| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Hidden services disabled in the config are now handled more gracefully
by arti/arti-client, before the hard error occurs.
The axum and hyper examples were updated as a consequence.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Added the `enabled` field to the config options for hidden services. The
default is `true`. If it is set to `false`, the service won't start. As
of this specific commit, it's a hard error; it'll be checked again at
an earlier stage where it won't be once the feature is ready.
Signed-off-by: hashcatHitman <[email protected]>
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | | |
arti-relay: Add OR port listener task
See merge request tpo/core/arti!3396
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
For incoming connections, wrap the peer address in `Sensitive` as it
could be a client.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This does not yet get the OR port from the config, and the channel
manager doesn't yet do anything with the incoming connection.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: Tor CI Release <[email protected]>
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-netdoc: parse2 More deduplication of the derive macro
See merge request tpo/core/arti!3455
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This can result in "trait not implemented" errors here. Use the
`${paste_spanned}` trick.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Move what is now IF_NONSTRUCTURAL_ACCUMULATE into the common module.
It's not yet suitable for reuse.
The docs for ACCUMULATE_ITEM_VALUE are still wrong. We'll fix that in
a moment.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This was previously only not done because of the need to c&p.
Also, we're going to be expanding some common macros that will use it.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The hygiene is fixed in derive-deftly 1.5.x.
|
| |\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | |
| | | | | | |
| | | | | | | |
tor-netdoc: Rename the `build` module to `encode`
See merge request tpo/core/arti!3456
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We're going to introduce facilities for encoding more generally, and
we'll want a way to enable them.
Instead, have a separate feature for *encoding* documents.
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The word "build" so often in Rust means builder pattern. This module
contains functions for encoding.
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
`arti-client`: Move `create_onion_service()` to `InertTorClient`
See merge request tpo/core/arti!3435
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Part of #2118.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-netdoc: parse2 derive: Some deduplication
See merge request tpo/core/arti!3450
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Have the module expect the use site to determine (mostly) the field
kind. Document this expectation.
Now NetdocParseableCommon can have the keyword-related definitions.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Put one textually-identical define in it, to start with.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
arti-client: Add TODO for #2249.
See merge request tpo/core/arti!3453
|
| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
rpclib: Rename `OutPtr` to `OutBoxedPtr`
Closes #1588
See merge request tpo/core/arti!3439
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Closes #1588.
|
| |\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
rtcompat: Spawn every future in_current_span.
See merge request tpo/core/arti!3445
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
If we need to override this in the future, we can provide a new
method that takes a Span as an argument.
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
tor-proto: Reduce `high_water_mark` of ChannelFrame
See merge request tpo/core/arti!3447
|
| | | |_|_|_|/ / / /
| |/| | | | | | | |
|
| |\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
proto: Rename RelayReatorHandle to RelayCirc, make it pub
See merge request tpo/core/arti!3410
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
We don't really need this channel here, because we already have control
and command channels for checking if the reactor task is still alive.
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
While this is technically a "reactor handle", I think RelayCirc sounds
better, because this is essentially our only public API for interacting
with a relay circuit (it will be used outside of tor-proto).
(This would also be consistent with our existing ClientCirc
client-side terminology).
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This will soon become `pub`, so I am factoring it out of `reactor.rs`.
|
| | | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
BackwardReactor is an implementation detail, so it shouldn't really be
mentioned in the soon-to-be-public-facing docs.
And besides, the control messages are no longer handled by the
BackwardReactor.
|
| |\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Bump derive-deftly to 1.5.0
See merge request tpo/core/arti!3451
|