mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.4.0 2022-05-27T13:01:20Z 2022-05-27T13:01:20Z Nick Mathewson nickm@torproject.org 2022-05-27T13:01:20Z urn:sha1:b232365a75249d6f767127feb2a47286f9ece762 I followed the following procedure to make these changes: * I used maint/changed_crates to find out which crates had changed since 0.3.0. * I used grep and maint/list_crates to sort those crates in topological (dependency) order. * I looked through semver_status to find which crates were listed as having semver-relevant changes (new APIs and breaking changes). * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no changes. For those crates, I incremented their patch-level version _without_ changing the version that other crates depend on. * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no obvious breaking changes. * I treated all crates that depend on `arti` and/or `arti-client` as having breaking changes. * I identified crates that depend on crates that have changed, even if they have not changed themselves, and identified them as having a non-breaking change. * For all of the crates, I used `cargo set-version -p $CRATE --bump $STATUS` (where `STATUS` is `patch` or `minor`) to update the versions, and the depended-upon versions. 2022-05-27T12:52:44Z Nick Mathewson nickm@torproject.org 2022-05-27T12:52:44Z urn:sha1:45d21d2520cf083000e4384242f33796186de29b These crates had only clippy fixes that do not affect their behavior: tor-bytes tor-cell tor-events tor-linkspec tor-netdir tor-socksproto This crate only had the cargo-husky dependency removed, which does not affect compatibility: tor-llcrypto Since these changes have no compatibility effects, it is not necessary to bump the versions of these crates which other crates depend on. 2022-05-27T12:30:27Z Nick Mathewson nickm@torproject.org 2022-05-27T12:30:27Z urn:sha1:f17c9083da1bc7aed7f00d1d54c1fd4fd23aed82 2022-05-26T10:40:43Z Ian Jackson iwj@torproject.org 2022-05-26T10:40:43Z urn:sha1:4bf87d61ca94648a7af220342303748f1ae1d1b3 Break TorClientConfig out of ArtiConfig and warn on unknown config keys Closes #459 and #417 See merge request tpo/core/arti!529 2022-05-24T19:14:57Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-24T18:48:13Z urn:sha1:9c88158740f85bd5a9c010947dc5707e897e5849 2022-05-24T19:14:57Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-24T18:35:00Z urn:sha1:865ae13502e5f72b13f078dd5ab937742c34dff4 This turns out to need quite a complicated algorithm. 2022-05-24T19:08:01Z Nick Mathewson nickm@torproject.org 2022-05-24T19:08:01Z urn:sha1:af54b99b40945812a54875e510db05f6d0149126 2022-05-24T14:54:02Z Nick Mathewson nickm@torproject.org 2022-05-20T19:15:56Z urn:sha1:12f2a47fcb42ea3ccf3456a034dbdec82a8f0953 We support all of the following (in TOML notation): ``` user = "rose" # by name user = 413 # by ID user = false # no user user = ":current" # A 'special' user. user = { name: "rose" } user = { id: 413 } user = { special: ":none" } user = { special: ":current" } ``` 2022-05-24T14:54:02Z Nick Mathewson nickm@torproject.org 2022-05-18T20:29:23Z urn:sha1:9dd7b99de1b8bf8625cf6de93770dda25fe2823b The Group and User (de)serialization is pretty ugly, and I can't vouch for the correcness of MistrustBuilder. I will seek feedback before I proceed. 2022-05-24T14:54:02Z Nick Mathewson nickm@torproject.org 2022-05-18T18:36:24Z urn:sha1:330582a142e30a80fe5f62af043955ca7373b7e7 This will help make the actual configuration more serializable, I hope.