mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update

Browse source
This commit is contained in:
Joey Hess 2017-02-24 17:57:21 -04:00
parent 1f0d0ab4b3
commit 634a485b50
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
1 changed files with 28 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn
View file

@ -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: