| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This moves the window-based flow control for half-streams out of the
`HalfStream` and into the `HalfStreamWindowFlowCtrl` object.
Now that it's applied only in `HalfStreamWindowFlowCtrl` and not
generally for all half-streams, we no longer apply window-based flow
control to half-streams when they're really using xon/xoff-based flow
control.
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This adds the general structure, and we'll fill it in and use it in a
following commit.
|
| | | |/ / / / / /
| |/| | | | | | |
|
| |\ \ \ \ \ \ \ \
| |/ / / / / / /
|/| | | | | | |
| | | | | | | |
| | | | | | | | |
hsclient: Fix numerous bugs in timeout estimators
See merge request tpo/core/arti!3940
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Gabi correctly points out that since the client uses guarded
circuits for introduction points, whereas the service uses naive
circuits, we shouldn't expect the peer's circuits to be any longer
than ours.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
There's no reason that the next person should have to rediscover
these caveats.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Both C tor and Arti will retry building a circuit if the first
attempt fails. This means that it can be worthwhile waiting longer
than we might otherwise for the HS to build its rendezvous circuit.
We don't need to make this change for _our_ circuits, since
the CircMgr code takes care of those timeouts for us.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
We don't actually need to use this method on any circuits that have
a virtual hop, so instead of "fixing" this method to ignore virtual
hops, the simpler approach is to change its name and its documented
behavior, and to explain how the documented behavior is appropriate
for our needs.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Duration::try_from_secs_f64 has existed since Rust 1.66,
so we can use it now.
It seems wrong to treat "infinity" and "negative infinity" as "one
second", so make them actually saturating.
Additionally, document behavior for infinity and negative infinity,
and document that the NaN behavior isn't documented.
(And secretly NaN behavior return a number on the same order of
magnitude as the input.)
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This strategy is safe because (outside of our tests) we never look
at the actual values of timeout_scale, but only at their ratios.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This time we _do_ need to use the BuildCircuit estimator, since we
have to consider the peer's circuit building.
The peer may be using full vanguards, so we need to use 5 as their
maximum hop estimate.
Additionally, their circuit may be longer than ours, so we ought to
possibly wait a bit longer for them to get our INTRODUCE2.
There are XXXXs here about OneWay timeout estimators, for immediate
followup.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The circmgr handles timeouts on its own, so we can let it do that.
Use the actual circuit length for calculating round-trip timeouts.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The circmgr code handles circuit timeouts, so we don't need to
include that redundantly.
Also, we look at the circuit to find out its number of hops,
so that we estimate the timeout more accurately.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The hspool operations already include their own timeouts, so we
don't need to recalculate them.
For the directory related operations, we now calculate the timeouts
based on actual circuit lengths, and use those timeouts on the
operations themselves.
|
| | |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | | |
We'll use these for timeout estimations.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Rust 1.88 added these, so we no longer have to use `any()` for false
and `all()` for true.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
It is no longer needed since we require Rust 1.89. Nobody was using
it.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | | |
We now know when it was stabilized, so we can say when to use it.
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
release: Remove semver.md files.
See merge request tpo/core/arti!3955
|
| | | | | | | | |
|
| | |/ / / / /
|/| | | | | |
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
release: Bump release date for 2.3.0.
See merge request tpo/core/arti!3953
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
release: Version bumps
See merge request tpo/core/arti!3952
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
cargo set-version -p arti-client 0.42.0
cargo set-version -p arti-config 0.42.0
cargo set-version -p arti-relay 0.42.0
cargo set-version -p arti-rpc-client-core 0.42.0
cargo set-version -p arti-rpcserver 0.42.0
cargo set-version -p arti-testing 0.42.0
cargo set-version -p arti-ureq 0.42.0
cargo set-version -p tor-async-utils 0.42.0
cargo set-version -p tor-basic-utils 0.42.0
cargo set-version -p tor-bytes 0.42.0
cargo set-version -p tor-cell 0.42.0
cargo set-version -p tor-cert 0.42.0
cargo set-version -p tor-cert-x509 0.42.0
cargo set-version -p tor-chanmgr 0.42.0
cargo set-version -p tor-checkable 0.42.0
cargo set-version -p tor-circmgr 0.42.0
cargo set-version -p tor-config 0.42.0
cargo set-version -p tor-config-path 0.42.0
cargo set-version -p tor-consdiff 0.42.0
cargo set-version -p tor-dirclient 0.42.0
cargo set-version -p tor-dircommon 0.42.0
cargo set-version -p tor-dirmgr 0.42.0
cargo set-version -p tor-dirserver 0.42.0
cargo set-version -p tor-error 0.42.0
cargo set-version -p tor-events 0.42.0
cargo set-version -p tor-general-addr 0.42.0
cargo set-version -p tor-geoip 0.42.0
cargo set-version -p tor-guardmgr 0.42.0
cargo set-version -p tor-hsclient 0.42.0
cargo set-version -p tor-hscrypto 0.42.0
cargo set-version -p tor-hsrproxy 0.42.0
cargo set-version -p tor-hsservice 0.42.0
cargo set-version -p tor-key-forge 0.42.0
cargo set-version -p tor-keymgr 0.42.0
cargo set-version -p tor-linkspec 0.42.0
cargo set-version -p tor-llcrypto 0.42.0
cargo set-version -p tor-log-ratelim 0.42.0
cargo set-version -p tor-memquota 0.42.0
cargo set-version -p tor-memquota-cost 0.42.0
cargo set-version -p tor-netdir 0.42.0
cargo set-version -p tor-netdoc 0.42.0
cargo set-version -p tor-persist 0.42.0
cargo set-version -p tor-proto 0.42.0
cargo set-version -p tor-protover 0.42.0
cargo set-version -p tor-ptmgr 0.42.0
cargo set-version -p tor-relay-crypto 0.42.0
cargo set-version -p tor-relay-selection 0.42.0
cargo set-version -p tor-rpcbase 0.42.0
cargo set-version -p tor-rpc-connect 0.42.0
cargo set-version -p tor-rtcompat 0.42.0
cargo set-version -p tor-rtmock 0.42.0
cargo set-version -p tor-socksproto 0.42.0
cargo set-version -p tor-units 0.42.0
|
| | | | | | | | |
|
| | |/ / / / / |
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
Release prep (fixup-features)
See merge request tpo/core/arti!3949
|
| | |/ / / / |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 9447e48d0c698d51c75706d5efedcd6142c82f2a, which
told Clippy to ignore a warning that (I think) no longer occurs.
(Clippy was complaining that we were _naming_ a function in a
const-context that wasn't const-stable at our MSRV. But it's fine
to _name_ a non-const function in that case: we just can't _call_
it.)
See https://github.com/rust-lang/rust-clippy/issues/15792 for more
info on the clippy bug.
AFAICT the warning no longer appears with current beta, nightly,
or stable versions.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Upgrade to hickory-proto 0.26.1
Closes #2517
See merge request tpo/core/arti!3942
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes
https://rustsec.org/advisories/RUSTSEC-2026-0120.html
and
https://rustsec.org/advisories/RUSTSEC-2026-0119.html
Neither of these is relevant for Arti, but we may as well upgrade.
This change required some code changes, since the upgrade from 0.25
changed some of the old APIs.
Closes #2517.
|
| |\ \ \ \
| |/ / /
|/| / /
| |/ /
| | | |
Unknown keyword handling fixes; use a more principled type for directory signature hash algo
See merge request tpo/core/arti!3923
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This type is now directly suitable for use in directory signatures.
While we're changing its type, rename the digest algorithm name field
from `digestname` to `digest_algo`. (The spec says `algorithm` but I
don't think we're going to reuse `direcctory-signature` for non-RSA
signatures so this is just the hash algorithm.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want DirectorySignatureHashAlgo for prod's directory Signature
type.
However, for complex cfg gate and macro scoping reasons, we can't just
move the definition out of poc. Hence this rather unpleasant
intermediate state. This will go away, and become normal again, when
we can abolish poc's signatures and have poc use a prod signature
type.
Review with
git show --color=always --color-moved-ws=allow-indentation-change --color-moved
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We're going to use this for `directory-signature`'s hash algorithm,
which the current code always treats as a string!
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Make the operation of disregarding the possible existence of
already-discarded information, more explicit.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This allows implementing NormalItemArgument for types that can only be
parsed, or only displayed - or other combinations.
I noticed this restriction while inventing a type I later decided was
unnecessary. I still think it's a good change.
There is no practical impact elsewhere, since in practice downstream
code implements NormalItemArgument rather than relying on it.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Part of #2492 phase 3.
This feature was experimental, so now that there are no cfg use gates,
we can abolish it right away.
|
| | | |
| | |
| | |
| | | |
Part of #2492 phase 2.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-cert: stabilise/abolish "encode" feature, and fix builder naming
See merge request tpo/core/arti!3926
|