On Wed, 2014-10-15 at 15:18 -0400, Joey Hess wrote: > I've talked about this with the git developers before, and while they > seemed to have some ideas for how to handle a conversion to a different > hash, they're not keen on doing it until forced by SHA1 being more > broken than it is now. Well,... I guess one could foresee that this will sooner or later become an issue, right after git came out :-( Hopefully, they will make this generic in the future... and ideally retain the old IDs as well (but not using them on verification), so that textual references to old commit IDs can still be used. > I think that's a pity, especially because they could be adding a more > secure hash to git now, and use both hashes, and avoid a massive flag > day later. Yep,... and as you said,... they rather seem to want to wait till the last minute... :( Really sad, especially since it was always also pointed out to be such a great security benefit of git... > Anyway, Debian obviously cannot go it on its own and change the hash > used by git, we need git to be useful for the things people use git for. Sure,... which is why I've listed git as one of the examples where we can't do much > Instead, it makes sense to adapt workflows that do not trust git hashes, > which mostly means making signed tags and commits, and checking the > signatures. This is something Debian could improve in many areas, I'm > sure. Uhm... well maybe I misunderstand you somehow,... but just trusting on some unverified hash alone was never enough as it never proved anything but integrity (not authenticity). So singing was always necessary and always will be, even with SHA3 or anything even "better". > In general, I think that Debian needs to identify upstreams that are > being proactive about dropping old crypto algos, and those that are not. Not sure if this alone is enough... but I also have no real clue on how one should actually organise such a crypto consolidation... Perhaps with a website, that tracks packages using crypto, marking which known-to-be-vulnerable stuff they still use/allow, which we-rather-want-to-avoid-it-even-if-not-yet-broken stuff they use/allow... and what their defaults in terms of algos are Right now the whole seems like a big haystack to me,... sure it's easy to talk about the big browsers,... but finding all the countless small programs/libs which do https/TLS/SSL/etc... some of them even ignoring certificate validations per default... > Major browsers, openssh upstream, etc are going to be more on top of > this than we are, and make better decisions. Aha,... well I can't sign that... just look at Mozilla, they default to RC4 being still allowed though it's known to be broken for months now, and known to have issues for even longer. Until not so many versions ago, they even defaulted to still allow unsafe TLS renegotiations, IIRC. > Web servers probably have > user pressure to keep old crypto available, in order to support broken > clients that some users care about, and Debian might be able to improve > the defaults in such cases. IMHO the big ones like webservers and browsers, are actually "less" of an issue: I mean either you have a security conscious admin/user and then he will probably know about the most important stuff in crypto... or you have someone who doesn't care,... and well... these people often even don't upgrade their stuff regularly. I'm not saying that it wouldn't be great if we could ship with better defaults (and disable broken/questionable stuff) there as well,... I just mean that I'm far more scared on all the small packages and little tools one often easily forgets about, that they may actually be a critical point in security. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature