mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=main 2026-07-15T18:05:29Z 2026-07-15T18:05:29Z Jim Newsome jnewsome@torproject.org 2026-07-15T18:05:29Z urn:sha1:e4c00405e703b6e274af2e3cfb000cab5a7c7837 2026-07-02T14:37:13Z Nick Mathewson nickm@torproject.org 2026-06-09T16:52:26Z urn:sha1:0d6a39241d0010149c0f4ca26a647f3cb00f255e We put this behind a feature because we probably want to test this out before we enable it. 2026-06-09T15:36:01Z Clara Engler cve@cve.cx 2026-06-09T15:36:01Z urn:sha1:9f5752a77fb57052c06ead0eeae606831f1e8e97 This commit executes maint/add_warning with the just added change to deny string slices except in tests. I recommend auditing this by checking out the previous commit followed by running the script yourself and then verifying that the diff is identical to this commit. This commit makes cargo clippy fail. We will add exceptions in the next commit. 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 2026-05-12T20:55:43Z Wesley Aptekar-Cassels me@wesleyac.com 2026-05-07T20:06:21Z urn:sha1:a18167928901d8c88cd1cdd87346de8ad1ee42a2 When the circ-padding feature is enabled, we use maybenot, which does not yet support rand 0.10. In the meantime, enabling this feature pulls in rand 0.9. This is not ideal, but should be okay as a temporary situation. This also replaces the use of ReseedingRng (which was removed in 0.10) with the reseeding_rng crate. This is somewhat less performant, but it should be okay. 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. 2026-03-26T19:20:17Z Nick Mathewson nickm@torproject.org 2026-03-26T15:52:39Z urn:sha1:e5b0b4bcfb7b9fbdc66d359a193582cb3031c51b 2026-03-15T20:18:56Z Tobias Stoeckmann tobias@stoeckmann.org 2026-03-15T20:05:34Z urn:sha1:2173207d8b909d1afdc55adda13faac13cdded0f 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. 2026-01-27T18:20:47Z Gabriela Moldovan gabi@torproject.org 2026-01-27T18:20:47Z urn:sha1:ecc930d55ac38d9188171981f8390c4b8b43dcb8