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

devblog

Browse source
This commit is contained in:
Joey Hess 2017-02-24 20:03:36 -04:00
parent 6b52fcbb7e
commit 622b3fface
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
2 changed files with 25 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/backends.mdwn
View file

@ -5,6 +5,8 @@ to retrieve the file's content (its value).
Multiple pluggable key-value backends are supported, and a single repository
can use different ones for different files.
These are the recommended backends to use.
* `SHA256E` -- The default backend for new files, combines a 256 bit SHA-2
hash of the file's content with the file's extension. This allows
verifying that the file content is right, and can avoid duplicates of
@ -20,6 +22,10 @@ can use different ones for different files.
* `SKEIN512`, `SKEIN512E`, `SKEIN256`, `SKEIN256E`
-- [Skein hash](http://en.wikipedia.org/wiki/Skein_hash),
a well-regarded SHA3 hash competition finalist.
The backends below do not guarantee cryptographically that the
content of an annexed file remains unchanged.
* `SHA1`, `SHA1E`, `MD5`, `MD5E` -- Smaller hashes than `SHA256`
for those who want a checksum but are not concerned about security.
* `WORM` ("Write Once, Read Many") -- This assumes that any file with
@ -30,6 +36,11 @@ can use different ones for different files.
It's generated when using eg, `git annex addurl --fast`, when the file
content is not available for hashing.
If you want to be able to prove that you're working with the same file
contents that were checked into a repository earlier, you should avoid
using the non-cryptographically-secure backends, and will need to use
signed git commits. See [[tips/using_signed_git_commits]] for details.
Note that the various 512 and 384 length hashes result in long paths,
which are known to not work on Windows. If interoperability on Windows is a
concern, avoid those.

13
doc/devblog/day_450__hardening_against_SHA_attacks.mdwn Normal file
View file

@ -0,0 +1,13 @@
Yesterday I said that a git-annex repository using signed commits and SHA2
backend would be secure from SHA1 collision attacks. Then I noticed that
there were two ways to embed the necessary collision generation data inside
git-annex key names. I've fixed both of them today, and cannot find any
other ways to embed collision generation data in between a signed commit
and the annexed files.
I also have a design for a way to configure git-annex to expect to see only
keys using secure hash backends, which will make it easier to work with
repositories that want to use signed commits and SHA2. Planning to implement
that tomorrow.
[[todo/sha1_collision_embedding_in_git-annex_keys]] has the details.