| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates had no changes until just a moment ago. But since
we updated the versions on some of their dependents, they have now
changed themselves. Thus they get patchlevel bumps.
```
tor-rtmock
tor-protover
tor-socksproto
tor-consdiff
tor-chanmgr
tor-dirclient
tor-hsservice
```
|
| |
|
|
|
|
|
|
|
|
| |
These crates have had breaking changes. They are pre-1.0, so they get
a minor bump.
```
tor-basic-utils
tor-config
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Their dependents are _not_ updated to a more recent version.
These bumped the version of a dependency that they don't expose
```
tor-rtcompat
fs-mistrust
```
This one had internal refactoring:
```
tor-netdir
```
These had trivial changes only:
```
tor-checkable
tor-ptmgr
tor-guardmgr
arti-hyper
arti-bench
arti-testing
```
|
| |
|
|
|
|
| |
Since we made the internals of the ptmgr protocol parser
conditionally private, we need to tell Cargo to build the fuzzer
with the `experimental-api` feature so that it can access them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
|
| |\
| |
| |
| |
| |
| |
| | |
Report causes of errors
Closes #680
See merge request tpo/core/arti!997
|
| | |
| |
| |
| | |
Split off for ease of review and possible rebase.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
These crates had API or behavior changes that may affect downstream
crates. Fortunately, they're all version 0.x, and don't need minor
bumps for this.
|
| |/
|
|
|
|
|
| |
These changes influence behavior, but not effect compatibility.
(If I messed up, and any crate except for `arti` has non-breaking
API changes, that's still fine, since they are all version
0.x.)
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|
| |
|
|
|
|
|
| |
These are also based on temporary logs that I added locally while I
was hunting bugs.
Also part of #677.
|
| |
|
|
|
|
|
|
| |
This is based on logs that I added locally while I was trying to
debug some startup issues. Hopefully they'll make things easier the
next time there's something to debug.
Part of #677.
|
| |
|
|
|
| |
This commit introduces a consistency to the summary line of all
README.md files in each and every crate.
|
| | |
|
| |\
| |
| |
| |
| | |
Bump the minor version of every crate.
See merge request tpo/core/arti!918
|
| | |
| |
| |
| |
| | |
We made this job easy this time around: by incrementing our MSRV, we
have forced ourselves to do at least a minor bump everywhere.
|
| |/
|
|
|
|
|
| |
If we don't do this, then snowflake's stdin will get closed and
it will exit immediately.
Found while investigating #333.
|
| | |
|
| |
|
|
| |
This is used exclusively by the reactor.
|
| |
|
|
|
| |
We may want to change this later, but this API is in a low level
crate, so this isn't a blocker.
|
| |\
| |
| |
| |
| |
| |
| | |
ptmgr: Do not construct an empty select_all future.
Closes #672 and #670
See merge request tpo/core/arti!907
|
| | |
| |
| |
| |
| |
| | |
Closes #670.
Closes #672.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Rename it from UnconfiguredTransport. Change descriptions, kind, and
retry. Add a TODO.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/901#note_2858455
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/901#note_2858454
|
| |/
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/901#note_2858456
|
| |
|
|
|
| |
(I think this may be impossible now, since we check in ipc.rs, but
IMO it's best to check.)
|
| | |
|
| | |
|
| |
|
|
| |
This lets us avoid logging the user's path.
|
| | |
|
| |\
| |
| |
| |
| | |
Resolved several conflicts while doing so; mostly with !893 and
!895.
|
| | |
| |
| |
| |
| |
| | |
This fleshes out the PtReactor that was previously a stub, making it
actually do reactor-ey things. Note that this is entirely untested, and
might not work at all. Hopefully it does, though.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
I prefer that it not take `&mut self`, since PtMgr already has
interior mutability.
I also need it to take `tor_config::Reconfigure` argument, in case
it gains any more smarts about validation in the future.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Per convention, have a `full` feature.
Also, downgrade the 'TODO pt-client' entries in README::limitations,
since they are not blockers for 1.1.0.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't make much sense to have the pluggable transport manager be a
registry, so replace its interface with a more narrowly defined, less generic
version.
Other changes:
- instead of returning a &-reference, it returns an owned Arc, which
should make the ptmgr easier to implement while allowing efficient
reuse
- provision for error handling is added, but will probably be revised in
a future commit pending discussion
- tor-ptmgr code that would generate warnings as a result of this change
is temporarily removed
This is a split out version of arti!886, intended so work on arti#659
can proceed.
|