| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
By default `--key-type` is set to `restricted-discovery` so it can
omitted from these examples (omitting it makes the usage a bit clearer
IMO).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I am deprecating the old `hsc get-key` subcommand in favor of the new
`hsc key get` subcommand. This is because I plan to implement the rest
of the key management functionality (key deletion, rotation, etc.) as
subcommands of the `hsc key` command. The alternative would be to add a
new distinct top-level `hsc rotate-key`, `hsc remove-key`, etc.
subcommand alongside the existing `hsc get-key` command (which IMO is
less nice than the alternative I'm proposing).
|
| |\
| |
| |
| |
| | |
memquota: be more firm about avoiding panics, and tidy up docs
See merge request tpo/core/arti!2404
|
| | |
| |
| |
| | |
And remove the rest of the now-obsolete text.
|
| | |
| |
| |
| |
| |
| | |
This detect possibly-panicking operations.
Empirically this lint seems rather better now.
|
| | | |
|
| | |
| |
| |
| | |
All of this is now documented in the lib.rs.
|
| | |
| |
| |
| |
| | |
This sentence is very important piece of overall explanation, but
didn't make it into the crate level docs.
|
| | |
| |
| |
| | |
All of this is now implemented. Delete the obsolete sketch.
|
| |\ \
| | |
| | |
| | |
| | | |
Update s101 numbers for Q2 2024
See merge request tpo/core/arti!2245
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Diziet prefers this terminology; we'll defer a reckoning here
till #849 is resolved.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead of saying "no errors before authentication",
we now say "no syntax errors ever."
This should be easier to implement.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
(This is obsoleted by arti-rpc-client-core.)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Notably, identifiers SHOULD be C identifiers,
and everything has a namespace.
Reserve "rpc" as a namespace for things that were previously
unnamespaced.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This is probably still far too informal, but it is better than our
previous documentation.
|
| | | |
| | |
| | |
| | |
| | | |
(Note what isn't implemented,
and one more kind of authentication we'll likely build someday.)
|
| | | | |
|
| | |/
|/|
| |
| | |
(Markdown convention deprecates having more than one top-level heading.)
|
| | | |
|
| | |
| |
| |
| | |
See: tpo/team#313.
|
| |\ \
| | |
| | |
| | |
| | | |
doc/dev/notes: keymgr-porcelain: Add note about moving keymgr functions out of TorClient.
See merge request tpo/core/arti!2314
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
of TorClient.
This would a possible long-term fix for #1496.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This describes a couple of options for extending the config reloading
logic to support watching for changes in the
`restricted_disovery.key_dirs` directories.
Note: the options we have here are, in a sense, two extremes
* one is about refactoring some of the existing code into a
reusable component, and leaving most of the configuration logic
unchanged
* the other involves rethinking the entire config watching/reloading
mechanism to support watching for changes in arbitrary directories
I am leaning towards the simpler option, because I'm not sure the other
one is worth the added complexity (we currently only have a single use
case for it).
|
| | |
| |
| |
| |
| | |
This also makes the `tests/testcases/hsc/hsc.md` test case a symlink to
`doc/hsc.md`.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Per discussion, this field isn't really specified in a way that lets
us fill it sensibly at the moment. So for now, we're going to just
omit it.
Additionally, we said that we'd Report on our errors; this branch
changes the implementation of RpcError to do that.
Question: Will the blanket implementation for Into<RpcError> make
it harder to re-add a Data field later on if we want to do so?
|
| | |
| |
| |
| |
| | |
We've wanted separate error codes for "no such method exists" and
"this method exists, but this object doesn't have it."
|
| |\ \
| | |
| | |
| | |
| | | |
Remove arti-hyper from the list of crates in Architecture.md
See merge request tpo/core/arti!2268
|
| | |/
| |
| |
| |
| |
| |
| | |
Possibly we should have a CI job to check that this file is kept up to
date, but let's not do that now.
I filed #1484.
|
| |/ |
|
| | |
|
| |
|
|
| |
Not the raw gen_md_links utility.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
According to the [vanguards spec], client rendezvous circuits should be
STUB+:
* lite: `C -> G -> L2 -> Rend`
* full: `C -> G -> L2 -> L3 -> Rend`
[vanguards spec]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/e5ace3667dcbbf893c6b632fd4e3f16114fd2a0e/spec/vanguards-spec/index.md
|