| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
This matches the behavior of C tor. Part of #1100.
|
| |
|
|
|
|
| |
This matches the behavior of C tor.
Part of #1100.
|
| | |
|
| |\
| |
| |
| |
| | |
Remove all semver.md files to start a fresh release round
See merge request tpo/core/arti!1957
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bump the minor version of these crates, and update the in-tree
dependencies.
Recently published as fresh crates, let's just assume there are
breaking changes:
fslock-guard
test-temp-dir
Breaking API change affecting many many downstream crates:
tor-rtcompat
Downstream crates which we're (conservatively) assuming have
tor-rtcompat types in their APIs:
tor-rtmock
tor-log-ratelim
tor-rpcbase
tor-llcrypto
tor-protover
tor-bytes
tor-hscrypto
tor-hspow
tor-socksproto
tor-checkable
tor-cert
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-consdiff
tor-netdir
tor-congestion
tor-persist
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
tor-hsrproxy
arti-client
arti-rpcserver
arti-config
arti-hyper
arti-bench
arti-testing
|
| |\
| |
| |
| |
| |
| |
| | |
Clean up, tune, and correct various parameters related to introduction points.
Closes #1210
See merge request tpo/core/arti!1924
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(Also, correct the comments that describe them.)
We may as well match the spec names when they aren't completely
bogus.
We are already renaming these parameters for this release, so it
isn't an additional breaking change.
|
| | |
| |
| |
| |
| |
| | |
The old names were somewhat inaccurate. (I would have considered
keeping and deprecating the old names, but we already have breaking
changes in tor-netdir.)
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
newer periods.
This fixes a bug where `offset_within_srv_period()` returns `None`,
instead of the offset of `when` from the start of the SRV of the
previous time period:
```
2024-01-24T15:24:46Z ERROR tor_hsservice::svc::publish::reactor: descriptor upload failed for HS service
allium-cepa2 and time period TimePeriod { interval_num: 19745, length: IntegerMinutes { value: 1440 },
epoch_offset_in_sec: 43200 }: error: Programming error: internal error (bug) at
/../arti/crates/tor-hsservice/src/svc/publish/reactor.rs:218:13: current wallclock time not within
SRV range?! (now=SystemTime { tv_sec: 1706109886, tv_nsec: 246572852 },
SRV_start=SystemTime { tv_sec: 1705968000, tv_nsec: 0 })
```
We need to be able to calculate this offset even if `now` is not within
the SRV range (because we upload the descriptor to the HsDirs of the
*previous* time period too).
Note a similar bug exited in `offset_within_period()` (which no longer
exists) too! That one was fixed in !1744:
```
Hidden services can have multiple "active" time periods for which they
generate descriptors. We need to be able to compute the offset of a
timestamp from the start of a given time period, even if that timestamp
falls within the "next" time period (for example, when publishing
descriptors for the "previous" time period, the `when` timestamp will
fall outside the `(start, end)` range of the "previous" time period).
```
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1904#note_2987777
|
| |
|
|
| |
Part of #1166
|
| |
|
|
|
|
|
|
| |
The publisher is the only user of `hs_dirs_upload`. It turns out it
never actually uses the first element of the yielded `Item`s, so we can
simplify `hs_dir_upload` to only return the HsDir `Relay`s.
Part of #1166
|
| |
|
|
|
|
|
|
|
| |
The descriptor publisher uses this function to obtain the list of
relevant time periods. It will soon also need to know the `srv_lifespan`
associated with each time period, so we change this function to return
`HsDirParams`.
Part of #1166
|
| | |
|
| |
|
|
| |
Closes #1254.
|
| | |
|
| |
|
|
| |
This is part of #1254.
|
| |
|
|
|
|
| |
This implements Relay::is_hs_intro_point.
Close #1240.
|
| |
|
|
|
| |
As we enforce these flags in more places, it will be handy for our
default network to have them for its relays.
|
| | |
|
| | |
|
| |
|
|
| |
These are not release-blockers.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
These crates had no changes previously, but they depend on crates
that had breaking changes themselves.
tor-linkspec
tor-hspow
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This crate doesn't have a meaningful public API, so it just gets a patchlevel bump:
arti
These crates had nonbreaking changes, and get a patchlevel bump:
tor-rtcompat
fs-mistrust
tor-llcrypto
tor-cert
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates have breaking changes on their own:
tor-error
tor-netdoc
tor-dirmgr
tor-keymgr
Because of the breaking change in tor-error, and the fact that
basically every crate publicly depends on tor-error (by implementing
ErrorKind), we need to call this a breaking change on all of the
following:
tor-config
tor-geoip
tor-rtmock
tor-log-ratelim
tor-rpcbase
tor-bytes
tor-hscrypto
tor-socksproto
tor-cell
tor-proto
tor-netdoc
tor-netdir
tor-persist
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
tor-hsrproxy
arti-client
arti-rpcserver
arti-config
arti-hyper
arti-testing
|
| |
|
|
|
|
|
|
|
|
| |
clippy in current stable thinks
|(a, b)| (a, b)
is always the identity function, but due to match ergonomics, it might
be an implicit copy.
This is fixed in nightly by
https://github.com/rust-lang/rust-clippy/pull/11792
|
| |
|
|
|
|
|
|
|
| |
These crates both depend on tor-error. Since tor-error got a
patchlevel bump, they now depend on the new version, which means by
our rules that _they_ get a patchlevel bump themselves.
tor-geoip
tor-rpcbase
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This crate is new, and gets a bump to 0.1.0.
tor-log-ratelim
This crate had a breaking change:
tor-persist
tor-llcrypto had a breaking change. These crates _are_
tor-llcrypto, or (transitively) depend on it. I am assuming that
they all re-expose something from it in a way that matters:
tor-llcrypto
tor-bytes
tor-hscrypto
tor-socksproto
tor-checkable
tor-cert
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-consdiff
tor-netdir
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
tor-hsrproxy
arti-client
arti-rpcserver
arti-hyper
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates had backward-compatible changes, and get a patchlevel
bump only:
fs-mistrust
tor-error
tor-config
tor-rtcompat
tor-rtmock
This crate exposes no non-CLI APIs, and gets a patchlevel bump only:
arti
|
| | |
|
| |
|
|
|
|
| |
It does not help that C tor has a set of parameters and a set of
configuration options with exactly the same names which configure
the same thing in two slightly different ways.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
These crates have new APIs:
tor-async-utils ADDED
tor-config ADDED
tor-hscrypto ADDED
tor-netdoc ADDED, plus BREAKING-experimental.
These crates have patch-level changes only:
tor-netdir (bugfix only). (re-exposes netdoc)
arti-rpcserver (tweaks only, uses nothing that broke.)
arti 1.1.10, no stable public APIs.
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
tor-basic-utils BREAKING
tor-rtmock BREAKING.
tor-cert BREAKING
tor-cell BREAKING
tor-proto BREAKING: re-exposes cell. (Also BREAKING-experimental)
tor-chanmgr BREAKING: Re-exposes proto.
tor-ptmgr BREAKING: re-exposes tor-chanmgr
tor-guardmgr BREAKING: re-exposes proto. (Only for ClockSkew I think?)
tor-circmgr BREAKING: re-exposes proto
tor-dirclient BREAKING
tor-hsclient BREAKING, re-exposes proto.
tor-hsservice BREAKING, re-exposes proto.
tor-hsrproxy BREAKING
arti-client BREAKING: re-exposes proto.
arti-hyper: BREAKING, re-exposes arti-client.
tor-dirmgr Let's assume BREAKING, very high-level.
tor-keymgr BREAKING, but experimental.
```
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The statement
```
if hsids.all(|(_hsid, period)| rings.any(|(_, _, tp)| tp == period)) {
```
had 2 bugs:
* the condition is reversed (it should be negated: we need to bail if
one of the specified `hsids` cannot be found on any of our rings)
* `rings.any()` mutates the `rings` iterator, causing
`hs_dirs_upload` to return fewer HSDirs than expected
|
| |
|
|
| |
(The only change in these crates is that their dependencies changed.)
|
| | |
|
| | |
|
| |
|
|
|
| |
These crates have had changes that do not require their dependents
to require a later version.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This threads the country codes work through the rest of the codebase:
- `tor-dirmgr` will now enable GeoIP with the embedded database when the
`geoip` future is enabled
- This can be extended later using the `DirMgrConfig` to allow
specifying a custom database; this is not done here, though
- `tor-circmgr`'s `SupportedCircUsage` and `TargetCircUsage` fields gain
new `country_code` members to allow filtering circuits by country
- These are `()` in builds where the `geoip` feature is not enabled --
doing it this way means we don't have to copy and paste huge swathes
of code, since we can't use `#[cfg]` in patterns
- `ExitPathBuilder` gains (hacked-in) support for choosing a relay with
the correct country code
- Due to the lack of conjuction, we just copy and paste a small bit,
pending further refactoring
- `StreamPrefs` now lets you specify a country code, letting embedders
make use of the feature
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are:
```
hashx
equix
tor-async-utils
tor-error
tor-config
tor-rtmock
tor-llcrypto
tor-bytes
tor-hscrypto
tor-hspow
tor-cert
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-netdir
tor-chanmgr
tor-guardmgr
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
arti-client
arti
```
|
| | |
|
| |
|
|
| |
Apply erroneous formatting as demanded by rustfmt.
|