| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Skip parsing the next line unless it starts with two spaces followed by
a non-whitespace character. This ensures we don't accidentally try to
parse a wrapped help line as a command.
This enables it to parse commands with wrapping descriptions, such as
```
Usage: arti hsc [OPTIONS] <COMMAND>
Commands:
prepare-service-discovery-key Prepare a service discovery key for connecting to a service
running in restricted discovery mode
help Print this message or the help of the given subcommand(s)
```
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds an experimental `arti hsc` subcommand for managing client
state and keys. Currently, it only supports the
`prepare-service-discovery-keys` operation described in #1281 and
`doc/dev/notes/client-auth.md`.
A note on terminology: I am referring to services that encrypt the
second layer of their descriptor as running in "restricted discovery"
mode (because they can only be discovered, i.e. have their IPT points
found out, by a set of authorized clients). The corresponding client
"auth" keys, being the keys that enable the client to find out the list
of intro points, pow-params etc. of the service, are referred to as
service "discovery keys".
Alternative names I considered:
* extra descriptor encryption: accurate, but overly technical. IMO,
the CLI should be accessible to users who aren't familiar with the
nitty-gritty of the protocol
* shielded mode: good, but slightly misleading. Calling it "shielded
mode" makes it sound like a universally desirable "extra protection"
that should almost always be enabled (which is not the case). Seeing
`shielded_mode = off` in the config might be worry operators that
don't fully understand what "extra descriptor encryption" or
"shielded mode" means
* restricted mode: slightly inaccurate. It implies this mechanism is a
good substitute for conventional service-side authentication, which
it isn't (because client authorization isn't instantaneous)
Closes #1281
|
| | |
|
| |
|
|
|
|
|
| |
This only runs in scheduled jobs. And it doesn't work right now.
It hasn't passed for at least a month, but it's not clear how much of
that time it was being run because the osx failure would mask it.
|
| |
|
|
|
|
| |
This has been obsolete for a very long time.
We have already published a version with a "won't be updated" warning.
|
| |
|
|
|
|
|
| |
No code changes needed.
Precisely
nailing-cargo -Eu upgrade --incompatible -p base32
|
| |
|
|
|
|
|
| |
No code changes needed.
Precisely
nailing-cargo -Eu upgrade --incompatible -p itertools
|
| | |
|
| |
|
|
|
|
|
|
| |
This is superseded now.
(I wish I had noticed it; perhaps I could have souped it up rather
than writing a whole new thing, but I think the result would have been
much the same.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compared to check-crate-owners:
1. Checks for uniformity, rather than having an embedded list
of intended maintainers.
2. Uses curl | jq, rather than `cargo owner`.
This is necessary for:
3. Ignores crates which have never been published.
This is necessary to be able to run this in CI, since there
may be new crates in the workspace.
4. Prints the ownership information rather differently -
just the usernames. This is a consequence of using curl | jq.
|
| |
|
|
| |
This is useful for debugging.
|
| | |
|
| | |
|
| |
|
|
|
| |
We (will) use `*.sh` for shell include files. We're about to make one
of these.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Add the optional non default feature flag "relay" that will be used to
enable relay support of arti.
This commit also adds the "relay" subcommand to arti binary conditionnal
on the feature flag in order to have a place holder starting point.
Signed-off-by: David Goulet <[email protected]>
|
| |\
| |
| |
| |
| |
| |
| | |
Script to check crate ownership
Closes #1462
See merge request tpo/core/arti!2196
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
I needed to use a virtual env to run this script (it doesn't work with
the mistune version packaged by arch), but found myself unable to
without changing the interpreter directive in `maint/extract-md-links`.
Closes #1460
|
| | |
|
| |\
| |
| |
| |
| | |
Upgrade and update packages for upcoming release
See merge request tpo/core/arti!2177
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
tor-keymgr: Add script for generating test key files.
See merge request tpo/core/arti!2121
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
The README now applies to the generate.sh script too, so it had to be
updated.
|
| | | |
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2169#note_3033481
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Provide and run script for making/checking link blocks in CHANGELOG.md
Closes #1388
See merge request tpo/core/arti!2126
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3030954
|
| | | |
| | |
| | |
| | |
| | | |
Suggested here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3026423
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2126#note_3026420
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This will be used by gen_md_links, instead of the regexp-based ad-hoc
parser there.
The existing parser gets wrong things like " `#[must_use]` ",
thinking that's a link.
Use a proper Markdown parser. But, we must commit some abuse, sadly.
|