Leaving aside for a moment the consequences in general of the presumed
imminent SHA1 collapse (and some of the valid points already made by Linus
regarding Git):
If FOSSIL will refuse (and I actually tried it with those two same SHA1
PDFs) to accept a file (commit, push, pull) with the same SHA1 as any of
those already in the repo (not sure about the unversioned case, however),
how is it possible for someone to inject a 'bad' file with the same SHA1 as
a 'good' file already in the repo?
The only ways I can imagine (and please add more if you see them) are:
* Deconstruct the repo, replace the specific file(s) with the 'bad' one(s)
and reconstruct. But, this would be in the user's local copy, and s/he
would not be able to push those changes to the other side (again, because
the given SHA1 already exists, and the file with the same SHA1 will not be
retransmitted/reloaded). The injection will not propagate beyond the
attacker's machine.
* Know the 'good' file before it's actually committed, prepare a 'bad' same
SHA1 replacement, and commit it before the 'good' has a chance, locking it
out. (Rather impossible even for clairvoyant people -- and even if, it
would most likely be noticed more easily than replacing a dormant file
nobody bothers with!)
* Be the administrator of a site (like chiselapp for example -- I do not
mean to insinuate anything, I simply do not know of another public example)
and go through the deconstruct-replace-reconstruct process replacing good
with bad. This is the only scenario I see which will affect the general
public -- specifically, those cloning the injected repo from scratch.
However, this again (because of no same SHA1 reloading) will not affect the
local copies of the contributors, when pulling/syncing -- or any of the
clones done before the injection. This is the only one I would worry about
at a theoretical level.
So, unless my assumptions above are incorrect, how urgent is the need to
transition away from SHA1?
Also, the two example PDF files with the same SHA1 still have different MD5
which fossil apparently already uses, and this (MD5) could be used as an
alternate verifier for each artifact without changing anything else. I
believe it will be really-really difficult (for the foreseeable future at
least) for someone to come up with a 'bad' file with both SHA1 and MD5 being
the same. Don't tell me MD5 is broken. One would still need to match both
SHA1 and MD5 to inject -- not easy!
I'm certainly not against transitioning to a more secure hash *eventually*
but I doubt there is such an immediate need (until the Easter deadline, for
example) for making what seems to be a rather serious update that (and this
my biggest concern) may introduce (an avalanche[?] of) bugs, and possibly
even risk the integrity of our current repos until fully bug-free. (I for
one would be reluctant to try it for actual work until enough other people
have used it for some time without problems.) So, I think it could be done
in a more relaxed timeframe that will also give time to brainstorm the best
possible general solution that will work easily even in the event of another
hash function replacement in the future (e.g., what if SHA3 is already being
prepped by Google for summer announcement?) while maintaining backwards
compatibility to the greatest extent possible. It's also interesting to
take some time to see how others will try to deal with this problem and get
ideas.
As for the proposal, although it sounds OK on first reading, the 'unknowns'
are a bit worrisome, particularly the syncing between different versions --
you can't really get the whole population to switch at the exact same time.
And, I'm not sure it's the minimum (i.e., less chance for new bugs) solution
possible. I believe the example I gave with the MD5 is safe enough
temporary 'hack' for the foreseeable future with less possibility of bugs as
it will not switch to a new hash, simply use the second one for extra
verification (and it doesn't have to be MD5, you can use SHA3 but in a
similar context -- simply MD5 is already there).
My 0.01 eurocent!
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
