mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.7 2023-08-01T15:40:26Z 2023-08-01T15:40:26Z Nick Mathewson nickm@torproject.org 2023-08-01T15:40:26Z urn:sha1:3422169ff4158e56764e2f3c3d2fea31e8031fcd Vesion bumps for 1.1.7. See merge request tpo/core/arti!1458 2023-08-01T14:57:55Z Nick Mathewson nickm@torproject.org 2023-08-01T14:57:55Z urn:sha1:3acdf102c705314aec63679e97240bb7d981d1c8 These crates are at version 0.x.y, so we don't need to distinguish new-feature changes from other changes: ``` tor-basic-utils fs-mistrust tor-error tor-geoip tor-checkable tor-linkspec tor-netdoc tor-netdir tor-persist tor-ptmgr tor-hsservice ``` This crate has a breaking change, but only when the semver-breaking feature `experimental-api` is enabled: ``` tor-config ``` This crate is at version 1.x.y, but has no new public APIs, and therefore does not need a minor version bump: ``` arti ``` 2023-08-01T14:51:25Z Nick Mathewson nickm@torproject.org 2023-08-01T14:51:25Z urn:sha1:6f2ae5960393b64c1d7615d2d523e050d3bebe5a These crates had first-order breaking changes: ``` retry-error tor-keymgr tor-proto tor-hsclient tor-rtmock ``` Additionally, these broke because they re-exposed RetryError: ``` tor-circmgr ``` Additionally, these broke because they may re-expose something from tor-proto: ``` arti-client tor-chanmgr tor-dirclient tor-dirmgr tor-guardmgr ``` Additionally, these broke for other fiddly reasons: `tor-ptmgr` implements traits from tor-chanmgr, which has a breaking change above. `arti-hyper` exposes types from arti-client in its API. 2023-08-01T12:32:20Z Nick Mathewson nickm@torproject.org 2023-08-01T12:32:20Z urn:sha1:9ce6f0a0eb32051ef36bed2c65f0794a5a04421d 2023-07-24T12:17:31Z Gabriela Moldovan gabi@torproject.org 2023-07-24T10:56:18Z urn:sha1:f96298a791f696012c572a1df8396eea46d43266 2023-07-24T12:17:23Z Gabriela Moldovan gabi@torproject.org 2023-07-24T11:01:59Z urn:sha1:9c326ced816ab4bf9e3e7380f5caa6a6cb05a784 2023-07-17T14:08:38Z Nick Mathewson nickm@torproject.org 2023-07-17T14:08:38Z urn:sha1:119bb68cbc9df63f85e6af90e3148f9ef7be792a (Everything else is already on 0.11.0.) 2023-07-13T11:13:59Z Gabriela Moldovan gabi@torproject.org 2023-07-12T18:07:13Z urn:sha1:d8299e8d2f3874f28f4b39893f75fc7be6962091 Previously, the keystore config consisted of a single field in `StorageConfig`, which encoded 2 bits of information: whether the keystore is enabled, and its root directory: ``` [storage] # use this path, fail if compiled out # keystore = "/path/to/arti/keystore" # # use default path, fail if compiled out # keystore = true # # disable # keystore = false ``` This commit adds `ArtiNativeKeystoreConfig`, which will replace the multi-purpose `keystore` field. The new config will look like this: ``` #[storage.keystore] # Whether the keystore is enabled. # # If the `keymgr` feature is enabled and this option is: # * set to false, we will ignore the configured keystore path. # * set to "auto", the configured keystore, or the default keystore, if the # keystore path is not specified, will be used # * set to true, the configured keystore, or the default keystore, if the # keystore path is not specified, will be used # # If the `keymgr` feature is disabled and this option is: # * set to false, we will ignore the configured keystore path. # * set to "auto", we will ignore the configured keystore path. # # Setting this option to true when the `keymgr` feature is disabled is a # configuration error. #enabled = "auto" # The root directory of the arti keystore #path = "${ARTI_LOCAL_DATA}/keystore" ``` While `ArtiNativeKeystoreConfig` currently only has 2 fields, `enabled` and `path`, future versions of the keystore might require additional config options. 2023-07-10T13:41:30Z Gabriela Moldovan gabi@torproject.org 2023-07-10T13:20:17Z urn:sha1:9cde64c2c8b05958dd2d0a3fe88ad915e8f49123 Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1337#note_2917701 This will make it harder to accidentally return the wrong value from `Keystore::get` (the returned value is now at least guaranteed to implement `EncodableKey`). Closes #937 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 ```