| 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
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix continually_expire_channels timing issues
See merge request tpo/core/arti!1834
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Disabling the shadow option --model-unblocked-syscall-latency causes
this bug not to surface. Better to remove this workaround for now
so that we can revisit again if/when it does rather than continue to
mask it.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This option is mostly a workaround for busy loops and other subtle race
conditions. While having it enabled can let us ignore some benign busy
loops and timing edge cases, it can also hide real problems; e.g.
burning extra CPU in a busy-loop.
https://shadow.github.io/docs/guide/limitations.html#busy-loops
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Remove our cargo-audit exception for ed25519-dalek
See merge request tpo/core/arti!1783
|
| | | |
| | |
| | |
| | |
| | | |
We should have added these to our record of previous rustsec
ignores, but we accidentally removed them instead.
|
| | | |
| | |
| | |
| | | |
It's no longer necessary now that we have upgraded.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
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
|