[Catalog-sig] hash tags

PJ Eby pje at telecommunity.com
Fri Mar 8 23:08:52 CET 2013

On Fri, Mar 8, 2013 at 4:26 PM, Donald Stufft <donald at stufft.io> wrote:
> On Mar 8, 2013, at 4:12 PM, PJ Eby <pje at telecommunity.com> wrote:
>> On Fri, Mar 8, 2013 at 2:52 PM, Noah Kantrowitz <noah at 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

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.  ;-)

More information about the Catalog-SIG mailing list