mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.13 2024-01-31T15:10:36Z 2024-01-31T15:10:36Z Nick Mathewson nickm@torproject.org 2024-01-31T15:10:36Z urn:sha1:4700e9ce6c075851068fd7ba17324b3d787ff651 (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. 2024-01-25T16:17:05Z Nick Mathewson nickm@torproject.org 2024-01-25T16:17:05Z urn:sha1:829a9244a964894b7bd1bebf298a688a7ee8f513 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.) 2024-01-24T16:42:43Z Gabriela Moldovan gabi@torproject.org 2024-01-24T16:42:43Z urn:sha1:14445e8bb0f3daa9420a3330614eeb4874bf881d 2024-01-24T15:58:55Z Gabriela Moldovan gabi@torproject.org 2024-01-24T15:51:31Z urn:sha1:5050e8c367ba0fb09552d93d3878a193f45678f2 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). ``` 2024-01-24T11:22:54Z Gabriela Moldovan gabi@torproject.org 2024-01-24T10:37:37Z urn:sha1:ab5f4ce0ede67419a8f03201375c2f5b245f5564 Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1904#note_2987777 2024-01-24T11:22:53Z Gabriela Moldovan gabi@torproject.org 2024-01-23T19:05:33Z urn:sha1:b487b7e8d6dfaaf7c65ea2ea30083d87dd1e785c Part of #1166 2024-01-24T11:22:27Z Gabriela Moldovan gabi@torproject.org 2024-01-23T14:48:37Z urn:sha1:2a69c1f966f4ff9220c7f1cb1365172268ce0aa0 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 2024-01-24T11:22:27Z Gabriela Moldovan gabi@torproject.org 2024-01-23T14:42:43Z urn:sha1:bc991f922b5d0fcacd1b6c8fa7b0dd4cdc516163 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 2024-01-23T13:57:16Z Nick Mathewson nickm@torproject.org 2024-01-23T13:49:34Z urn:sha1:7248a5ee37cca562c9a46b9717b801457674eb74 Closes #1254. 2024-01-23T13:57:16Z Nick Mathewson nickm@torproject.org 2024-01-23T13:40:59Z urn:sha1:188e201622e345c220de77bf0edd006804271932