mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.1 2023-02-01T15:36:29Z 2023-02-01T15:36:29Z Nick Mathewson nickm@torproject.org 2023-02-01T15:36:29Z urn:sha1:7c1b6a5a81e382be6210c7e2b0aae9695ad0bef4 These crates had API or behavior changes that may affect downstream crates. Fortunately, they're all version 0.x, and don't need minor bumps for this. 2023-02-01T15:23:58Z Nick Mathewson nickm@torproject.org 2023-02-01T15:23:58Z urn:sha1:66f594a4b6fac81137886be90a7bda3687923d48 These changes influence behavior, but not effect compatibility. (If I messed up, and any crate except for `arti` has non-breaking API changes, that's still fine, since they are all version 0.x.) 2023-01-25T21:29:53Z Nick Mathewson nickm@torproject.org 2023-01-25T21:29:53Z urn:sha1:f9903789d1134f5c484fdab3d4f3d4a710e3d76e This required rewriting some of our error handling code in command-line processing, since the toml crate now displays and reports errors differently. (Admittedly, this code still is kind of ugly, but at least it is nicely hidden.) 2023-01-20T13:06:30Z Nick Mathewson nickm@torproject.org 2023-01-19T19:50:07Z urn:sha1:889206cde4ef29d7d10bda546f8ad518eb09c290 This is in lieu of upgrading to the latest base64 crate, which has a different API from the old one. Since we have to migrate either way, we might as well use base64ct everywhere. I don't think that most of these cases _require_ constant-time base64, but it won't hurt. 2022-11-30T20:10:16Z Nick Mathewson nickm@torproject.org 2022-11-30T20:10:16Z urn:sha1:38bef96b99dbf17922dc601d4250abc0368b519f We made this job easy this time around: by incrementing our MSRV, we have forced ourselves to do at least a minor bump everywhere. 2022-11-21T14:58:24Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-11-17T17:49:19Z urn:sha1:cd2070b3ba83824a1a9a9d9ba4695dd6a15dd8e8 And test cases for it, and its errors. 2022-11-21T14:58:24Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-11-18T16:32:11Z urn:sha1:589f74a78f05f0d9fbdc9844d6686b0cbb60878d This struct is going to be the principal "dictionary-style" serde representation for a bridge, and the builder, making this all in keeping with our usual approach. In this commit: * Introduce the struct (defining the serialisation) * Provide the setters (defining the Rust API) * Add success test cases (not all of the data in which is used yet) 2022-11-18T14:22:31Z Nick Mathewson nickm@torproject.org 2022-11-18T14:22:31Z urn:sha1:c666133be4e18d77e44434dccea4d432b176631e Mark bridge and PT-related APIs as non-experimental. Closes #643 See merge request tpo/core/arti!865 2022-11-18T13:53:47Z Nick Mathewson nickm@torproject.org 2022-11-16T17:44:33Z urn:sha1:471cdc77f2fdee6d17ac35dbcd50555d23e7db44 2022-11-17T17:32:57Z Nick Mathewson nickm@torproject.org 2022-11-17T17:32:57Z urn:sha1:8dfbbca4e58337878e030d183b8cba9c2e77d70a We previously had a trace message on _every_ change. That's fine, but we also want to log more important changes where the user can see them. Namely: * If we go from any other status to Reachable, we want to tell the user. (We don't want to spam them if it was already reachable.) * If we go from Untried or Reachable to Unreachable, we want to tell the user. (We don't tell them about changes from Retriable to Unreachable, since that just means that a retry attempt was not successful.) Closes #627.