On Tue, Mar 16, 2021 at 9:42 AM Christian Heimes <christian@python.org> wrote:
On 16/03/2021 16.54, Julien Palard wrote:
> Le 2021-03-16 à 15:52, Christian Heimes a écrit :
>> could you please explain your use case? Which problem are you trying to
>> solve? How would a sha256 checksum help you solve that problem?
>
> No, I'm just forwarding the surprise of a user seen on a random social
> network (I'm monitoring the python hashtag on mastodon those days).

The MD5 fingerprint is really just a checksum to detect download issues.
Any checksum would do the trick, even CRC-32. We could (and should)
replace the MD5 fingerprint with SHA-256 or SHA-512 [1].

In our case SHA-256 checksums don't provide any real benefit over MD5.

The benefit of listing the sha256 for files is that it prevents this question coming up again and again because md5 is old and rightfully on the "never use" list for many people. Even if there are situations where it is fine as an effective improvement over a CRC.
 
Security and data integrity is provided by TLS / HTTPS and optionally by
GPG signatures. The Python source code and checksums are provided by the
same server. If an attacker is able to modify the tar ball, then it's
likely they can replace the checksum information, too.

People do look at https://python.org/ to get the official checksums of the downloads at a much different time than the tarball they have lying around was downloaded.  Hosting them serves as an easy way to check the integrity of what they already got at some previous time.

Lets not let perfect be the enemy of the good here.

What do other things hosting downloads do?  I see some that list only sha256.  I see others that list both.  I don't really care which we do so long as we include something standard not red-flagged as broken due to collisions.

-gps