[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