Re: hash tags

On Mar 8, 2013, at 5:08 PM, PJ Eby <[email protected]> wrote:

> On Fri, Mar 8, 2013 at 4:26 PM, Donald Stufft <[email protected]> wrote:
>> On Mar 8, 2013, at 4:12 PM, PJ Eby <[email protected]> wrote:
>> 
>>> On Fri, Mar 8, 2013 at 2:52 PM, Noah Kantrowitz <[email protected]> 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

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJROmJeAAoJEG48vOkzctz6zoIP/RCUcFUzSr0iPuCks3YgZQNO
fpO3DmED0TYonKDVeKRJN6zi92RvRGIZoIod0MqQmO/yz0fMz5A6hJVO7RoG7qtk
PHw7gnieN3ydynIekyNtyw7a+hxdom796G/3fSTfnxhuhPMkT96OR5JncWkR54FL
nAwCf8WLwhq5xuJYVNo/jVoGTd9bcUgk9PFfm0cFER3VIIRpFgdJnq8hkGDvL32J
vnBTXr2+SWW1233I6sN16eOmmGVvsys5OPdE++R5/75kk9+2S4pEccAlxpq6IRmF
NAJm9unv4CvNSm+2RQywSPCJ+y3TsYBPNqAWTg1WgxAFWGXFMj/zF/r9ouGX7PYY
SYNv7jYT2k+iew8IuuiN+mAA0Pb7kds8mQW3SgsYUPFNfVEqQpokCkuESl+98LZJ
8F9TTFtjDQW2bSyrUp9cpBj9UrZAcXIvSZcrf+lYOYJqmr3E6K70l5rCCjw96PYR
Sq9FzPL2nY0MFRmRVl4QCl8Pv2CZMf7vjQw4Jo/inzhtPFn/JDminsFcsZ/3NcQb
hyGolw9JH8DT0cMwLu3XTDM1wxXhapnDGp8HFg0kIvAP95X7P0PDhbaYkgsAOpHi
zr7WIlSW+cHT1TAbT47N+16EtE1hZIHNQ+vELGeBErfYoYTUfzG9MufVamTfbWlH
1Ov+8lIOO1cLWVDu7WkR
=fvyU
-----END PGP SIGNATURE-----