| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | | |
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
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/|
| | |
| | | |
Part of #1071
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes a race condition that would normally be fairly benign -
it would result in scheduling to check for expired channels again
immediately, and assuming non-zero time passes would then remove the
channel.
In Shadow's default time model though, zero time passes in this case,
so we just keep scheduling to check again immediately forever; i.e.
deadlock.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Without this change, if the delay is less than one second, the code will
effectively busy-loop until the delay has elapsed. This
potentially leads to deadlock in shadow simulations, and
wastes CPU in real usage.
https://shadow.github.io/docs/guide/limitations.html?highlight=busy#busy-loops
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
Clear away some misc todos in tor-hsservice.
See merge request tpo/core/arti!1819
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
hsservice: Log hsid whether we just generated it or not.
See merge request tpo/core/arti!1830
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With this change you can find your hsid in your logs
(if safe logging is off) even if you forgot to notice it the first
time around.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
arti_client: Cleanup around keymgr feature and config
See merge request tpo/core/arti!1832
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
keymgr is always on when it is needed, so experimental-api isn't
needed here.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The sub_builder pattern changes `StorageConfigBuilder` so that
instead of holding an `Option<ArtiNativeKeystoreConfig>`,
it holds an `ArtiNativeKeystoreConfigBuilder`.
This makes it a little more ergonomic to use from Rust,
and lets us use defaults for the builder fields so that we
can make them optional in our configuration.
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This change causes arti_client to have a configurable keymgr when
the onion-service-service feature is present, so that you no longer
need to configure "experimental" or "experimental-api" as well in
order to get a working onion service.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
circmgr:Resolve a warning when building without ntor-v3
See merge request tpo/core/arti!1831
|
| | |/ / / |
|