| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| |
| | |
Filed
https://gitlab.torproject.org/tpo/core/arti/-/issues/1177
proposing a final fix.
|
| | |
| |
| |
| |
| |
| | |
Filed
https://gitlab.torproject.org/tpo/core/arti/-/issues/1176
proposing a final fix.
|
| | |
| |
| |
| | |
clippy correctly identifies that this is nicer than matches!.
|
| | |
| |
| |
| |
| | |
I'm not sure about this. Leaving it this way seems the most
conservative choice for now.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
clippy in current stable thinks
|(a, b)| (a, b)
is always the identity function, but due to match ergonomics, it might
be an implicit copy.
This is fixed in nightly by
https://github.com/rust-lang/rust-clippy/pull/11792
|
| | |
| |
| |
| | |
Resolves clippy complaints about needless fallible conversions.
|
| |/
|
|
|
| |
FTR I don't think agree with clippy on this question, but then I often
don't.
|
| |\
| |
| |
| |
| | |
tor-rtcompat: use track-caller for thin wrappers
See merge request tpo/core/arti!1843
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In particular, when the (unstable) tokio tracing feature is enabled,
every tracing line includes the name of where the current task was
created. Without this change, that ends up being the name of
intermediate trait methods like TokioRuntimeHandle::block_on, which is
not very helpful.
Adding the `track_caller` attribute causes the name of the caller of
these methods to be used instead, which is typically more helpful.
IIUC this change is not breaking in terms of semver
https://rustc-dev-guide.rust-lang.org/backend/implicit-caller-location.html.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Bump zerocopy 0.7.29 -> 0.7.31
Closes #1174
See merge request tpo/core/arti!1844
|
| |/
|
|
|
|
|
|
| |
```
cargo update -p zerocopy
```
Fixes https://gitlab.torproject.org/tpo/core/arti/-/issues/1174
|
| |\
| |
| |
| |
| |
| |
| | |
tor-netdoc: Make HsDescBuilder::auth_clients take an Option.
Closes #1019
See merge request tpo/core/arti!1840
|
| | |
| |
| |
| | |
Closes #1019
|
| |\ \
| | |
| | |
| | |
| | | |
tor-cell: Stop using deprecated name in doctest
See merge request tpo/core/arti!1842
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-keymgr: Use spec.torproject.org for the SSH algo name domain.
Closes #1108
See merge request tpo/core/arti!1838
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The algorithm name for x25519 keys has changed, so the test keys need to
be updated.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The algorithm name for expanded ed25519 keys has changed, so the test
keys need to be updated.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Diziet addressed these in #1049
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Note: any existing x25519 or expanded ed25519 keys you might have in the
keystore will become invalid (your keystore will appear corrupt, so you
will need to manually delete them if you want to continue using the
onion service they were originally generated for).
Part of #1108
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
doc: Document how to find out your .onion address with `arti hss`.
See merge request tpo/core/arti!1841
|
| | | | | |
|
| | | |/
| |/| |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Rename {Any}RelayCell to {Any}RelayMsgOuter
Closes #775
See merge request tpo/core/arti!1839
|
| | | |
| | |
| | |
| | |
| | | |
We should remove these once we do our final renaming here,
but for now we may as well avoid a breaking change.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit is pure renaming, done automatically with rust-analyzer.
Comment fixes and other cleanups will be in the subsequent commits.
We're doing this renaming because we need a name for
the combination of a `RelayMsg` and an `Option<StreamId>`
that we use when we have a `RelayMsg`
we intend to route to a given stream or circuit internally.
Previously we called this a `RelayCell`,
but that name was already somewhat inaccurate,
and will become _very_ inaccurate with the arrival of prop340,
which breaksthe 1:1 relationship between relay cells
and relay messages.
(If we didn't do this renaming now, we'd soon be making
the relationship between `UnparsedRelayCell`and `RelayCell`
many-to-many, which would be ridiculous and confusing.)
The `RelayMsgOuter` name is a placeholder:
We expect that we'll want to rename this type,
and may also want to rename `RelayMsg`,
and unify our vocabulary in other areas too.
But such a renaming will have to wait
for a larger discussion affecting the specifications,
so that we can use the same vocabulary everywhere.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
tor-hsservice: Fix broken doc link.
See merge request tpo/core/arti!1836
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Resolve Arti crate todos, redux
See merge request tpo/core/arti!1833
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
(We can't use `visibility::make(pub)` or `visible` here.
Try it yourself if you don't believe me!)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The TODO HSS in question is about our inability to serialize every
possible builder. The right answer here might be to use something
else instead of a ListBuilder.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The most logical way to do this was to change the "List" type
to a HashMap, and add a build function to the ListBuilder.
This change additionally renames:
OnionServiceProxyConfig{List=>Map}
NamedProxyMap => ProxyBuilderMap
(We now have two kinds of map, and this name change will clarify the
distinction.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
IIUC, there will never be a Some(InNew) entry here, since we will
never have an onion service be configured by default. Instead we
test this kind of configuration by having commented-out options that
we uncomment as needed.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
It's correct that we'd like someday for the `arti` crate APIs to
allow all the different modes supported by `Reconfigure` enum;
this is #1156, and it does not block an HSS release.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
(This was solved with !1798)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
arti: Add an hss subcommand.
See merge request tpo/core/arti!1837
|
| | | | | |
|