diff options
author | Joey Hess <joeyh@joeyh.name> | 2017-02-24 17:57:21 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2017-02-24 17:57:21 -0400 |
commit | 4e8d9714a31987f879b4cad5c2b394386d02a829 (patch) | |
tree | 8a9aa264800d45dec4f0d4d45e01a7d07ab81bea /doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn | |
parent | a9603a022f086e0b0a2e5b4d9d1b38aaa672cd17 (diff) |
update
Diffstat (limited to 'doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn')
-rw-r--r-- | doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn index 013d66a1c..7bb23a007 100644 --- a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn +++ b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn @@ -31,6 +31,34 @@ warn about such a mistake. Perhaps, then, the config setting should be turned on by `git annex init`? Or, we can document this gotcha. +> I've done some groundwork for this, but making git-annex not accept +> insecure keys into the repo at all requires changing file2key, +> which is a pure function that's used in eg, instances for serailization. +> +> So, how to make it vary depending on git config? Can't. Alternative +> would be to add lots of checks everywhere a key is read from disk +> or network, which feels like it would be a hard security boundary to +> manage. +> +> It doesn't really matter if content under an insecure key is in the +> repo, as long as there's not a signed commit referencing such a key. +> So, we could say, this is up to the user constucting a signed commit, to not +> put such keys in the commit. +> +> Or, we could use the pre-commit hook, and when +> the config setting disallows insecure keys, make it reject commits +> that contain them. But, if a past commit added a file using an insecure +> key, and the current commit does not touch it, should it be rejected? +> Rejecting it would then require a somewhat expensive look at the tree +> being committed. +> +> The user might be merging a branch from someone else; there seems no +> git hook that can sanity check a fast-forward merge. +> +> Perhaps leave it up to the person making signed commits to get it +> right, and make git annex fsck warn about such keys? That seems +> reasonable. --[[Joey]] + ---- A few other potential problems: |