| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| |
|
|
|
| |
It's cute, but I don't think it will help performance, and I'm
undecided about whether the semantic implications are true.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This logic is a bit tricky, so I've tried to document it and add
fairly good tests. The silver lining is that the external API for
all of this logic will make it invisible and hidden.
There are some cases where I added functions that I think might
eventually get lowered into MdConsensus: But I don't want to lower
too much right now, since the convention for our netdoc accessors is
that they are fairly unsophisticated, and they show you the document
as it is.
Closes #686
|
| |\
| |
| |
| |
| | |
Upgrade toml to version 0.6.
See merge request tpo/core/arti!989
|
| | |
| |
| |
| |
| |
| |
| | |
This required rewriting some of our error handling code in
command-line processing, since the toml crate now displays and
reports errors differently. (Admittedly, this code still is kind of
ugly, but at least it is nicely hidden.)
|
| | | |
|
| | |
| |
| |
| |
| | |
This implementation was made based on the specification, and then
validated against itself, and against C Tor.
|
| | |
| |
| |
| |
| | |
This required some API tweaks, which is probably to be expected;
these time periods are a wonky kind of thing.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
(We don't yet use the code that uses it, but we might as well have
our unused code be up-to-date.)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is in lieu of upgrading to the latest base64 crate, which has
a different API from the old one. Since we have to migrate either
way, we might as well use base64ct everywhere.
I don't think that most of these cases _require_ constant-time
base64, but it won't hurt.
|
| | |
|
| |\
| |
| |
| |
| | |
Make a top-level API for connecting to onion services.
See merge request tpo/core/arti!971
|
| | |
| |
| |
| | |
Fortunately, it adds very little to the arti-client API surface.
|
| |/
|
|
| |
ed25519 1.5.2 has been yanked.
|
| |
|
|
|
|
|
|
|
| |
These are a bit complex internally, but the API they present is
pretty simple. I've left some discussion of points where the design
isn't totally fleshed out, and where we need to look harder at the
spec.
Part of #716.
|
| |
|
|
|
|
|
| |
On 1.22, cargo audit is complaining about RUSTSEC-2023-0001.
We aren't affected, since we don't use windows named pipes (yet),
but let's make cargo audit happier.
|
| |\
| |
| |
| |
| |
| |
| | |
Temporary fix for #715 and #569
Closes #715
See merge request tpo/core/arti!958
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Onion service APIs, part 1.
See merge request tpo/core/arti!959
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This module has types and operations needed in multiple places
for an onion service implementation. There are a bunch of
TODO hs-crypto comments that we'll need to fill in.
|
| |/ / |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the new upstream version (published by me, recently).
It has the same MSRV and one breaking change:
The caller who specifies a home dir function for substituting into
strings, must now supply a string, not Path. Previously shellexpand
would allow the caller to supply non-unicode data, and then simply not
substitute it. That was an infelicity in the shellexpand API.
Now this infelicity is pushed into our code. The overall behaviour of
Arti hasn't changed as a result. And it seems reasonable to me.
shellexpand 3.x also has a module for expanding Paths instead, in
response to requests for this filed as upstream tickets. We *could*
use that but I am not sanguine about that approach: the Pathness would
spread throughout much of our config and file handling code.
I think we should at the very least postpone trying to work with
invalid-unicode-paths as long as we can.
|
| |
|
|
|
| |
We made this job easy this time around: by incrementing our MSRV, we
have forced ourselves to do at least a minor bump everywhere.
|
| | |
|
| |\
| |
| |
| |
| | |
Add tests for a bunch of code in tor-linkspec
See merge request tpo/core/arti!867
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Post-merge cleanups for PtMgr
Closes #667 and #659
See merge request tpo/core/arti!893
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes a `pt_state` directory inside .local/share/arti (or the
local equivalent), right next to our existing `state` dir.
Ideally we would use a separate directory for each PT, but we have a
very fuzzy "what is a specific PT" notion.
Closes #667
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These are implementation details and we don't want to mark them as
stable.
To do this, I needed to apply some additional options to the example
code's configuration in Cargo.toml.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
As near as I can tell, the rust-crypto SHA1 crate was called `sha-1`
for a while because of a conflict with a different SHA1 crate. Now
they apparently have the `sha1` name back and have deprecated the
`sha-1` name.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
reproducible builds without shm
Closes #614
See merge request tpo/core/arti!818
|
| | | |/
| |/| |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Define a "redactable" trait, and use it when logging guard info
Closes #648 and #627
See merge request tpo/core/arti!882
|
| | | | |
|
| | |/ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements `PtMgr`, a pluggable transport manager
responsible for keeping track of spawned PTs and spawning them to
satisfy client requests on demand.
It does this in two parts: the `PtMgr` type exported to the rest of the
code, and the background `PtReactor` that actually does the spawning;
this design ensures that only one attempt to spawn a PT is active at a
time, and will prove useful later for implementing e.g. timeouts.
A few changes were necessary to the rest of the code in order to make
this all work out. Namely:
- `TransportRegistry`'s API didn't make any sense for two reasons:
- It wasn't feasible for implementors to implement `ChannelFactory`,
since that'd require constructing a `ChanBuilder` (which requires a
bootstrap reporting event sender).
- Treating the PT manager as a registry is over-general; it's only
necessary for it to spawn pluggable transports, so saddling it with
other concerns didn't make any sense.
- (It's possible to get extensibility for arbitrary user customization
by just letting the user swap in a new `ChannelFactory`, anyway.)
- Therefore, the `PtMgr` implements the new `AbstractPtMgr` trait, which
is far more narrowly focused; this only exists to solve a dependency
loop, and is documented as such.
- This provides a `TransportHelper` instead of a `ChannelFactory`.
|
| | |
|
| |
|
|
|
| |
This makes it easy to talk about, and construct, a
BoxSensitive<OwnedChanTarget>, which is what we'll use in errors.
|