mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.0.1 2022-09-20T13:13:31Z 2022-09-20T13:13:31Z Nick Mathewson nickm@torproject.org 2022-09-20T13:13:31Z urn:sha1:657914f7787a0ac5bdaad8c15d41a91425e1c8cf There are some places in the protocol where we have an all-zero RSA identity that does not truly represent a key, but rather represents an absent or unknown key. For these, it's better to use `RsaIdentity::is_zero` instead of manually checking for a set of zero bytes: it expresses the intent better, and ensures that the operation is constant-time. I am deliberately not introducing a more general IsZero trait here, or implementing is_zero for anything else: This is the only one we seem to need right now. We can generalize it later if we have to. 2022-08-01T16:27:53Z Nick Mathewson nickm@torproject.org 2022-08-01T16:23:59Z urn:sha1:dd0a83925c7cfb944155be57327f73891cb2f52a These are not secret. 2022-07-06T13:57:45Z eta tor@eta.st 2022-07-05T10:57:10Z urn:sha1:c2e2da5dc35b2e0aa4cc17865ec4d14c725558c7 - arti#448 and arti!607 highlight an issue with upgrading `rsa`: namely, the `x25519-dalek` version previously used has a hard dependency on `zeroize` 1.3, which creates a dependency conflict. - However, `x25519-dalek` version `2.0.0-pre.1` relaxes this dependency. Reviewing the changelogs, it doesn't look like that version is substantially different from the current one at all, so it should be safe to use despite the "prerelease" tag. - The new `x25519-dalek` version also bumps `rand_core`, which means we don't have to use the RNG compat wrapper in `tor-llcrypto` as much. closes arti#448 2022-03-04T13:55:34Z Nick Mathewson nickm@torproject.org 2022-03-04T13:55:34Z urn:sha1:b6452b481215ce0963123630234b01be0c440092 We perform this operation in a bunch of places, and most of them use hex::decode(). That's not great, since hex::decode() has to do heap allocation. This implementation uses hex::decode_to_slice(), which should be faster. (In the future we might choose to use one of the faster hex implementations, but I'm hoping that this change will be sufficient to get hex decoding out of our profiles.) Part of #377. 2022-03-02T17:04:07Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-03-02T15:37:11Z urn:sha1:d1e8aa1dbda0ea00b5458bbcb765bb7214f7ad95 No functional change. 2021-12-06T20:11:03Z Nick Mathewson nickm@torproject.org 2021-12-06T20:01:29Z urn:sha1:31b385c5b20205e879a847a9331c30a37dc2e6f5 We want to only use TODO in the codebase for non-blockers, and open tickets for anything that is a bigger blocker than a TODO. These XXXXs seem like definite non-blockers to me. Part of arti#231. 2021-11-24T23:12:44Z Nick Mathewson nickm@torproject.org 2021-11-24T22:31:42Z urn:sha1:f55950ab8d86fec3c5fbe33650c4a7001f9812b3 Also fix some commonwealth spellings that had slipped in. 2021-10-29T12:39:04Z Nick Mathewson nickm@torproject.org 2021-10-29T12:39:04Z urn:sha1:1ee24ce6537373448d8fd5fb074768c6887cb90b Instead of putting a fully qualified name in the text, in most cases we should just use the short name of the type or function we're referring to. In other words, instead of saying [`crate::module::Foo`], we should typically say [`Foo`](crate::module::Foo). 2021-10-01T14:53:18Z Nick Mathewson nickm@torproject.org 2021-10-01T14:53:18Z urn:sha1:1d64e88d67b5c75bcd238b50e5c20bfc1ebbc34c 2021-08-27T13:53:09Z Nick Mathewson nickm@torproject.org 2021-08-27T13:53:09Z urn:sha1:557a0ff40b3731d4690767de27010bbeff08777d This will cause some pain for now, but now is really the best time to do this kind of thing.