[Distutils] Proposal: drop md5 for sha256

Tarek Ziadé tarek at ziade.org
Wed Jul 4 09:47:32 CEST 2012


On 7/4/12 9:35 AM, Tarek Ziadé wrote:
> On 7/4/12 2:50 AM, PJ Eby wrote:
>> On Tue, Jul 3, 2012 at 7:33 PM, Jennings, Jared L CTR USAF AFMC 46 
>> SK/CCI <jared.jennings.ctr at eglin.af.mil 
>> <mailto:jared.jennings.ctr at eglin.af.mil>> wrote:
>>
>>     On hosts configured for compliance with U.S. Federal Information
>>     Processing Standard (FIPS) 140-2
>>     <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>, like
>>     those in some banks and, yes, the U.S. Department of Defense,
>>     cryptographic modules (such as OpenSSL, which underlies hashlib)
>>     are not
>>     allowed to calculate MD5 digests, because MD5 is no longer a FIPS
>>     Approved digest algorithm.
>>
>>
>> So if it's not a cryptographic module, it's okay?  ;-)
>>
>>     I know no one is trying here to lean on MD5 for security, but the
>>     standard says nothing about the reason why you're using MD5: just
>>     that
>>     you can't.
>>
>>     No one expects a digest algorithm to fail, and Python 2.x may not
>>     have
>>     been fixed to check for that before being frozen
>>     <https://bugzilla.redhat.com/show_bug.cgi?id=746118#c3>, so if
>>     you run
>>     an MD5 checksum on a FIPS-compliant system with an unpatched
>>     Python 2.x,
>>     the Python interpreter will segfault. (Ruby, too, had this
>>     problem and
>>     was itself only recently fixed,
>>     <http://bugs.ruby-lang.org/issues/4944>.)
>>
>>     I have to configure hosts in accordance with FIPS 140-2, so the more
>>     places I can get rid of MD5, the less headaches I have.
>>
>>
>> If we replace it with something else, then I suggest we replace it 
>> with something that's even MORE braindead than md5 so that nobody 
>> will mistake it for a secure hash.  Otherwise, we will have this 
>> exact same problem all over again when the replacement "secure" hash 
>> is disabled by a newer version of FIPS.
>>
>> The other option is simply to forego a checksum altogether and assume 
>> same size = same file.  Honestly, I don't remember why we cared about 
>> detecting such modifications in the first place: neither PEP 376 nor 
>> 262 explain why, and 376 doesn't explain why it went with md5 instead 
>> of sha1 (as in PEP 262).
>
> I wanted to be able to offer a way for installers to detect that a 
> file was changed to avoid deleting it for instance, and issue a 
> warning to the user -- or maybe give a chance to the installer to save 
> a copy of the file somewhere.
>
> I picked md5 because I wanted it brain dead and could not imagine that 
> would  be an issue somehow. Maybe zlib.crc32 would be a better choice.

Oh let's do a fletcher checksum ! This one should be universally 
authorized by any system

grabbed on the web:

def fletcher(path, modulus=255):

     with open(path) as f:
         data = f.read()
     numbers = map(ord, data)
     a = b = 0
     for number in numbers:
         a += number
         b += a
     a %= modulus
     b %= modulus
     return hex((a << 8) | b)[2:].upper().zfill(4)



>
> If we remove the hash, oh well. no big deal I guess. If an installer 
> wants to add this feature it can maintain hashes itself.
>
>
>>
>>
>>
>> _______________________________________________
>> Distutils-SIG maillist  -Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120704/527cf018/attachment-0001.html>


More information about the Distutils-SIG mailing list