python devs are planning to stop signing with gpg and switching to sigstore
Python developers started to discuss PEP-761 [1], which is about stop signing Python release tarballs with GPG and switching to sigstore. The discussion on discuss.python.org [2] grew to rather large one, including Fedora and openSUSE maintainers strong opposition to using Python-based sigstore and prefering compiled version [3] and requiring offline verification [4] (also supported by the Gentoo maintainer [4]). Hopefully there is also alternative Go client [5]. Similar discussion started on Debian Python list [6]. The thing which runs through my mind is whether we as whole openSUSE don’t want to switch to sigstore for security of our packages as well. What do you think? Best, Matěj [1] https://peps.python.org/pep-0761/ [2] https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signature... [3] https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signature... [4] https://github.com/sigstore/sigstore-python/issues/483 [5] https://github.com/sigstore/sigstore-go/ [6] https://lists.debian.org/debian-python/2024/09/msg00066.html -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Fascism is the stage reached after communism has proved an illusion. -- Friedrich von Hayek
Hi Matěj, On 10.10.24 21:13 Matěj Cepl wrote:
Python developers started to discuss PEP-761 [1], which is about stop signing Python release tarballs with GPG and switching to sigstore. The discussion on discuss.python.org [2] grew to rather large one, including Fedora and openSUSE maintainers strong opposition to using Python-based sigstore and prefering compiled version [3] and requiring offline verification [4] (also supported by the Gentoo maintainer [4]). Hopefully there is also alternative Go client [5]. Similar discussion started on Debian Python list [6].
Interesting.
The thing which runs through my mind is whether we as whole openSUSE don’t want to switch to sigstore for security of our packages as well. What do you think?
I have not yet seen tarballs being signed with sigstore, only compiled binaries. So I am not sure how much use it would bring to support having sigstore functionality integrated like currently with GPG (where having a keyring in the package lets OBS check the integrity of the tarball). Or are you talking about signing the built RPMs with sigstore? Kind Regards, Johannes
On Thu, Oct 10, 2024 at 09:13:38PM +0200, Matěj Cepl wrote:
Python developers started to discuss PEP-761 [1], which is about stop signing Python release tarballs with GPG and switching to sigstore. The discussion on discuss.python.org [2] grew to rather large one, including Fedora and openSUSE maintainers strong opposition to using Python-based sigstore and prefering compiled version [3] and requiring offline verification [4] (also supported by the Gentoo maintainer [4]). Hopefully there is also alternative Go client [5]. Similar discussion started on Debian Python list [6].
The thing which runs through my mind is whether we as whole openSUSE don’t want to switch to sigstore for security of our packages as well. What do you think?
Hello, if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service. While individual developer have varying awareness of good security practices and their keys get compromised from time to time this is replaced by central keystore that is one huge target for all attacks. This is a nice example of diseconomy of scale. While individual developers are not particularly difficult to attack the reward for compromising one developer key is low. This single point of failure is much more rewarding target, and while they may have better security practices than the average Joe Coder the attacks that they need to fend off will likely be way more common and more sophisticated as the service becomes more important. There is nothing 100% reliable, think of what will happen when the sigstore service fails, and what the failure modes could be: - DoS making it and the certificate registries unavailable - compromise that is discovered immediately but requires full rebuild of the service and user account data - compromise that is not discovered immediately and puts all software signed by sigstore in past weeks/months into question While the service aims at mitigating 'typo squatting' AFAICT it in fact blesses typo squatters with a veneer of 'cryptographic validation'. With all keys ephemeral and only tied to any package release by the metadata provided by the service anyone can generate a key for their typo squat release. After there has been a lot of talk on how the central package repositoris like NPM and the python and rust equivalents are single point of failure for the respective ecosystem (left-pad anyone?) as well as rewarding targets for low-tech attacks, the ansswer is: make more critical services centralized. What could possibly go wrong? This push towards centralization kind of rests on the 'messiah' rhetoric along the lines 'Individual users cannot be trusted to do/decide this themselves, we will do it for them'. Compare with gnuk project that makes key storage affordable, reasonably secure for individual use, and intelligible to the general user. https://blog.danman.eu/2-usb-crypto-token-for-use-with-gpg-and-ssh/ Thanks Michal
On Fri Oct 11, 2024 at 12:52 PM CEST, Michal Suchánek wrote:
if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service.
I don’t think it is only about centralization/decentralization (or at all). Just duck it and you get plenty of pages like [1] with a long list of gripes against PGP/GPG on purely technical basis. I have also learned about the other alternative for GPG from the OpenBSD universe, signify [2], which may be more relevant for the operating system distribution. However, technical aspects of this religious war go a way over my head. Best, Matěj [1] https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ [2] https://www.openbsd.org/papers/bsdcan-signify.html -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 No matter what happens in the kitchen, never apologize. -- Julia Child
On 2024-10-13 08:58, Matěj Cepl wrote:
On Fri Oct 11, 2024 at 12:52 PM CEST, Michal Suchánek wrote:
if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service.
I don’t think it is only about centralization/decentralization (or at all). Just duck it and you get plenty of pages like [1] with a long list of gripes against PGP/GPG on purely technical basis.
I have also learned about the other alternative for GPG from the OpenBSD universe, signify [2], which may be more relevant for the operating system distribution. However, technical aspects of this religious war go a way over my head.
The network of GPG key servers has been effectively out of service for several years, since the DOS attack started around 2019 or 2020. Keys submitted to one server do not get propagated to other servers. For reference, google "DOS attack on GPG key servers". Example: https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e SKS Keyserver Network Attack: Consequences https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f SKS Keyserver Network Under Attack https://access.redhat.com/articles/4264021 CVE-2019-13050: Certificate spamming attack against SKS key servers and GnuPG I do not know what to use as an alternative, or if there is one. Package signing seems to be not very much affected, as long as we effectively use a single key server, not the network. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Sun, Oct 13, 2024 at 08:58:11AM +0200, Matěj Cepl wrote:
On Fri Oct 11, 2024 at 12:52 PM CEST, Michal Suchánek wrote:
if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service.
I don’t think it is only about centralization/decentralization (or at all). Just duck it and you get plenty of pages like [1] with a long list of gripes against PGP/GPG on purely technical basis.
GPG/PGP is supserseded for most purposes. However, for signing distributed binaries I have yet to see a proposed alternative that is actually technically at least on par with GPG/PGP.
I have also learned about the other alternative for GPG from the OpenBSD universe, signify [2], which may be more relevant for the
Yes, signify might be a better alternative, specializing on one thing, not trying to do everything at once, poorly, and confusing the UI with too many features. At the same time it sounds like it may be too simplistic, and migrating a distribution like openSUSE completely to signify might be challenging. Thanks Michal
On Sun, Oct 13, 2024 at 07:36:39PM +0200, Michal Suchánek wrote:
On Sun, Oct 13, 2024 at 08:58:11AM +0200, Matěj Cepl wrote:
On Fri Oct 11, 2024 at 12:52 PM CEST, Michal Suchánek wrote:
if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service.
I don’t think it is only about centralization/decentralization (or at all). Just duck it and you get plenty of pages like [1] with a long list of gripes against PGP/GPG on purely technical basis.
GPG/PGP is supserseded for most purposes. However, for signing distributed binaries I have yet to see a proposed alternative that is actually technically at least on par with GPG/PGP.
I agree. GPG/PGP really has its issues (even on security mailing lists like distros people struggle with it, so how usable is if for others?), but package signing is a well established mechanism. sigstore has advantages, but also some serious drawbacks. Being able to authenticate to the service at the time you request the signature isn't on the same level as accessing a properly stored key. But one of the great features of signatures is that you can just do multiple. You mostly don't have that luxury when it comes to confidentiality. I would see value in the additional use of sigstore, but I would be really hesitant to drop GPG/PGP for that. Johannes -- GPG Key EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0 Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66 SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Wed, Oct 30, 2024 at 04:18:10AM +0100, Johannes Segitz wrote:
On Sun, Oct 13, 2024 at 07:36:39PM +0200, Michal Suchánek wrote:
On Sun, Oct 13, 2024 at 08:58:11AM +0200, Matěj Cepl wrote:
On Fri Oct 11, 2024 at 12:52 PM CEST, Michal Suchánek wrote:
if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service.
I don’t think it is only about centralization/decentralization (or at all). Just duck it and you get plenty of pages like [1] with a long list of gripes against PGP/GPG on purely technical basis.
GPG/PGP is supserseded for most purposes. However, for signing distributed binaries I have yet to see a proposed alternative that is actually technically at least on par with GPG/PGP.
I agree. GPG/PGP really has its issues (even on security mailing lists like distros people struggle with it, so how usable is if for others?), but package signing is a well established mechanism.
sigstore has advantages, but also some serious drawbacks. Being able to authenticate to the service at the time you request the signature isn't on the same level as accessing a properly stored key.
But one of the great features of signatures is that you can just do multiple. You mostly don't have that luxury when it comes to confidentiality. I would see value in the additional use of sigstore, but I would be really hesitant to drop GPG/PGP for that.
The signify tool proposed here is acutally aiming to replace GPG/PGP for signatures of packages, and seems somewhat workable. It throws away all unneeded features to the point of supporting one hash, ane signature algorithm, one key format, one signature format. That might be sort of OK, and there is a vague plan for changing the algorithms/formats as requirements change (to another single one supported from then on) but the practicability of the plan is not tested. Another weak point of signify is key management. It's actually a weak point of GPG as well. While in GPG the key management is overeingineered to the point of near unintelligibility in signify it is non-existent. The single key-management feature that was added after initial testing is random 16bit key identifier that makes it possible to distinguish bad signature and signature made with a different key. Thanks Michal
On Wed, Oct 30, 2024 at 03:19:02PM +0100, Michal Suchánek wrote:
On Wed, Oct 30, 2024 at 04:18:10AM +0100, Johannes Segitz wrote:
On Sun, Oct 13, 2024 at 07:36:39PM +0200, Michal Suchánek wrote:
On Sun, Oct 13, 2024 at 08:58:11AM +0200, Matěj Cepl wrote:
On Fri Oct 11, 2024 at 12:52 PM CEST, Michal Suchánek wrote:
if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service.
I don’t think it is only about centralization/decentralization (or at all). Just duck it and you get plenty of pages like [1] with a long list of gripes against PGP/GPG on purely technical basis.
GPG/PGP is supserseded for most purposes. However, for signing distributed binaries I have yet to see a proposed alternative that is actually technically at least on par with GPG/PGP.
I agree. GPG/PGP really has its issues (even on security mailing lists like distros people struggle with it, so how usable is if for others?), but package signing is a well established mechanism.
sigstore has advantages, but also some serious drawbacks. Being able to authenticate to the service at the time you request the signature isn't on the same level as accessing a properly stored key.
But one of the great features of signatures is that you can just do multiple. You mostly don't have that luxury when it comes to confidentiality. I would see value in the additional use of sigstore, but I would be really hesitant to drop GPG/PGP for that.
The signify tool proposed here is acutally aiming to replace GPG/PGP for signatures of packages, and seems somewhat workable.
It throws away all unneeded features to the point of supporting one hash, ane signature algorithm, one key format, one signature format.
That might be sort of OK, and there is a vague plan for changing the algorithms/formats as requirements change (to another single one supported from then on) but the practicability of the plan is not tested.
Another weak point of signify is key management. It's actually a weak point of GPG as well. While in GPG the key management is overeingineered to the point of near unintelligibility in signify it is non-existent. The single key-management feature that was added after initial testing is random 16bit key identifier that makes it possible to distinguish bad signature and signature made with a different key.
FWIW 16 bit key signatures are nowwhere enough, you can exhaust this keyspace in minutes and generate a signature with the same id if needed. Sorry that I had no chance to look at how python plans to do it yet, too busy days :/ Ciao, Marcus
On Wed, Oct 30, 2024 at 03:21:54PM +0100, Marcus Meissner wrote:
FWIW 16 bit key signatures are nowwhere enough, you can exhaust this keyspace in minutes and generate a signature with the same id if needed.
Sorry that I had no chance to look at how python plans to do it yet, too busy days :/
Note that python uses sigstore (what we use for container signing), not signify (what openbsd uses for package signing)... Cheers, Michael. -- Michael Schroeder SUSE Software Solutions Germany GmbH mls@suse.de GF: Ivo Totev HRB 36809, AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
On Wed, Oct 30, 2024 at 03:21:54PM +0100, Marcus Meissner wrote:
On Wed, Oct 30, 2024 at 03:19:02PM +0100, Michal Suchánek wrote:
On Wed, Oct 30, 2024 at 04:18:10AM +0100, Johannes Segitz wrote:
On Sun, Oct 13, 2024 at 07:36:39PM +0200, Michal Suchánek wrote:
On Sun, Oct 13, 2024 at 08:58:11AM +0200, Matěj Cepl wrote:
On Fri Oct 11, 2024 at 12:52 PM CEST, Michal Suchánek wrote:
if I understand this correctly intead of decentralized GPG infrastructure sigstore is a centralized service.
I don’t think it is only about centralization/decentralization (or at all). Just duck it and you get plenty of pages like [1] with a long list of gripes against PGP/GPG on purely technical basis.
GPG/PGP is supserseded for most purposes. However, for signing distributed binaries I have yet to see a proposed alternative that is actually technically at least on par with GPG/PGP.
I agree. GPG/PGP really has its issues (even on security mailing lists like distros people struggle with it, so how usable is if for others?), but package signing is a well established mechanism.
sigstore has advantages, but also some serious drawbacks. Being able to authenticate to the service at the time you request the signature isn't on the same level as accessing a properly stored key.
But one of the great features of signatures is that you can just do multiple. You mostly don't have that luxury when it comes to confidentiality. I would see value in the additional use of sigstore, but I would be really hesitant to drop GPG/PGP for that.
The signify tool proposed here is acutally aiming to replace GPG/PGP for signatures of packages, and seems somewhat workable.
It throws away all unneeded features to the point of supporting one hash, ane signature algorithm, one key format, one signature format.
That might be sort of OK, and there is a vague plan for changing the algorithms/formats as requirements change (to another single one supported from then on) but the practicability of the plan is not tested.
Another weak point of signify is key management. It's actually a weak point of GPG as well. While in GPG the key management is overeingineered to the point of near unintelligibility in signify it is non-existent. The single key-management feature that was added after initial testing is random 16bit key identifier that makes it possible to distinguish bad signature and signature made with a different key.
FWIW 16 bit key signatures are nowwhere enough, you can exhaust this keyspace in minutes and generate a signature with the same id if needed.
The ID is not a security feature, it's a key management feature. That is if you have a several dozen keys needed to verify submissions for a typical medium sized project such a BSD based OS the ID is used to detect that you are using the wrong key to verify the signarute, nothing else. It is not inteded to be world-wide unique identifier for the key, and cannot be. Similar to how prefix of the SHA1 of a key is used to identify the key in many GPG-related applications but it is not a globally unique identifier. Thanks Michal
participants (7)
-
Carlos E. R. -
Johannes Kastl -
Johannes Segitz -
Marcus Meissner -
Matěj Cepl -
Michael Schroeder -
Michal Suchánek