From: Joey Hess Date: Wed, 30 Mar 2022 16:53:35 +0000 (-0400) Subject: more thoughts X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~75^2~87 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=04f13c7d3d0da049e9083e93ba58e847a3b9024b;p=git-annex.git more thoughts This idea seems fleshed out enough to implement now. Sponsored-by: Boyd Stephen Smith Jr. on Patreon --- diff --git a/doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn b/doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn index 0c29f48144..69f7dff948 100644 --- a/doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn +++ b/doc/todo/do_not_count_trusted_repos_toward_mincopies.mdwn @@ -18,4 +18,39 @@ content in the meantime, it risks data loss. So, is it worth breaking an existing, but unsafe use case, in order to make it easier to use trust safely? +Without an answer to that question, one approach would be to add an +ultimatelytrusted level, which behaves like trusted does now. The +serialization of ultimatelytrusted would be what is used for trusted now, +so existing trusted repositories would convert to it, and no behavior would +change. The new trusted would use a different serialization, which old +versions of git-annex would be unable to parse, but parsing defaults to +semitrusted, so old versions of git-annex would behave safely. + +Then after some amount of time, users can be polled to see if they +need ultimatelytrusted, and if not it can be deprecated and eventually be +changed to be the same as new trusted. Or, a gitconfig can be added that +makes ultimatelytrusted behave the same as trusted. + +That seems like a reasonable plan. + +(I thought about just adding a gitconfig now to control which behavior +to use for trusted, but that would not be safe, if a user expects the new +trusted behavior, they could `git-annex trust` a repo, but then later +the gitconfig gets unset, or is not set in a clone.) + +---- + +A complication with implementation: Currently when checking if a drop is safe, +trusted repositories result in a TrustedCopy, and are not checked. And it +checks other repositories until it has enough other evidence that the drop +is safe. But now it would need to check some trusted repositories, +while providing TrustedCopy for ones that it has not checked. + +One way to deal with that is, check trusted repositories in amoung the +rest (in cost order). If content is present, add a LockedCopy or +a RecentlyVerifiedCopy to the evidence. If the content is not present, +add nothing to the evidence (or could add TrustedCopy, but there seems +no benefit to doing that). If the repository cannot be accessed, add +a TrustedCopy to the evidence. + --[[Joey]]