mirrors/arti.git/crates/tor-hsservice/src/publish/reactor.rs, branch arti-v2.4.0 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.4.0 2026-05-21T15:55:18Z hsservice: Set the current random value for the custom netdir 2026-05-21T15:55:18Z Gabriela Moldovan gabi@torproject.org 2026-05-21T15:00:52Z urn:sha1:ac13f3a453135c8d6509f0e093aba42cfd6ac696 This test was supposed to set both the current and the previous SRV in the test netdir, but was actually only setting the previous one. With the new SRV fixes from ee07c441909b41d5fbbfbffae310e954a69db478, all the hsservice tests using this netdir were panicking on an `.unwrap()`, because the SRV for the "previous" TP could not be found, which is actually what you'd expect to happen, given that the netdir was built with only one SRV. The reason the tests weren't failing before is, funnily enough, because of the bug in SRV calculation that is fixed in ee07c441909b41d5fbbfbffae310e954a69db478: In `tor-netdir`, the `extract_srvs()` function (correctly) only returned a single SRV from the consensus (the "previous one", set with `bld.shared_rand_prev()` in the test), but the `find_params_for_time()` was wrongly matching up that same SRV with multiple time periods. This happened because the old implementation was computing the "previous SRV" validity interval as: * ts_begin = `[start_of_day_containing(consensus_ts) - ONE_DAY` * ts_end = `ts_begin + srv_interval` And because the test SRV interval is 288h(!), and the test TP length is only 24h, the validity period of the previous SRV (incorrectly) covered two TPs (both the previous and the current). So as a result, the test was "successfully" getting back the same SRV for both the previous and the current TP. The bug was introduced in the commit that originally added the hsservice tests: 279842526591918e25ca97e6392f211a50192396 dirclient, hsservice: Use Arc<str> for hsdesc publishing. 2026-05-12T12:10:03Z Nick Mathewson nickm@torproject.org 2026-04-25T21:30:17Z urn:sha1:176fcd170d2a9adc38ff82e42a5167a940e47268 This saves a little memory, but the technique will help save more memory for other uploads. Fix word duplicate typos 2026-03-15T20:18:56Z Tobias Stoeckmann tobias@stoeckmann.org 2026-03-15T20:05:34Z urn:sha1:2173207d8b909d1afdc55adda13faac13cdded0f hsservice: Remove unnecessary wraps from publisher function 2026-01-27T18:21:39Z Gabriela Moldovan gabi@torproject.org 2026-01-27T18:21:39Z urn:sha1:cb992c01e82a820a9b75dd755815725926cbebb9 This lint triggers now that the unnecessary `async` is gone. hsservice: Remove unnecessary async from publisher function 2026-01-27T18:20:47Z Gabriela Moldovan gabi@torproject.org 2026-01-27T18:20:47Z urn:sha1:ecc930d55ac38d9188171981f8390c4b8b43dcb8 opentelemetry: Instrument a bunch of functions. 2025-11-24T16:28:07Z Wesley Aptekar-Cassels me@wesleyac.com 2025-11-24T16:28:07Z urn:sha1:a4db6a7495b13dd7b00416dd1660a5ad82b60919 These are all aimed at figuring out in more detail what's going on in #2079 and related issues. Fix name of clippy lint to unchecked_time_subtraction (2) 2025-11-06T11:28:22Z Ian Jackson ijackson@chiark.greenend.org.uk 2025-11-06T11:23:25Z urn:sha1:a5fd5c48ea059a80cc1f6c50e248654b5ff3aaff Run maint/add_warning hsservice: Move derive_more::From out of internal_prelude. 2025-08-19T13:46:54Z Nick Mathewson nickm@torproject.org 2025-08-19T13:46:54Z urn:sha1:6cb98ccc344768c0cff6b7136ea81c38d2f4e990 This fixes an error from nightly. The trouble is that with nightly, there's a now a [derive macro for From][issue]. That doesn't cause a conflict when we `use derive_more::From`, but it _does_ cause a conflict when we import `derive_more::From` via `use internal_prelude::*`. So as a solution, we just import `derive_more::From` explicitly. Closes #2124 [issue]: https://github.com/rust-lang/rust/pull/144922 misc: cleanup now that `_report!` macros support fields 2025-08-18T19:45:55Z Steven Engler opara@torproject.org 2025-08-09T20:31:11Z urn:sha1:2de5c18fae7be30c4ab3c3fae520c81fb3ff74ed proto: Move the `stream` module under `client` (breaking). 2025-08-18T16:09:04Z Gabriela Moldovan gabi@torproject.org 2025-08-18T15:52:38Z urn:sha1:702e7276898d3f31e22033c5b64fea91703f3701 The `stream` module is client-specific, for the most part, so I am moving it under `client`. Later on, we will factor out the parts that can be shared with the relay implementation. Note: this is a breaking change as the deleted `stream` module was `pub`. We could've kept the module and reexported from it the public types from `tor_proto::client::stream`, but I think it's better to have this `client` namespacing, because it makes the separation between the client and relay parts clearer.