mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.5.0 2026-03-15T20:18:56Z 2026-03-15T20:18:56Z Tobias Stoeckmann tobias@stoeckmann.org 2026-03-15T20:05:34Z urn:sha1:2173207d8b909d1afdc55adda13faac13cdded0f 2024-08-19T16:12:57Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-19T15:13:36Z urn:sha1:5c324fa3bc77dacdbc7aafdbc1fe89e59237c47d 2022-12-20T13:31:47Z Emil Engler me@emilengler.com 2022-12-20T13:31:47Z urn:sha1:8579bc66a8959c0731182f94dd6c1c575529eb14 This commit introduces a consistency to the summary line of all README.md files in each and every crate. 2022-10-12T14:26:52Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-10-12T13:52:46Z urn:sha1:99f4511f1e5e558d3faa219292c7d16e467443df Add fn main wrappers to allow use of ?. Add ,no-run to test cases that fail due to accessing the filesystem. 2022-08-31T15:08:03Z Nick Mathewson nickm@torproject.org 2022-08-31T15:08:03Z urn:sha1:8b6f4cc69d3dd4fac9c56eb297101a245e157732 2022-05-25T20:25:58Z trinity-1686a trinity@deuxfleurs.fr 2022-05-25T15:37:19Z urn:sha1:b380c25e6637b2cf48239eea8c4a3707eb3aa67e 2022-05-06T13:51:11Z Nick Mathewson nickm@torproject.org 2022-05-06T13:51:11Z urn:sha1:9447e6935551a4d3824dede6016e1eac09b77b53 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.