mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.6 2023-06-30T12:42:21Z 2023-06-30T12:42:21Z Nick Mathewson nickm@torproject.org 2023-06-30T12:42:21Z urn:sha1:de13a7319b7de5a336a70f128d1904954ed77f82 Done with the commands below. The following crates have had various changes, and should get a patchlevel bump. Since they are pre-1.0, we do not need to distinguish new APIs from other changes. ``` cargo set-version --bump patch -p arti-client cargo set-version --bump patch -p safelog cargo set-version --bump patch -p tor-bytes cargo set-version --bump patch -p tor-cert cargo set-version --bump patch -p tor-circmgr cargo set-version --bump patch -p tor-config cargo set-version --bump patch -p tor-consdiff cargo set-version --bump patch -p tor-dirclient cargo set-version --bump patch -p tor-dirmgr cargo set-version --bump patch -p tor-error cargo set-version --bump patch -p tor-hsservice cargo set-version --bump patch -p tor-linkspec cargo set-version --bump patch -p tor-llcrypto cargo set-version --bump patch -p tor-netdir cargo set-version --bump patch -p tor-netdoc cargo set-version --bump patch -p tor-proto cargo set-version --bump patch -p tor-rpcbase cargo set-version --bump patch -p tor-socksproto ``` This crate has new features, but no new non-experimental Rust APIs. So even though it is post-1.0, it gets a patchlevel bump. ``` cargo set-version --bump patch -p arti ``` 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-27T15:17:52Z urn:sha1:aa5e9b1e951e23fa393f79e8324a39c5de863521 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-27T15:12:36Z urn:sha1:b466b24a1807d1d0e261a6e23418e0152f15d734 This removes the `# Availability` section from the `convert_ed25519_to_curve25519_private` and `convert_curve25519_to_ed25519_private` docs. We don't generally have this sort of section anywhere else in the codebase (we use unstable cargo-docs features to make sure items are annotated correctly). 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-26T19:42:55Z urn:sha1:32261d40060b6ac61bcf10fd5aa2e7228eb8c658 The `convert_curve25519_to_ed25519_private` and `convert_ed25519_to_curve25519_private` functions are now exported by `tor-llcrypto` if the `cvt-25519` feature is enabled. 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-26T19:40:54Z urn:sha1:9e80a206ca045a515a53bddcc52c16037391a1f8 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-26T14:47:25Z urn:sha1:94f405704f483f293297bdc611644e10b5a2ce11 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-26T14:46:11Z urn:sha1:7c44984f3d4ad0767d617f116c257ca87f5897a6 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-26T14:33:23Z urn:sha1:e06fc04b0b7cf59cacfacdc345754c1ea183a5fe 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-26T14:23:41Z urn:sha1:fa6290c0cc2d370db6f16510e2fbae6cce44effe 2023-06-27T18:23:42Z Gabriela Moldovan gabi@torproject.org 2023-06-26T14:13:05Z urn:sha1:7ecb2221a01d76e426f8676feaf7c428aed1aeab This adds a TODO explaining how convert_ed25519_to_curve25519_private will need to be audited when we upgrade to the latest x25519-dalek. This also adds a `debug_assertions` and a test that ensures `StaticSecret::from` is clamping the input (when we bump x25519-dalek, the assertions will fail, as the latest version doesn't do clamping in StaticSecret::from).