On Mar 8, 2013, at 5:08 PM, PJ Eby <p...@telecommunity.com> wrote: > On Fri, Mar 8, 2013 at 4:26 PM, Donald Stufft <don...@stufft.io> wrote: >> On Mar 8, 2013, at 4:12 PM, PJ Eby <p...@telecommunity.com> wrote: >> >>> On Fri, Mar 8, 2013 at 2:52 PM, Noah Kantrowitz <n...@coderanger.net> wrote: >>>> MD5 is _not_ acceptable for anything security related and we shouldn't be >>>> adding anything that increases our dependence on it. MD5's only use in the >>>> packaging world is to make people who forget that TCP has its own >>>> checksums feel all warm and fuzzy that there hasn't been _accidental_ >>>> download corruption. >>> >>> So, you're saying that someone has found a second-preimage attack >>> against MD5 that's more efficient than the current 2**127 threshold >>> established in 2009? >>> >>> "Anything security related" is pretty broad. Out of the many classes >>> of attacks on hashes, AFAIK the only class that's relevant to PyPI is >>> second preimage attacks, i.e. one where the attacker has the original >>> file and the hash, and must construct a new file that produces the >>> same hash value. >> >> Relevant to PyPI is pretty broad, and when you're developing a secure system >> you need to look past what is ok *today* and design for the next 5, 10, or >> 20 years. So even if there's no attack that can directly allow replacing the >> target file with a new one, continuing to utilize it is bad. It has a number >> of weaknesses which do not install confidence in its future security >> meanwhile there are a number of other hashes which _do_. >> >> Unless you'd rather be trying to replace hashes everywhere once it's already >> completely broken. > > We can replace it completely in a lot less than that many years, if > the new PEP-based tools can be brought to pass. Using new protocols > (e.g. the embedded signatures in wheel files) will make most of this > moot. > > What I'm against is trying to patch over the existing protocol when > what we really want is to replace it altogether. Adding hashes and > filesizes and whatnot is just gilding the existing lily, or more like > gilding the pond scum, actually. ;-)
Unless we are planning on removing the existing tooling this still matters even with the new system in place. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
