mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.4 2022-01-27T22:13:38Z 2022-01-27T22:13:38Z Nick Mathewson nickm@torproject.org 2022-01-27T22:13:38Z urn:sha1:98d81716105c3bc90256a7b1533071c92d9594e1 This failure occurred because our tests use canned data to exercise the directory state functionality, and the canned consensus has suddenly become very expired. There are better fixes possible, but this is a minimal one that should get CI working on main again. 2022-01-19T13:22:42Z Nick Mathewson nickm@torproject.org 2022-01-19T13:22:42Z urn:sha1:d1c362f30873f4f937d0452fdd5d804948622770 2022-01-18T18:06:08Z Nick Mathewson nickm@torproject.org 2022-01-13T18:55:34Z urn:sha1:f34faec7d96fdb87aa84744950ac37264b215965 The interface is similar to the one exposed by `arti-client`: it internally uses postage::watch to give a series of events showing when a bootstrap status is changing. Thanks to the existing state/driver separation in the DirMgr design we don't need much new logic: each download state needs to expose (internally) how far along it is in its download, which the bootstrap code passes to the DirMgr if it has changed. I believe that in the long run, we'll probably want to expose more (or different) information here, and we'll want to process it differently. With that in mind, I've made the API for `DirBootstrapStatus` deliberately narrow, so that we can change its of its internal later on without breaking code that depends on it. (The information exposed by this commit is not yet summarized in `arti-client`.) Part of #96. 2022-01-10T15:10:41Z eta tor@eta.st 2022-01-10T15:10:41Z urn:sha1:de1b19c22a60aa7e86c56023b65b14722ac33c05 That's what I get for blindly trusting @nickm :p 2022-01-10T14:02:24Z eta tor@eta.st 2022-01-10T14:02:24Z urn:sha1:da848a1b9cb4cf6b829f24a4b7b994ba9e60b6ae Fix ticket 178: Don't use a NetDir until we have microdescriptors for all of our primary guards. Closes #178 See merge request tpo/core/arti!220 2022-01-07T18:16:06Z Nick Mathewson nickm@torproject.org 2022-01-07T18:16:06Z urn:sha1:d9b423c17f485126a3dea4de8da5c45cb03037d2 When our current consensus is getting close to being invalid (but it isn't invalid yet), we try to get a new one. So far, so good. But we had a bug: when we went to get a new consensus, we'd see that we had a perfectly fine not-yet-invalid consensus in our cache, reload it, find that it was ready, and continue! This patch fixes our behavior: If we have a usable consensus, then when we reset the bootstrapping process, we ignore any cached consensus. Fixes bug #274. 2022-01-06T20:58:43Z Nick Mathewson nickm@torproject.org 2022-01-06T19:32:54Z urn:sha1:e8e0f673367bb6e1a983e174481c5484e8245c62 This prevents a security-failure condition that could happen if our directory caches don't give us these microdescriptors, but we nevertheless decide that the directory is usable. Closes #178 2021-12-16T14:31:23Z Nick Mathewson nickm@torproject.org 2021-12-16T14:08:15Z urn:sha1:9f6e09b4d1ff7d62cb917d59d36ab946a081d103 Previously we didn't retain the value of our cache_usage field when calling reset() from GetMicrodescsState. This resolves an XXXX comment. 2021-12-16T14:28:51Z eta tor@eta.st 2021-12-16T14:28:51Z urn:sha1:e62212112ca4005fb5c8c3b220716e6f75f4fd5f Refactor directory events to use a new FlagPublisher mechanism. See merge request tpo/core/arti!188 2021-12-16T13:51:34Z Nick Mathewson nickm@torproject.org 2021-12-16T13:51:34Z urn:sha1:b5672cb2c79257cd1ac20de3474ba825cae198b5 This warning occurs if we ask for microdescriptors from our local cache, and our cache gives us something we didn't ask for. It shouldn't be possible, so let's warn when it occurs. This patch resolves an XXXX.