This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Include sha256 hashes of release downloads in announcement communications
Type: Stage:
Components: Versions: Python 3.11, Python 3.10, Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: gregory.p.smith, ydroneaud
Priority: deferred blocker Keywords:

Created on 2021-12-15 01:40 by gregory.p.smith, last changed 2022-04-11 14:59 by admin.

Messages (1)
msg408579 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2021-12-15 01:40
The announcement email list (https://mail.python.org/archives/list/python-announce-list@python.org/) and other places we make announcements beyond just the release pages like https://www.python.org/downloads/release/python-3101/ should include a list of sha256 hashes of the release binaries in the announcement text.

This serves as an alternative confirmation that nothing has changed as such announcements are widely distributed and archived by independent parties and individuals and can thus convey a level of trust that a hash listed on the downloads page cannot (where an attacker would simply modify both).

Yes there is a gpg signature on the downloads. I encourage people to use that.  But this provides an alternate distributed mechanism to verify that nothing has changed at all since the release announcement.  Something a gpg signature cannot fully do (consider this protection against the possibility of new signed binary being put into its place by a compromised key/signer/builder/RM before anyone happens to notice and poke around).

A simple table of:

filename.tar.gz | sha256 hash
filename.msi | sha256 hash
filename.dmg | sha256 hash
...

At the end of the announcement email/post would suffice.

Less of an issue on source packages as those can be verified against the git repo. But it's nice for people to know if binaries change without an announcement and explanation and is easy for us to provide.

Bonus points if the release announcement email body itself is signed (if that is even feasible per our release signing GPG key management).

[context: see recent python-dev subject: Python release announcement format]
History
Date User Action Args
2022-04-11 14:59:53adminsetgithub: 90235
2021-12-15 08:49:37ydroneaudsetnosy: + ydroneaud
2021-12-15 01:40:48gregory.p.smithcreate