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-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. 2022-05-24T14:54:02Z Nick Mathewson nickm@torproject.org 2022-05-18T17:26:01Z urn:sha1:95200383b52d1644d4de357c2a8a50d91fdc1021 This is an approximately minimal revision to get Builder in place; subsequent commits will clean up the API. 2022-05-03T14:03:32Z Nick Mathewson nickm@torproject.org 2022-04-27T19:20:56Z urn:sha1:85d7084d953e67e50c6a735af0e90f1f85c3f75b This required a bit of poking through the `users` crate, to mess with the user and group dbs. The original goal was to "trust the group with the same name as us", but it turned into a bit of a production, since: * We want to take our own name from $USER, assuming that matches our uid. (Otherwise we want to ask getpwuid_r().) * We only want to trust the group if we are actually a member of that group. * We want to cache this information. * We want to test this code. 2022-05-03T14:03:32Z Nick Mathewson nickm@torproject.org 2022-04-24T15:12:45Z urn:sha1:7254fc60eb69b652b01f841c2fe835208b20f362 2022-05-03T14:03:32Z Nick Mathewson nickm@torproject.org 2022-04-19T00:23:23Z urn:sha1:75633109c2a75cef0769983ec1b3d20496d1ee38 Also, explain _why_ this is pretty important. 2022-05-03T14:03:32Z Nick Mathewson nickm@torproject.org 2022-04-13T15:32:23Z urn:sha1:c4a5a49b55ef367afd45ca5855591e28e5f227f4 This crate is meant to solve #315 by giving a way to make sure that a file or directory is only accessible by trusted users. I've tried to explain carefully (in comments and documentation) what this crate is doing and why, under the assumption that it will someday be read by another person like me who does _not_ live and breathe unix file permissions. The crate is still missing some key features, noted in the TODO section. It differs from the first version of the crate by taking a more principled approach to directory checking: it emulates the path lookup process (reading symlinks and all) one path change at a time, thus ensuring that we check every directory which could enable an untrusted user to get to our target file, _or_ which could enable them to get to any symlink that would get them to the target file. The API is also slightly different: It separates the `Mistrust` object (where you configure what you do or do not trust) from the `Verifier` (where you set up a check that you want to perform on a single object). Verifiers are set up to be a bit ephemeral, so that it is hard to accidentally declare that _every_ object is meant to be readable when you only mean that _some_ objects may be readable.