Python release announcement format
Hi, I'm not familiar with the Python release process, but looking at the latest release https://www.python.org/downloads/release/python-3101/ we can see MD5 is still used ... which doesn't sound right in 2021 ... especially since we proved it's possible to build different .tar.gz that have the same MD5 https://twitter.com/ydroneaud/status/1448659749604446211 https://twitter.com/angealbertini/status/1449736035110461443 You would reply there's OpenPGP / GnuPG signature. But then I would like to raise another issue regarding the release process: As the announcement on comp.lang.python.announce /python-announce-list@python.org doesn't record the release digest / release signature, the operator behind https://www.python.org/downloads/release/python-3101/ are free to change the release content at any time, provided there's a valid signature. And there will no way for us to check the release wasn't modified after the announcement. It would be great ifhttps://www.python.org/dev/peps/pep-0101/ would be improved from the naive: "Write the announcement for the mailing lists. This is the fuzzy bit because not much can be automated. You can use an earlier announcement as a template, but edit it for content!" to require the release announcement to record release archives digests as SHA-2 256 (added point if the announcement is signed), or the armored OpenPGP signatures (but's that a lot of base64 characters). Should I open a bug for this issue ? Regards. -- Yann Droneaud OPTEYA
On 14/12/2021 11.56, Yann Droneaud wrote:
Hi,
I'm not familiar with the Python release process, but looking at the latest release
https://www.python.org/downloads/release/python-3101/
we can see MD5 is still used ... which doesn't sound right in 2021 ... especially since we proved it's possible to build different .tar.gz that have the same MD5
https://twitter.com/ydroneaud/status/1448659749604446211 https://twitter.com/angealbertini/status/1449736035110461443
You would reply there's OpenPGP / GnuPG signature. But then I would like to raise another issue regarding the release process:
As the announcement on comp.lang.python.announce /python-announce-list@python.org doesn't record the release digest / release signature, the operator behind https://www.python.org/downloads/release/python-3101/ are free to change the release content at any time, provided there's a valid signature. And there will no way for us to check the release wasn't modified after the announcement.
It would be great ifhttps://www.python.org/dev/peps/pep-0101/ would be improved from the naive:
"Write the announcement for the mailing lists. This is the fuzzy bit because not much can be automated. You can use an earlier announcement as a template, but edit it for content!"
to require the release announcement to record release archives digests as SHA-2 256 (added point if the announcement is signed), or the armored OpenPGP signatures (but's that a lot of base64 characters).
I would also argue that OpenPGP signatures are a bad solution in 2021. PGP has not aged well and GnuPG tool has flaws. Better, more modern options like sigstore are still under development, though. We could (and maybe should) provide a SHA256 tag file (sha256sum --tag) and sign it with OpenGPG. The signature of a sha256 checksum file is as good as signing the files directly. Christian
On Tue, Dec 14, 2021 at 11:56:09AM +0100, Yann Droneaud wrote:
Hi,
I'm not familiar with the Python release process, but looking at the latest release
https://www.python.org/downloads/release/python-3101/
we can see MD5 is still used ... which doesn't sound right in 2021 ... especially since we proved it's possible to build different .tar.gz that have the same MD5
Please ignore my ignorant question, but what is the actual threat you are concerned about here? Anyone who gains access to the Python web site sufficient to smuggle in a different .tar.gz file will surely also be able to just change the checksum on the website to whatever they want. It doesn't matter what the checksum is or how strong it is, MD5 or SHA256 or any other checksum. An attacker who can change the file can change the checksum to match it. And both the download and the webpage listing the checksum are over https. If we don't trust https, the whole internet is broken and changing to a stronger checksum won't help. A hypothetical MITM attacker capable of breaking https and injecting new content into the download file can likewise change the checksum. Checksums are, as far as I understand it, only good for verifying data integrity against download errors, not malicious attack. And for that, MD5 is more than sufficient. Have I missed something? -- Steve
On Tue, Dec 14, 2021 at 9:06 AM Yann Droneaud <ydroneaud@opteya.com> wrote:
Hi,
I'm not familiar with the Python release process, but looking at the latest release https://www.python.org/downloads/release/python-3101/
we can see MD5 is still used ... which doesn't sound right in 2021 ... especially since we proved it's possible to build different .tar.gz that have the same MD5
https://twitter.com/ydroneaud/status/1448659749604446211https://twitter.com/...
You would reply there's OpenPGP / GnuPG signature. But then I would like to raise another issue regarding the release process:
As the announcement on comp.lang.python.announce / python-announce-list@python.org doesn't record the release digest / release signature, the operator behindhttps://www.python.org/downloads/release/python-3101/ are free to change the release content at any time, provided there's a valid signature. And there will no way for us to check the release wasn't modified after the announcement.
For source archives, one can diff the contents of the source download vs those of the equivalent tag in the git repository. For binaries, well, there's already a ton of trust involved in accepting a binary from anyone. But agreed having the currently secure hashes in the announcement email would be good.
It would be great if https://www.python.org/dev/peps/pep-0101/ would be improved from the naive:
"Write the announcement for the mailing lists. This is the fuzzy bit because not much can be automated. You can use an earlier announcement as a template, but edit it for content!"
to require the release announcement to record release archives digests as SHA-2 256 (added point if the announcement is signed), or the armored OpenPGP signatures (but's that a lot of base64 characters).
Should I open a bug for this issue ?
Makes sense, it is a pretty small change to make to the announcement format. Filed. https://bugs.python.org/issue46077 -gps Regards.
-- Yann Droneaud OPTEYA
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6NI6V7DH... Code of Conduct: http://python.org/psf/codeofconduct/
Hi,
Have I missed something?
Having the SHA-2 256 in the release email makes it a bit more immutable: my mailbox is not reachabable by the same people that can replace the release archives on the server. Let's say it's adding a second factor of trust. Regards. -- Yann Droneaud OPTEYA
Hi, Le 15/12/2021 à 02:42, Gregory P. Smith a écrit :
On Tue, Dec 14, 2021 at 9:06 AM Yann Droneaud <ydroneaud@opteya.com> wrote:
Should I open a bug for this issue ?
Makes sense, it is a pretty small change to make to the announcement format. Filed. https://bugs.python.org/issue46077
Thanks, you transcribed my thought perfectly ! -- Yann Droneaud OPTEYA
On Sun, Dec 19, 2021, 11:49 AM Steven D'Aprano
And both the download and the webpage listing the checksum are over https. If we don't trust https, the whole internet is broken and changing to a stronger checksum won't help. A hypothetical MITM attacker capable of breaking https and injecting new content into the download file can likewise change the checksum.
I think the attack is Mallory can influence Alice to use an installer obtained from somewhere else (e.g. a caching proxy, a shared drive, a thumb drive, embedded in an OS distribution, etc). As "assurance" Mallory tells Alice to validate the installer against the hash published on python.org, which Mallory has not compromised.
participants (5)
-
Christian Heimes -
David Mertz, Ph.D. -
Gregory P. Smith -
Steven D'Aprano -
Yann Droneaud