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

inheritable annex.securehashesonly

Browse source 
* init: When annex.securehashesonly has been set with git-annex config,
  copy that value to the annex.securehashesonly git config.
* config --set: As well as setting value in git-annex branch,
  set local gitconfig. This is needed especially for
  annex.securehashesonly, which is read only from local gitconfig and not
  the git-annex branch.

doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn has the
rationalle for doing it this way. There's no perfect solution; this
seems to be the least-bad one.

This commit was supported by the NSF-funded DataLad project.
This commit is contained in:
Joey Hess 2017-02-27 16:08:16 -04:00
parent 6e0e7d885c
commit e53070c1ff
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
7 changed files with 51 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -3,6 +3,8 @@ that it could be used for a SHA1 collision attack. So, a signed git commit
could point to a tree with such a key in it, and the blob for the key could
have two versions with the same SHA1.
> All issues below are [[done]] --[[Joey]]
Users who want to use git-annex with signed commits to mitigate git's own
SHA1 insecurities would like at least a way to disable the insecure
git-annex backends:
@ -82,7 +84,8 @@ Or, we can document this gotcha.
> > change their behavior, although new ones will. That's a mixed
> > blessing; it makes it harder to switch an existing repo to disallowing
> > SHA1/URL/WORM, but an accidental/malicious re-enabling won't affect
> > clones made while it was disabled.
> > clones made while it was disabled.
> > > This is done now.
> >
> > Could a repository be configured to either always disallow
> > SHA1/URL/WORM, or always allow them, and then not let that be changed?