Python PGP proposal poses packaging puzzles

By Joe Brockmeier
October 21, 2024

Sigstore is a project that is meant to simplify and improve the process of signing, verifying, and protecting software. It is a relatively new project, declared "generally available" in 2022. Python is an early adopter of sigstore; it started providing signatures for CPython artifacts with Python 3.11 in 2022. This is in addition to the OpenPGP signatures it has been providing since at least 2001. Now, Seth Michael Larson—the Python Software Foundation (PSF) security developer-in-residence—would like to deprecate the PGP signature and move to sigstore exclusively by next year. If that happens, it will involve some changes in the way that Linux distributions verify Python releases, since none of the major distributions have processes for working with sigstore.

PGP and sigstore

No doubt many readers already have some experience with using implementations of OpenPGP, Pretty Good Privacy (PGP) or GNU Privacy Guard (GPG), to sign and verify artifacts. PGP signatures have been used for decades to provide proof that tarballs, packages, ISO images, and so forth are genuine. The terms PGP and GPG are used interchangeably in the various discussion threads and elsewhere, but we will stick with "PGP" for simplicity's sake.

To sign an artifact, a developer needs to create a PGP key pair and publish the public key for interested parties to use to verify the signature. Anyone can create a key pair that claims to be from "Foo Project Release Manager <rm@foo-project.org>", use it to sign artifacts, and publish the public key near the artifact. Users have had to rely on published keys to judge whether the key used belongs to the person (or organization) that is supposed to have signed the artifact. The ideal scenario is being able to validate a key fingerprint via the "web of trust", but that can be difficult.

In some ways, PGP signing is part of open-source community culture. It used to be common to have signing parties at events and Linux User Group (LUG) meetings to help expand the web of trust. People would examine each others' passport or other identifying documentation, collect public-key fingerprints, and then sign each others' keys to affirm they belonged to the person in question. There are fewer key-signing parties at events these days, though they're still held at events like DebConf 2024.

The use of PGP has waned, but it is still actively used by upstream projects and Linux distributions. However, there are also many complaints about the complexity of managing and verifying PGP keys, as well as complaints about the deficiencies in the web-of-trust concept. The Linux kernel community has had to implement its own solution to maintain the kernel's web of trust in 2019, following a series of attacks on public keyservers.

Many developers would like PGP to go away, but there have been few alternatives to replace it. Sigstore is now being used by some projects to do just that. It was started by Red Hat to solve the problem of providing signatures for container images, it moved to the Linux Foundation in 2021, and then moved again to the foundation's Open Source Security Foundation (OpenSSF). The project offers several tools and services for signing, verifying, and enforcing policy based on sigstore metadata.

With sigstore, a developer does not need to create or maintain a key pair (though it is possible to do so). Instead, they only need to have an account with a provider, such as GitHub, GitLab, Google, or Microsoft, that uses OpenID Connect (OIDC) to verify identity. Note that those are the default providers, but it is possible to set up other OIDC providers. The developer then uses a client, such as cosign, that requests a certificate from the OpenID provider to verify the developer's identity. Assuming the developer authenticates successfully with the OpenID provider, a short-lived certificate is issued for signing the artifact and then the attestation is published to a public ledger called Rekor. Cosign is also used to verify signatures. The sigstore documentation has a detailed overview of the process and the various sigstore components. An open-access research paper is available for those who would like to go deeper into the concept.

In short, sigstore removes the need for developers to have, maintain, and distribute PGP keys. It replaces the web of trust with centralized authorities for verifying the identity of artifact signers. Some of the downsides are that it relies on a handful of providers and requires tooling changes for those who have automated PGP signature checking.

Proposal

Larson started a "pre-PEP" discussion on the Python forum about dropping PGP signatures on September 25. Despite its newness, he made the case that sigstore had been adopted by other major projects and services, such as the Python Package Index (PyPI) (which dropped PGP support in 2023), npm, and GitHub, and was "likely to stick around". From a technical perspective, he said it made sense for those signing artifacts as well as those verifying them:

Sigstore has the benefit of not requiring release managers to maintain and protect separate long-lived expiring secret keys to maintain the integrity of Python artifacts, instead release managers only need to maintain control of an email account (something release managers already need to do). On the verifier side, Sigstore doesn't require discovering and fetching keys which might become unavailable, out of date, etc and doesn't require downloading an artifact to verify its integrity.

After some pre-PEP discussion, Larson published a draft of PEP 761 ("Deprecating PGP signatures for CPython artifacts") for discussion on October 9, and asked downstream users of the PGP signatures to weigh in.

If the PEP is accepted, CPython would phase out PGP signatures for the next major Python release, 3.14, due in October 2025. PGP signatures would still be published for updates to earlier CPython releases until those releases reach the end of their life. So, for example, the just-released Python 3.13 will continue to have PGP signatures for each update until it is discontinued in October 2029.

In the PEP, Larson argues that providing PGP and sigstore signatures fails to give downstream projects any incentive to adopt sigstore. So long as CPython continues to provide PGP signatures, there is little motivation to adopt sigstore.

Discussion

Larson's proposal drew support from Python contributors on the forum. Hugo van Kemenade, a CPython core developer, said that he would be the first release manager (RM) to be affected by the change and was strongly in favor of it. "Sigstore looks a much better solution, we already have it in place, and I'd much rather spend my RM time on things that are more useful for our users". He also noted that he had not needed to use PGP for two decades: "since Nokia (remember them?) used to mail us Symbian (remember that?) SDKs encrypted on DVDs (remember those?)".

Steve Dower, also a CPython core developer, weighed in that PGP signatures for Windows and macOS Python builds are "entirely redundant with the native OS embedded signatures we use", but that people complained when the project stopped providing PGP signatures for those builds: "the only reason we still do them is because people shouted last time we stopped". Once signatures were reinstated, he said, the shouting stopped.

Distributions weigh in

There has been no shouting in the discussions, but there have been concerns raised by maintainers from several Linux distributions. Miro Hrončok, Fedora's Python maintainer, said that Fedora verifies PGP signatures of Python tarballs when building packages, but said there were blockers to using sigstore to do the same. Specifically, he said that sigstore was missing offline verification and that the Python sigstore components had too many dependencies.

Larson pointed to the sigstore-go client as a potential solution to both problems. The discussion also spurred work on a longstanding issue of adding offline support to the sigstore-python tool. A release with offline support was uploaded to PyPI on October 10. Sigstore's cosign does support air-gapped or offline verification, though it requires downloading the trust root ahead of time to be able to use the --offline parameter.

Debian developer Stefano Rivera admitted that Debian had not been using PGP to verify CPython, because the package maintainers never got around to setting it up, or didn't consider it important. He said that he intended to ensure PGP signatures were checked in the future, and that a lot would need to happen for Debian to be able to support sigstore:

As to sigstore, we'd need to support it in our uscan tool, to have automated verification happen. To include the signature in our source packages, as PGP signatures are, we'd need to modify dpkg-source, and possibly the archive, to support storing them. It's hard to motivate that change for a single upstream. I know there are other ecosystems supporting it, but I've never run into any doing so actively.

Despite the extra work, though, Rivera said that he thought there was agreement on goals, and it would be a matter of "convincing people that sigstore is worth the effort of implementation in Debian package tooling." He started a discussion on debian-devel about supporting sigstore, as well as other mechanisms such as SSH signatures and signify.

Debian developer Guillem Jover provided some interesting thoughts on the matter. He was disappointed in the upstream discussion:

I find this usual conflation (in the upstream discussion) of GPG (or GnuPG) as if it was OpenPGP itself rather problematic, because the OpenPGP ecosystem is way richer than that, and as such way more active, and there has been and there is lots of work going on to implement and provide more usable, intuitive, secure and modern interfaces and code [...]

He was open to exploring other technologies for signing, however. He suggested adding "partial" support for other methods, such as updating the uscan script that downloads sources and verifies signatures, but not going so far as adding support to dpkg. Rivera agreed and said that Debian might "talk about adding support to dpkg later, when we can see significant use".

Sam James, a Gentoo developer, recommended that Python continue using PGP signatures for one more release cycle to allow those downstream of Python to adapt and provide feedback:

We didn't have sigstore packaged at all before now and had to package a lot of new dependencies for it which took time. Others will surely be in the same position. We also have a lot of tooling around PGP and none for sigstore yet.

Larson thanked James for providing feedback and said that the final timeline was up to the steering council. He asked a few follow-up questions about Gentoo's timeline for starting to package 3.14, what blockers exist beyond offline verification, and when Gentoo might know what those blockers would be.

On October 12, Gentoo developer Michał Górny committed a series of patches to verify sigstore signatures for Gentoo, answering the question of when Gentoo might be able to adapt to sigstore. Hrončok said that Fedora would need to package cosign before it would be able to use it for verifying artifacts, but didn't say whether that is going to happen or not.

OpenSUSE developer Matěj Cepl brought up the topic on openSUSE's factory mailing list, and asked for thoughts on using sigstore. So far there have only been a few responses, and none have been enthusiastic about sigstore.

Next steps

The discussion is still ongoing, so it is possible that the steering council will decide to defer dropping PGP signatures to give downstream projects more time. Packagers from the major distributions have been quick to jump into this discussion, but it is asking a lot to require distributions to adapt to this change in less than 12 months. One thing that is clear from the discussions is that a few years is not enough time for a technology like sigstore to gain widespread acceptance and understanding. At least, not without forcing the conversation. Larson seems to be doing a good job of getting that ball rolling, while working collaboratively to clear obstacles from his goal of sigstore adoption.

Whether Python drops PGP signatures in 3.14 or a later release, it seems likely that it will drop them at some point in the not-so-distant future, and that Linux distributions will need to add sigstore verification to their repertoire. That will likely help drive its adoption further, which means that it's time for users of open-source software and Linux distributions to start paying closer attention to the technology and its implications.

Index entries for this article
Security	Python
Python	Packaging
Python	Security

Long-term keys are important

Posted Oct 21, 2024 15:52 UTC (Mon) by DemiMarie (subscriber, #164188) [Link] (3 responses)

Eliminating a long-term secret key means that SigStore provides much weaker guarantees than a standard digital signature does.

It’s much better to use The Update Framework, which is purpose-built for software updates and supports features like M-of-N signature requirements.

OpenPGP is absolutely terrible, but the solution needs to provide the same guarantees, not weaker ones.

Long-term keys are important

Posted Oct 21, 2024 16:24 UTC (Mon) by knewt (subscriber, #32124) [Link]

> It’s much better to use The Update Framework, which is purpose-built for software updates and supports features like M-of-N signature requirements.

From some initial reading on Sigstore, one of the technologies that it uses behind the scenes apparently _is_ TUF.

Long-term keys are important

Posted Oct 22, 2024 10:45 UTC (Tue) by opsec (subscriber, #119360) [Link]

Nit pick: Having a .io domain for that framework might cause issues in the next 5-15 years due to that TLD 8-}

Long-term keys are important

Posted Oct 22, 2024 20:00 UTC (Tue) by DimeCadmium (subscriber, #157243) [Link]

Yes, from Sigstore's site (under "threat model"):

> Under normal operation (no Sigstore compromise), verifying a “keyless” signature from user@example.com using the ExampleIdP identity provider at a given timestamp guarantees that the signature was created by a signer who successfully authenticated to Sigstore using that identity at that time.

> It does not guarantee that the signer should be able to authenticate (for instance, in the event of a compromised account, or compromised identity provider), that the signer should have signed the given message, or that the software artifact in question is “good” (see the section on “Policy” below).

Basically, you're now trusting Sigstore. Not only that, you're also trusting whatever OpenID service the person used to authenticate to Sigstore - so let's say a project uses their GitHub account to authenticate to Sigstore... the same GitHub account that can also push new updates to the project...

It's somewhere between "literally nothing but an additional point of failure" (if they authenticate to it with the same account) and "negligible added value for significant added risk" (if they use a different account).

The next step in corporate control of 'open source'

Posted Oct 21, 2024 15:54 UTC (Mon) by ballombe (subscriber, #9523) [Link] (8 responses)

So if you do not have an account on GitHub, GitLab, Google, or Microsoft, then you cannot sign your software ?

The next step in corporate control of 'open source'

Posted Oct 21, 2024 16:30 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

That's already the idea with doing uploads on pypi.

They first rendered PGP signatures useless, then removed them because nobody was using them, and made a whole show of forcing everyone to use 2FA (you generate a single globally scoped never expired token now and use that instead of your username and password), but the preferential lane for uploads is to do them directly from github's runners. I guess at some point it will be the only way, which means projects that are on other forges will have to move to one of the blessed ones to upload.

I think python is basically microsoft owned at this point.

The next step in corporate control of 'open source'

Posted Oct 21, 2024 16:59 UTC (Mon) by Nahor (subscriber, #51583) [Link] (6 responses)

From the article:
> they only need to have an account with a provider [...] that uses OpenID Connect (OIDC) to verify identity. Note that [...] it is possible to set up other OIDC providers.

Here is a list of providers:
https://en.wikipedia.org/wiki/List_of_OAuth_providers

The next step in corporate control of 'open source'

Posted Oct 21, 2024 17:44 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (5 responses)

Depends if they allow other providers. Pypi doesn't allow you to use whatever provider you like.

The next step in corporate control of 'open source'

Posted Oct 22, 2024 17:22 UTC (Tue) by Nahor (subscriber, #51583) [Link] (4 responses)

> Depends if they allow other providers.

It's in the article and the excerpt I quoted:
>> [...] Note that [...] it is possible to set up other OIDC providers.

Am I missing something!?

The next step in corporate control of 'open source'

Posted Oct 22, 2024 18:12 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (3 responses)

I am saying that I do not know how it works in this case, but for pypi uploads there is a list of accepted oidc. So using a known protocol isn't indication of openness.

The next step in corporate control of 'open source'

Posted Oct 22, 2024 19:47 UTC (Tue) by Nahor (subscriber, #51583) [Link] (2 responses)

But we are not talking about pypi. If the article didn't specify if Sigstore supports alternative OIDC providers, then sure, you could use pypi as an example of which it might be. But the article, which I assume has been researched, does say it can be changed, so what pypi does is irrelevant and all you're doing is spreading FUD.

The next step in corporate control of 'open source'

Posted Oct 22, 2024 20:04 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (1 responses)

Can you please link the sigstore documentation where it explains how to add a new OIDC? Because I've only seen mentions of google/microsoft but I could not find a documented way to add another.

The next step in corporate control of 'open source'

Posted Oct 22, 2024 20:20 UTC (Tue) by daroc (editor, #160859) [Link]

The documentation on how to add an OIDC provider to fulcio lives here.

Insecure dev machines.

Posted Oct 21, 2024 16:09 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (62 responses)

Developer machines are insecure, so we cannot trust builds done on them and then signed and uploaded.

But are microsoft's machines more trustworthy?

Insecure dev machines.

Posted Oct 21, 2024 17:15 UTC (Mon) by bluca (subscriber, #118303) [Link] (51 responses)

Well, yes? And substitute 'Microsoft' with any other entity that employs a 24/7/365 security team looking after its infrastructure, of course.

Insecure dev machines.

Posted Oct 21, 2024 17:42 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (37 responses)

In a way yes, you're right.

But also they're a gigantic company with tight contacts with a government of an imperialistic foreign power. If I said "Download this build, it's built by the Kremlin's official build agent" who would trust that?

Insecure dev machines.

Posted Oct 21, 2024 23:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (36 responses)

> If I said "Download this build, it's built by the Kremlin's official build agent" who would trust that?

If I were living in Russia, then yes?

Python Software Foundation is incorporated in the US (in Delaware), so it's not like the US can't force it to do shady stuff if the government goes rogue.

Insecure dev machines.

Posted Oct 22, 2024 11:19 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

On the whole Russians don't trust the Kremlin. In China trust in their government is very high, but in Russia it has never been like that. It's a cultural thing. So no, chances are if you lived in Russia you wouldn't trust the Kremlin either.

Insecure dev machines.

Posted Oct 22, 2024 17:25 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Uhm, Russian is one of my native languages, JFYI.

A Russian company licensed to work in Russia will probably have no problem with code signed by the Kremlin. It might be even a requirement if they are selling the software to various official services. And after all, why worry about nebulous software supply chain attacks, when the government can just send armed people into your office?

Insecure dev machines.

Posted Oct 22, 2024 20:40 UTC (Tue) by amarao (subscriber, #87073) [Link] (33 responses)

In case of GPG, web of trust can reject rogue keys, even if some specific government wants you to trust them.

Decentralization is the point of web of trust.

Sigstore brings centralization, low quality authorization (email as means of proving identity? Lol.)

Insecure dev machines.

Posted Oct 22, 2024 20:58 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (31 responses)

It's a different threat model. PGP keys can be stolen, and used surreptitiously pretty much indefinitely. There is no way to enforce 2FA or a hardware root-of-trust for PGP keys.

Cloud providers have 2FA and anomaly detection, so they can in practice detect these kinds of compromises.

> Decentralization is the point of web of trust.

There is no trust in the web of trust.

Insecure dev machines.

Posted Oct 22, 2024 21:11 UTC (Tue) by amarao (subscriber, #87073) [Link] (30 responses)

Cloud provider could do good things, or can have gag order and do bad things. I do not trust Microsoft (why should I?), and the main point of web of trust is that I decide whom I trust and whom not. Via my trust in other people trust I can get implicit trust.

Contrary, forced trust into big companies is unjustified. Check out amount of malicious drivers signed by trusted keys, signed by authorities. Check out number of rouge keys issued by CA from turkie, russia and china. Even in US Symantec signed multiple cases of malware. Why Microsoft is better? Why Microsoft at all? Why do we discuss trust in Mirosoft, which seems Linux as cancer, in discusson on Linux distributions?

Insecure dev machines.

Posted Oct 22, 2024 21:25 UTC (Tue) by bluca (subscriber, #118303) [Link] (24 responses)

> Why do we discuss trust in Mirosoft, which seems Linux as cancer, in discusson on Linux distributions?

The 90s called, they want their memes back

Insecure dev machines.

Posted Oct 22, 2024 21:30 UTC (Tue) by amarao (subscriber, #87073) [Link]

So, you are implying that they had changed their opinion and now are friends of Linux. And we shiuld trust them.

What is stopping them, right after Linux community completely hooked on them for source code and trust management, just to change their opinion once more? Did they had bad intentions toward Linux? Will they get it again?

Centralization of trust management would allow them to do simple tweaks for T&C, forbidding software they don't like, breaking distros.

They can change opinion about Linux from cancer to friends on a whim. Can they do reverse?

Insecure dev machines.

Posted Oct 22, 2024 22:00 UTC (Tue) by atnot (subscriber, #124910) [Link] (21 responses)

Indeed, Microsoft's current leadership has understood, two decades later, that supporting open source software is to their benefit. But can that be guaranteed forever? And should we really make a corporation's goodwill, which can be changed very easily, a load-bearing assumption in our ecosystem?

Insecure dev machines.

Posted Oct 22, 2024 23:41 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

This is actually a valid concern, and this proposal does not have exclusive dependence on Microsoft. Nothing stops PSF from hosting builds on other clouds, and they're not dependent on Microsoft only for OIDC.

Insecure dev machines.

Posted Oct 23, 2024 2:50 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (19 responses)

I think they understood that locking down open source on their platform is what benefits them, and that's what they are doing.

Insecure dev machines.

Posted Oct 23, 2024 9:12 UTC (Wed) by bluca (subscriber, #118303) [Link] (18 responses)

Can we please keep the dumb conspiracy theories from the 90s confined to newsy, reddit and other such low-quality forums? Thanks

Insecure dev machines.

Posted Oct 23, 2024 9:21 UTC (Wed) by amarao (subscriber, #87073) [Link] (17 responses)

Is your comment polite, respectful, and informative?
Are you saying something new that extends the conversation?

Insecure dev machines.

Posted Oct 23, 2024 13:44 UTC (Wed) by raven667 (subscriber, #5198) [Link]

I think there are a number of LWNers who happen to work for big companies like MS, Oracle, Google, FB, IBM, etc. which are the subject of various conspiracy theories and accusations of bad faith, who themselves are sometimes the originator or work on the systems people have conspiracy theories about and take these accusations of bad faith personally because they are the one being referred to, or they personally know who is being referred to, and take offense when they believe they are operating in good faith for the betterment of their project and users.

Call it like you see it (some initiatives are cynically motivated), but don't be surprised if someone's offended or you get pushback.

Evil corporations

Posted Oct 23, 2024 14:02 UTC (Wed) by corbet (editor, #1) [Link] (15 responses)

I think I can understand where bluca is coming from. If I understand, he is seeing people trash his employer for its behavior over 20 years ago, feels that the company he is working for now is different, and would like the trashing to stop. It must not be fun to be told repeatedly that you are a minion of the Evil Empire.

For the moment, Microsoft appears to be our friend. Tomorrow could be another story, but that is true of every company that works with our community. Corporations are best seen as amoral entities that are only one bad quarterly report away from a complete change of behavior. Corporate support makes all the difference, but we don't want to become too dependent on any of them.

Evil corporations

Posted Oct 23, 2024 19:01 UTC (Wed) by bluca (subscriber, #118303) [Link] (14 responses)

All of that, and even more: there can be many reasons corporations do things, and especially in engineering-led organizations whether or not there are groups of _motivated_ engineers pushing in a determinate direction sometimes matters a lot. Say for example, pushing toward embracing open source and Linux.

Evil corporations

Posted Oct 23, 2024 19:14 UTC (Wed) by amarao (subscriber, #87073) [Link] (13 responses)

The main problem with accepting 'help' from Microsoft here is that its aim is to replace the existing community-based trust system. It took decades to build the existing network, and thousands of signing parties to get it.

If we follow Microsoft's offer to swap the web-of-trust model for their auth provider (which it is, essentially), a few years later we will get to a situation where the web-of-trust is in decay (and unused).

Can you predict if Microsoft will be a 'friend' 10 years later? Exactly at the time when the last crumbs of the GPG network are removed. Won't it be the perfect moment to move from 'extend' phase to 'extinguish'? How about updating T&C to forbid certain types of activities under their auth provider? What if those forbidden activities include reverse engineering for a new protocol or a new filesystem, or, I don't know, a new proprietary communication protocol between AIs? It is forbidden, accounts are deactivated, and distributions won't 'revive antique GPG' just to support a couple of 'banned' projects.

Is it too absurd to imagine? Especially the 'extinguish' phase? Moreover, I don't think MS here is any better or worse than any big corporation. A corporation gets leverage, a corporation uses leverage to gain even more leverage.

Evil corporations

Posted Oct 23, 2024 20:57 UTC (Wed) by bluca (subscriber, #118303) [Link]

Please see https://lwn.net/Articles/995249/

Evil corporations

Posted Oct 24, 2024 4:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]

This envisions a level of thinking, planning, foresight and control that I don't think any living human actually has, let alone the executives who actually run big companies. Do you really think these people are smart enough to pull off what you describe? Have you seen them actually speak? Without some pretty clear evidence these kinds of conspiracies just don't exist, there are technical issues and maintenance issues and incentives but not multi-year plans for ...*evil*...

Evil corporations

Posted Oct 24, 2024 9:25 UTC (Thu) by farnz (subscriber, #17727) [Link] (10 responses)

Note that extrapolating from Microsoft of more than 10 years ago to Microsoft of today isn't reasonable, since 10 years ago, it changed both its CEO and its chairman - the two most senior leadership positions. It is very easy to believe that this major change in leadership, which was driven by the failure of the previous leadership to win in the market for phones and cloud computing, has completely changed Microsoft into a different company.

Hating on Microsoft because of how it behaved under previous leadership is like cheering on the SCO Group in its lawsuit against IBM because someone's taking on the bullies at Big Blue. There's no shortage of historically evil behaviour in IBM's past, but the company has changed direction since then.

Evil corporations

Posted Oct 24, 2024 9:52 UTC (Thu) by amarao (subscriber, #87073) [Link] (9 responses)

What is preventing Microsoft chaning CEO again? I look on some opensource projects and I see how pure hostility toward opensource community appears out of nothing (Hashicorp, Redis, Mongo, etc). There is not a single argument to declare that Microsoft is different then any other company.

This discussion is not about 'how bad Microsoft is', it's about replacement of true web of trust, build out of people and people trust to each other, with corporate entity, which now looks like a friend, but have 'profits' written as a goal in their memorandum of association.

If Microsoft hate sounds like a 'Linux revenge', replace Microsoft with any corporate entity. Who is the current angel in heavens? Cloudflare. Let's say it will be delegated to CF. It is the same. Now CF is the friend, but nothing preventing them from leveraging it for achieving their legal obligation toward shareholders: make profits.

Whole thread and my clamor is not about specific company, but a fact, that web of trust is been replaced with commercial companies as gatekeepers.

Evil corporations

Posted Oct 24, 2024 10:14 UTC (Thu) by farnz (subscriber, #17727) [Link] (8 responses)

Your arguments were all based on Microsoft being evil - they are no different to any other group of people, and the composition of that group has changed significantly in the last decade.

And the web of trust doesn't change this one iota; if, instead of "corporate control", you had to have a signature from a PyPI operator or someone they've trusted, you're in exactly the same position, since the PyPI operators are also a group of people who can leverage that trust to abuse you.

Fundamentally, what you're saying is that you're scared that a group that you've chosen to trust becomes untrustworthy in the future; and without some form of ability to see the future, there's no way to see whether that will, or will not, happen.

Evil corporations

Posted Oct 24, 2024 10:55 UTC (Thu) by amarao (subscriber, #87073) [Link] (5 responses)

I specifically replaced Microsoft with other company, if you missed that.

ANY commercial company is bad. They have a goal, written in their memorandum of association: generate profits. Any commercial company placing opensource above profits is violating own obligations toward shareholders (There can be goodwill or publicity reasons, but all of them must lead to higher profits, or company is not doing its job).

Therefore, entrusting already build community trust to commercial gatekeepers is trust suicide.

They are free to participate, they are free to be trusted, but only as a member of web of trust, not as their gatekeeper.

If it wasn't clear, once more: any commercial company is bad for this job, not MS specifically.

Evil corporations

Posted Oct 24, 2024 11:04 UTC (Thu) by farnz (subscriber, #17727) [Link] (3 responses)

And I pointed out that you can replace any commercial company with the PSF or the PyPI operators, or any group of people. They all have their own goals, many of which are hidden from you, and which may conflict with what you want from the service they operate.

Indeed, in many respects, Microsoft (Azure), Amazon (AWS) and Google (GCE) are perfect stewards for services like PyPI; there is more profit to be had from making it easy to write software that you then need compute resources for (which they sell for a nice markup) than there is to be had from tightly controlling the availability of software so that you don't need to buy anything from their cloud arms.

Evil corporations

Posted Oct 24, 2024 11:41 UTC (Thu) by atnot (subscriber, #124910) [Link] (2 responses)

> And I pointed out that you can replace any commercial company with the PSF or the PyPI operators, or any group of people

I realize I won't get very far with this if you believe "greediness is just Human Nature™" or other obviously incorrect post-hoc justifications, but surely you see the difference between a legal entity set up in service of a community and beholden by it's bylaws or charter by nature of its legal status to at least somewhat act in the interest of that community, and an external corporation which is practically required to be maximally extractive?
I can name a dozen examples of corporations pivoting away from FOSS just in the last few years off of the top of my head. I have yet to hear of any community foundation doing the same thing. I'm sure it's probably happened, but it's not a pattern.

Evil corporations

Posted Oct 24, 2024 13:04 UTC (Thu) by farnz (subscriber, #17727) [Link]

An external corporation is not "practically required to be maximally extractive", no more than FOSS authors are "practically required to work for free". A corporation is entirely permitted to decide that it's not worth being extractive in this area in order to increase its overall profits by making it easier to spend in another area - for example, it's perfectly OK for a cloud computing provider to not maximally extract from the supply of software in order to make more profits from cloud computing.

And I've seen many community foundations outside software simply fall apart because the people who were running them chose to stop running them for the benefit of the community, but instead ran them to extract maximum money for themselves at the expense of the community they were nominally there to support. So far, that's been rare in software mostly because foundations tend to be controlled by a set of big corporations who are all more scared of a competitor taking control than they are of not extracting maximum money from the community, whereas companies tend to be founded in place of foundations when people want to extract maximum money.

It's also worth noting in this context that the people who are deciding which signature systems to trust are Microsoft employees (among others), and if their employment forced them to be maximally profit extracting, that would be happening with the web of trust as a trust mechanism.

The real danger is not that you trust a corporate, it's when you trust only one entity; whoever controls the trusted entity controls everything. Doesn't matter who that trusted entity is (whether it be the PSF, or Microsoft), because someone wanting to extract maximum money can take control of it, and at that point you're screwed. And in this respect, sigstore itself is fine, because it already supports the concept of multiple trusted signers - the problem is only if the PSF chooses to have only Microsoft as a trusted signer, and sets itself on a course where it can't (e.g.) add GitLab, or Facebook, or TikTok as trusted signers later down the line.

Evil corporations

Posted Oct 24, 2024 20:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I guess you generate your own electricity and etch your own circuits?

The key is to make sure you're not vendor-locked. Which is true in the case of the PSF, they are not locked to MS. If Microsoft goes evil, they can just switch to another cloud provider.

Evil corporations

Posted Oct 24, 2024 11:08 UTC (Thu) by intelfx (subscriber, #130118) [Link]

Well said. Thanks.

Evil corporations

Posted Oct 24, 2024 16:00 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (1 responses)

A signature from pypi is very different from a signature for every uploader that signs their upload.

Evil corporations

Posted Oct 24, 2024 17:06 UTC (Thu) by farnz (subscriber, #17727) [Link]

In both cases, though, the issue is not whether a signature is made by a given corporation; the issue is when you only get one choice, and have to hope that it's not malicious.

In other words, I have a lot of time for your position that whatever PyPI adopts needs to support multiple sources of signatures, because only allowing GitLab, or GitHub, or Linux Foundation, or any other single party to act as the signature source is a recipe for giving that party control. I don't have a lot of time for the idea that it's inherently wrong to let any of the parties that you trust for signatures be a corporate entity.

Insecure dev machines.

Posted Oct 25, 2024 9:02 UTC (Fri) by milesrout (subscriber, #126894) [Link]

Nothing to do with the 90s at all. What Microsoft is doing here, and what they're doing with every other "open source" contribution they are making, is the same thing they've been doing for decades at this point: embrace, extend, extinguish.

Why people fall for it during the embrace phase *every single time* is beyond me.

Insecure dev machines.

Posted Oct 22, 2024 21:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> Cloud provider could do good things, or can have gag order and do bad things.

Think through it. The cloud provider (headquartered in the US) enjoys quite a few legal protections. There are also very few reasons the US government can legally force Github (or whomever) to actively _forge_ binary artifacts.

Moreover, these kinds of actions will require a willing participation of many people inside Microsoft to keep the manipulation hidden. And it'll have to be there fairly long-term. And it can be readily detected if the package uploader is not a willing participant. And of course, nobody _stops_ you from adding PGP signatures to your source code to verify its provenance.

It's so much easier to come to you personally and give you a choice: "We have planted a lot of CSAM on your laptop. Do you want to give us your PGP key and stay silent about that, or do you want to spend the next 20 years in jail?"

If you're being threatened, blink twice.

> I do not trust Microsoft (why should I?), and the main point of web of trust is that I decide whom I trust and whom not. Via my trust in other people trust I can get implicit trust.

This does not work at all. Unless you're in a cult, at least one person you trust likely also trusts Microsoft. So you also trust Microsoft.

> Check out number of rouge keys issued by CA from turkie, russia and china.

I don't believe there are many. CA Transparency is now mandatory, and these kinds of shenanigans can't be hidden.

> Why do we discuss trust in Mirosoft, which seems Linux as cancer, in discusson on Linux distributions?

You just might be in a cult.

Insecure dev machines.

Posted Oct 22, 2024 21:52 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> And of course, nobody _stops_ you from adding PGP signatures to your source code to verify its provenance.

Actually, come to think about it, if the builds are truly repeatable, you can provide PGP signatures out of band. If the Github-generated artifacts match yours, then the signatures will stay valid and can just be appended to the binary.

I don't think this is implemented right now, but I don't think adding this is going to be controversial.

Insecure dev machines.

Posted Oct 23, 2024 2:52 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (2 responses)

Well the bank crisis and so on show us that workers are willing to commit crimes without reporting them.

Also in USA being a whistleblower is very dangerous, so understandably there are few people who are willing to do that.

They can certainly come to a developer's home with a wrench, but it doesn't scale as well.

Insecure dev machines.

Posted Oct 23, 2024 5:11 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Also in USA being a whistleblower is very dangerous, so understandably there are few people who are willing to do that.

The US, for all its faults, doesn't jail people who are already in the US without at least some due process. And the US government will have to keep silencing at least dozens of people. Who are not officials or military bound to keep the state secrets.

So the scenario is not impossible, but highly unlikely. In addition, the PSF can even further mitigate the issue by using multiple cloud providers simultaneously (e.g. Gitlab and Github). Making it that much more harder to exploit.

> They can certainly come to a developer's home with a wrench, but it doesn't scale as well.

They don't need it to scale. Just one developer of a popular library is enough if they upload pre-built binaries directly. And keep in mind, this developer might be living in a far less lawful country than the US (plenty to choose from, unfortunately).

Insecure dev machines.

Posted Oct 23, 2024 7:17 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

You won't have dozens of whistleblowers if you just kill the first one.

Insecure dev machines.

Posted Oct 29, 2024 13:03 UTC (Tue) by Avamander (guest, #152359) [Link]

GPG's WoT has not practically worked for years though.

Insecure dev machines.

Posted Oct 21, 2024 17:43 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

Also I believe this is one of such occasions where you put the disclaimer that you work for microsoft.

Insecure dev machines.

Posted Oct 21, 2024 20:30 UTC (Mon) by ballombe (subscriber, #9523) [Link] (4 responses)

If you need a refresher about the state of microsoft security, I suggest
<https://arstechnica.com/information-technology/2024/05/mi...>

Insecure dev machines.

Posted Oct 21, 2024 22:28 UTC (Mon) by bluca (subscriber, #118303) [Link] (3 responses)

I'm more aware than you could possibly imagine - still better than random Joe Developer's laptop, though

Insecure dev machines.

Posted Oct 22, 2024 11:32 UTC (Tue) by ballombe (subscriber, #9523) [Link] (2 responses)

If that were true, Debian would have collapsed a long time ago...

Insecure dev machines.

Posted Oct 22, 2024 11:37 UTC (Tue) by bluca (subscriber, #118303) [Link]

Why would something being better than something else cause yet another thing to collapse?

Insecure dev machines.

Posted Oct 22, 2024 16:11 UTC (Tue) by farnz (subscriber, #17727) [Link]

Not really - one of the "open secrets" about security is that most people don't get hacked by simple luck, not because they're particularly secure.

Debian hasn't collapsed because hacking a distro developer's machine in order to insert malware into the distro packages is a high-risk, low-reward path when you compare it to faking an identity to become an upstream developer of something critical (for example). You'd not only need to hack a DD's machine, but also to do things that don't cause either the hacked DD, or another DD, to become suspicious about your actions; but something like doing an NMU to a maintained package with no clear reason is likely to get people's attention.

Insecure dev machines.

Posted Oct 22, 2024 12:02 UTC (Tue) by edeloget (subscriber, #88392) [Link] (6 responses)

I would not be so sure.

https://arstechnica.com/security/2024/01/in-major-gaffe-h...

https://arstechnica.com/security/2024/01/microsoft-networ...

https://arstechnica.com/security/2023/09/hack-of-a-micros...

All these articles refers to the 2023 MS infrastructure security failure that allows attacker to rampage through Azure for weeks ; I especially not mention severe failures in their programs and services (0-day on on premise Exchange servers, failure to fix an admin-to-kernel vuln that allowed APT groups to install rootkits on sensitive servers...) which are not fully relevant to the discussion. Yet, MS has been lambasted by at least a senator because the way it dealt with security issues (https://arstechnica.com/security/2023/07/us-senator-blast...) and that lead Sadya Natella to write some kind of apology letter (which, of course, is not called an apology letter but a "critical culture shift"; https://blogs.microsoft.com/blog/2024/05/03/prioritizing-...).

In the end, it does not tell much good of MS security practices that your CEO has to tell the world that from now on, security will be a priority. In 2024. For a global cloud provider.

The problem with centralization is that you create a highly, unique valuable target. Even if the target is strong, it will eventually be succesfully attacked one day, whatever the security engineer does (APT groups have so many ways to hack their targets, including weird moves such as fake employement meetings with current high-value employees (https://www.darkreading.com/threat-intelligence/dprk-hack...) or posing as possible recruits for high-value jobs (https://www.darkreading.com/cybersecurity-operations/free...)).

So your dev machines might be insecure, and you are surely not prepared enough to fight alone against an APT, but odds are that APT will find a centralized target way more interesting than your dev machine in the first place, even if you are a highly important developper.

Insecure dev machines.

Posted Oct 22, 2024 12:19 UTC (Tue) by bluca (subscriber, #118303) [Link] (5 responses)

> I would not be so sure.

I would - "better" does not mean "perfect". Any organization with an on-call 24/7/365 security team is better than Joe Random's laptop, even if the former sometimes fails, because when the latter fails it's just that nobody notices. Anybody who dislikes Microsoft for any reason can just pick Google or Gitlab any of the other OAUTH providers, this is not about just one specific company/organisation.

Insecure dev machines.

Posted Oct 22, 2024 13:45 UTC (Tue) by paulj (subscriber, #341) [Link]

You can't systematically attack hundreds of thousands of different software projects at source with an attack on Joe Random's laptop though.

Insecure dev machines.

Posted Oct 22, 2024 20:04 UTC (Tue) by DimeCadmium (subscriber, #157243) [Link]

No one at MS noticed either :)

Insecure dev machines.

Posted Oct 25, 2024 9:09 UTC (Fri) by milesrout (subscriber, #126894) [Link] (2 responses)

>Anybody who dislikes Microsoft for any reason can just pick Google or Gitlab any of the other OAUTH providers, this is not about just one specific company/organisation.

But I don't trust any of them. And they're central points of failure for far too much free software already. Why doesn't the PSF run a provider for this? It seems mad to use GitHub for this sort of thing.

Insecure dev machines.

Posted Oct 25, 2024 10:50 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> Why doesn't the PSF run a provider for this? It seems mad to use GitHub for this sort of thing.

Because they can't afford to? These things come with a big price tag for staff, a big price tag for equipment, a big price tag for lawyers and liability insurance, etc etc.

Would YOU step up to the plate and volunteer, knowing that you could be the target of State Sponsored Hacking, and that if you failed absolutely EVERYTHING could be on the line - sued into bankruptcy, and jailed on top?

There's a reason these things are done by big corps.

(Take why it's Microsoft that controls the secure boot keys - I gather they were the ONLY people to volunteer - the LF took one look and said "we don't have the resources". Pity they couldn't set up a trade association of computer manufacturers to do it, but it is what it is.)

Cheers,
Wol

Insecure dev machines.

Posted Oct 25, 2024 11:26 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

There should be no boot keys!

Also see: https://arstechnica.com/information-technology/2016/08/mi...

Insecure dev machines.

Posted Oct 21, 2024 17:40 UTC (Mon) by hkario (subscriber, #94864) [Link] (3 responses)

Any up to date machine you're not using for general web browsing will be more secure than developer's machines.

Insecure dev machines.

Posted Oct 21, 2024 18:38 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

It doesn't matter at all.

Insecure dev machines.

Posted Oct 22, 2024 6:21 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

Sorry, this comment was supposed to go under disclosing working for microsoft comment. I've apparently misclicked.

Insecure dev machines.

Posted Oct 21, 2024 18:44 UTC (Mon) by DemiMarie (subscriber, #164188) [Link]

Qubes OS solves that problem. Disclaimer: am a Qubes OS developer.

Insecure dev machines.

Posted Oct 22, 2024 8:40 UTC (Tue) by epa (subscriber, #39769) [Link] (5 responses)

But if a developer's PC is insecure, can we trust "has control of an email address" either? Unless they're disciplined enough to have a separate device for their mail.

Insecure dev machines.

Posted Oct 22, 2024 14:57 UTC (Tue) by mricon (subscriber, #59252) [Link]

Yes, this is kind of the key part here. If we cannot trust the developer workstation, we cannot trust any actions performed on that workstation, so sigstore's short-lived certificates don't solve this problem. They solve *other* problems, such as having a trusted public ledger and getting a proof that, at the time of the signature, the person still had credentials for that particular account and that account was active. However, if the workstation of the developer issuing sigstore certificates cannot be trusted, the signature cannot be trusted either.

Insecure dev machines.

Posted Oct 22, 2024 17:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

The idea is that the build process will happen on the Github's infrastructure, and the signature only verifies the provenance.

Insecure dev machines.

Posted Oct 22, 2024 19:43 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (2 responses)

But a compromised machine has a nice ~/.ssh directory that allows to upload whatever on github

Insecure dev machines.

Posted Oct 22, 2024 20:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It's way better than Jia Tan silently replacing your binaries just after the linking step, but before signing them with your PGP key.

Builds on GitHub instead of compromised developer machine

Posted Oct 23, 2024 8:13 UTC (Wed) by farnz (subscriber, #17727) [Link]

On the assumption that you trust GitHub, this guarantees you that the source visible on GitHub is the corresponding source for the binary built on GitHub. With a developer doing the signing, I can build a binary that does not correspond to the given source, sign it, and upload it.

Reproducible builds would, of course, be better.

Single-point-of-failure

Posted Oct 21, 2024 17:38 UTC (Mon) by paulbarker (subscriber, #95785) [Link] (16 responses)

A correction from reading the sigstore documentation.

The article says "The developer then uses a client, such as cosign, that requests a certificate from the OpenID provider to verify the developer's identity.", implying that each OpenID provider can produce an appropriate signing certificate. This suggests that there is no single-point-of-failure.

Looking at the sigstore docs, I see: "The Cosign command requests a certificate from the Sigstore certificate authority, Fulcio. Fulcio checks your identity by using an authentication protocol (OpenID Connect) to confirm your email address. If your identity is correct, Fulcio grants a short-lived, time-stamped certificate. The certificate is bound to the public key to attest to your identity. This activity is logged using the Sigstore transparency and timestamping log, Rekor."

(from https://docs.sigstore.dev/quickstart/quickstart-cosign/)

So, there is a single-point-of-failure here on the Fulcio certificate authority. I think it's important to bear that in mind when deploying sigstore.

Single-point-of-failure

Posted Oct 21, 2024 21:23 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (4 responses)

> Fulcio checks your identity by using an authentication protocol (OpenID Connect) to confirm your email address.

Huh…and how's that work for someone like me that uses a per-service email address?

Single-point-of-failure

Posted Oct 21, 2024 23:40 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Presumably, just like if you would use multiple PGP keys?

Single-point-of-failure

Posted Oct 22, 2024 13:34 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

Right…there I could cross-sign my identities and make a chain of trust. Here…how do I get `github@frobnitz` to be verification for `pypi@frobnitz`?

Single-point-of-failure

Posted Oct 22, 2024 14:47 UTC (Tue) by knewt (subscriber, #32124) [Link]

I suspect (but have not checked) that you would add pypi@frobnitz as an additional secondary email address to your GitHub account. I know for sure that you can _have_ multiple emails with GitHub.

Or if you didn't want to add that email (which I can understand), I guess you could do something like pypi-signing@frobnitz.

Single-point-of-failure

Posted Oct 22, 2024 17:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Just add the secondary email as another maintainer.

Single-point-of-failure

Posted Oct 22, 2024 5:25 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (10 responses)

Oh, this is great… it asks some random external service to sign, which asks some other random external service to… verify the eMail address…?!

This is so far removed from what most do with OpenPGP… it’s not even laughable.

And of course bound to one CA… did they not learn?

These days, federation is key, not centralisation. Kinda… like you do with OpenPGP.

Single-point-of-failure

Posted Oct 22, 2024 9:20 UTC (Tue) by kleptog (subscriber, #1183) [Link] (9 responses)

In the end it's a trust chain, whether via random people in a web of trust, or some corporate entity which is trusted to identify other users. But ownership of an email is really a poor proxy of identity, if commonly used.

The rest test would be if this can support the (in-progress) European digital identity. If it's good enough for issuing digital drivers licenses, it's got to be good enough for uploading packages. Basing everything on a few US corporates is a different kind of single point of failure.

Single-point-of-failure

Posted Oct 22, 2024 21:31 UTC (Tue) by mirabilos (subscriber, #84359) [Link]

tbh I trust my government even less, at least on digital things

Single-point-of-failure

Posted Oct 25, 2024 9:07 UTC (Fri) by milesrout (subscriber, #126894) [Link] (7 responses)

>European digital identity

Does this mean that I get to choose either to trust Microsoft, Google, and Facebook, or... Hungary?

Single-point-of-failure

Posted Oct 25, 2024 21:37 UTC (Fri) by kleptog (subscriber, #1183) [Link] (5 responses)

> Does this mean that I get to choose either to trust Microsoft, Google, and Facebook, or... Hungary?

Like I said, if banks can trust eID to allow you to open new bank accounts, sign documents and take out loans, surely it must be good enough for uploading to PyPI?

No bank is going to allow me open a bank account by authenticating with my Gmail account. I find the trust in Microsoft/Google/Facebook somewhat concerning. None of them care about your identity at all, only your credit card.

Single-point-of-failure

Posted Oct 29, 2024 8:59 UTC (Tue) by taladar (subscriber, #68407) [Link] (4 responses)

Banks just financially absorb a certain amount of risk. A 99.9% solution is good enough for them. It is not good enough for a protection of the software supply chain where a single central compromise could affect millions of systems.

Single-point-of-failure

Posted Oct 29, 2024 12:01 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> Banks just financially absorb a certain amount of risk. A 99.9% solution is good enough for them. It is not good enough for a protection of the software supply chain where a single central compromise could affect millions of systems.

As opposed to... protection of the financial supply chain where a single central compromise could affect millions of people, and billions of Euros?

Single-point-of-failure

Posted Oct 30, 2024 8:57 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

But a compromise of a single bank account won't do that.

Single-point-of-failure

Posted Oct 30, 2024 11:39 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

> But a compromise of a single bank account won't do that.

But a compromise of the central national digital identity provider that the bank (or rather, *all* banks) uses will.

Remember, this government-provided identity is sufficient for literal life-and-death (and the state forcibly stripping you of your freedom) situations.

Single-point-of-failure

Posted Oct 30, 2024 16:44 UTC (Wed) by kleptog (subscriber, #1183) [Link]

A bank only needs to verify your identity once, when the account is opened. After that they have their own login systems which have worked just fine for years. Using a government provided identity every time to log into bank account is I guess possible, but not really the goal.

And it's only for online things. Offline your physical passport trumps whatever any online system says.

Single-point-of-failure

Posted Oct 29, 2024 13:08 UTC (Tue) by Avamander (guest, #152359) [Link]

You could also choose Finland, Estonia, Latvia or any others that aren't stuck in stone age with paper signatures.

Complaining about a deprecation when you're not even using the service yet?

Posted Oct 22, 2024 7:21 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (1 responses)

I must admit that I find the Debian position of "please don't deprecate this before we manage to start using it" a bit baffling. Debian has been shipping Python for years, apparently(?) with no PGP verification at all, and nobody seems to be the least bit concerned (I don't see anyone in the thread suggesting that they're about to file a CVE or anything). So first of all, that gives you a sense of how relevant PGP really is to overall security. But the more prosaic question is this: If you only start using a feature right before it gets deprecated, as a direct result of the deprecation discussion, do you really have any leg to stand on when the feature gets deprecated out from under you?

Of course, there are several other distros who really are using PGP, and they obviously have a stronger claim here (as compared to Debian). But I am still a bit confused as to why Debian is bothering to set up a PGP-verification system that evidently has no major security benefit, and is just going to break in (at most) a few years when this proposal takes effect anyway.

Complaining about a deprecation when you're not even using the service yet?

Posted Oct 22, 2024 7:35 UTC (Tue) by pm215 (subscriber, #98099) [Link]

Looking through some of the mailing list threads I think the answer to "why start checking PGP signatures now?" is that it was an oversight and it's trivial to fix -- drop the right public key into debian/upstream/signing-key.asc in the packaging and the preexisting machinery (which Debian is using for other upstreams that provide GPG signatures) will just start doing the checks. So you might as well do that now, and be covered until the support for sigstore is rolled out, even if that's a very short timeframe. Whereas actually supporting sigstore requires engineering work, done by people other than the Python packagers, so it's going to take some time to get in place.

Is Python trustworthy when it comes to tooling?

Posted Oct 22, 2024 8:34 UTC (Tue) by taladar (subscriber, #68407) [Link]

The Python ecosystem has made so many bad and inconsistent tooling decisions over the last decade or two, are they really the right upstream project to follow with decisions like this?

Persistently perspicacious

Posted Oct 22, 2024 11:13 UTC (Tue) by stijn (subscriber, #570) [Link]

Publisher produces pleasing python packaging protection proposal pronouncement.

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 12:28 UTC (Tue) by epa (subscriber, #39769) [Link] (14 responses)

In the bad old days (before Let's Encrypt) we used to complain about certificate errors from web browsers. Surely the browser could remember the sever's public key from last time? Then only the very first connection to the site would be vulnerable to MITM attacks, and while this is surely worse than a fully authenticated connection, it's just as surely better than connecting over plain http with no encryption. You could get a large part of the benefits of encryption without depending on a money-grubbing, incompetent public key infrastructure.

For PGP we might have a similar situation. The whole "web of trust", despite the best efforts of Debian developers to hold key-signing parties, hasn't really taken off. Yet the basic technology of public-key encryption and signing is well understood. Although an attacker could get hold of the private key by compromising a developer's computer and make signed releases, that is a much higher bar than no signing step at all. So how about "the same key as last time"? In the release tarball include a file called release_keys, similar to the ssh authorized_keys file, which lists public keys allowed to make a new release. Then when a new tarball comes out and has a PGP signature alongside it, you just need to check it against the previous version.

By all means check "ownership of an email address" or whether somebody has an account on Facebook or their European digital id or whatever. Those might be appropriate steps when you are accepting the release_keys file for the first time.

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 13:17 UTC (Tue) by geert (subscriber, #98403) [Link] (1 responses)

That's called TOFU
https://en.wikipedia.org/wiki/Trust_on_first_use

Use a keypair, but skip the web of trust

Posted Nov 2, 2024 11:10 UTC (Sat) by gouttegd (guest, #106484) [Link]

> That's called TOFU

And incidentally it’s something that GnuPG has explicitly supported for nearly a decade (`--trust-model tofu`).

An often forgotten feature of the OpenPGP standard is that it is _not_ tied to any specific trust model, and certainly not to the web-of-trust, which is just one trust model among others. In fact I believe the web-of-trust is not mentioned even once in RFC 48880. It has always been possible to “skip the web of trust”.

And I think that overall, it has been hugely damaging to OpenPGP as a whole that almost everybody equates OpenPGP with the use of the web-of-trust.

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 13:21 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

> despite the best efforts of Debian developers to hold key-signing parties, hasn't really taken off

FWIW, I think this is for the better. At one point it was pointed out that the typical pattern of "check IDs and then sign keys" hangs on the ability of people to authenticate IDs of potentially very foreign entities in real time, usually without any assistance. I think I'd be "ok" at detecting fraudulent state IDs of my US state but would be totally lost on knowing what constitutes a valid passport (domestic or foreign) or other state IDs.

I'd much rather signing be associated with "I have seen this key in use with this email ID for long enough to trust the connection" than "someone I met that claimed this key ID and had a passable identification document".

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 13:34 UTC (Tue) by bluca (subscriber, #118303) [Link]

At the FOSDEM key signing party some years ago, someone used a "facsimile" passport from $somecountry. IIRC nobody noticed on the spot, and it was reported only some days after.

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 13:28 UTC (Tue) by smcv (subscriber, #53363) [Link]

> So how about "the same key as last time"?

This is effectively what is already done in Debian (and Arch, and other distros) when attempting to verify PGP signatures on a new upstream release's tarball or signed git tag, because there is often no web-of-trust trust path between the upstream release manager and the downstream packager.

In Debian it's conventional to put one or more full public keys in debian/upstream/signing-key.asc; in Arch the PKGBUILD lists public key fingerprints, with an implicit expectation that the full public key can be downloaded from "the usual keyservers" (the actual set of keyservers that is used is not rigorously specified).

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 15:53 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (4 responses)

Well with SSL the idea was that you'd verify who the person/entity behind the domain actually was in real life.

Let's encrypt effectively killed it. They just verify you can control the domain (legitimately or not) and sign whatever.

Also the check is done via HTTP, so if you can do a MITM between the domain and letsencrypt itself you can get them to sign something else :)

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 18:42 UTC (Tue) by smcv (subscriber, #53363) [Link]

> Well with SSL the idea was that you'd verify who the person/entity behind the domain actually was in real life.

Originally, yes, that was the intention, back when there were expected to be maybe a few hundred to a few thousand organizations on the internet; but that verification scales really poorly (and requires some human judgement in the loop, and is vulnerable to social engineering, and can't be automated), so some CAs cut costs by only doing domain-control verification ("DV"), resulting in browsers not trusting or displaying the real-world-identity details from the certificate unless it had a special flag to confirm that the CA was genuinely still checking those details (which are now part of a higher-priced product category, "EV").

For example even large organizations like the BBC (the UK's national broadcaster) use DV, and financial sites like Paypal are mostly the only ones that use EV (compare what your browser tells you about www.bbc.co.uk vs. www.paypal.com).

> Let's encrypt effectively killed it. They just verify you can control the domain (legitimately or not) and sign whatever.

This happened long before Let's Encrypt. Let's Encrypt is the logical conclusion of the race-to-the-bottom on price: the price they charge for domain verification is zero.

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 20:10 UTC (Tue) by DimeCadmium (subscriber, #157243) [Link] (2 responses)

> Also the check is done via HTTP, so if you can do a MITM between the domain and letsencrypt itself you can get them to sign something else :)

Sure... if you can get a MITM between the domain and *every single one of LetsEncrypt's perspectives* https://letsencrypt.org/2020/02/19/multi-perspective-vali...

Use a keypair, but skip the web of trust

Posted Oct 23, 2024 6:19 UTC (Wed) by pabs (subscriber, #43278) [Link] (1 responses)

That was already done by Hetzner to one of their customers:

https://notes.valdikss.org.ru/jabber.ru-mitm/

For a global active adversary it is probably trivial to attack you even if you had a diverse set of hosting providers.

Use a keypair, but skip the web of trust

Posted Oct 29, 2024 9:13 UTC (Tue) by taladar (subscriber, #68407) [Link]

Just because it is trivial for the hosting provider who owns and routes your literal IP address that doesn't mean that it is trivial to do for anyone else.

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 16:18 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

Part of the problem with the web of trust is that we're intermingling more than one thing: the things I can promise easily are that, as far as I can tell, the person who can encrypt and sign with key ID 0x12345678 can also read e-mail sent to foo@example.com and send e-mail from that source address, goes by the name "Jane Smith" in person as well as electronically, and looks like the photo attached to the key.

The thing the web of trust tried to get us to determine is whether the person who can encrypt and sign with key ID 0x12345678 is the same as some specific legal person, with ID checks and everything so that even if I go by the alias "Jane Smith" in the context you know me in, I cannot use that alias on my PGP key because I have no government ID that names me as "Jane Smith". And this collapses because nobody is good at checking IDs as an occasional "key signing party" thing.

Use a keypair, but skip the web of trust

Posted Oct 22, 2024 18:38 UTC (Tue) by Wol (subscriber, #4433) [Link]

> And this collapses because nobody is good at checking IDs as an occasional "key signing party" thing.

It also collapses because not everybody has IDs. Somewhere (probably here) I also heard that some people also do not have (or need) a legal name.

In the UK, the only ID a person is pretty much obliged to have is a birth certificate. And that relies on their parents registering them (which they don't always).

It's much less common nowadays, but still happens, that girls will grow up, get married, be a housewife all their life, and never have any documentation in their own name. 50, 60 year-old women even today sometimes have the devil of time sorting things out after their husband dies because everybody demands documents they've never had, and they end up in an endless loop of "but I don't have X, I don't have Y, I don't have Z, I don't have X, ...". It could happen to a bloke, but is just far more unlikely.

Cheers,
Wol

Use a keypair, but skip the web of trust

Posted Oct 29, 2024 13:10 UTC (Tue) by Avamander (guest, #152359) [Link] (1 responses)

> 0x12345678 can also read e-mail sent to foo@example.com and send e-mail from that source address

There's no guarantee of that with PGP. Google saying that someone controls an address (via OIDC) however does guarantee that.

Use a keypair, but skip the web of trust

Posted Oct 30, 2024 8:58 UTC (Wed) by taladar (subscriber, #68407) [Link]

Technically nothing guarantees that in either case because they might have lost access to the account literally the second after the signature was created.

Such a headline!

Posted Oct 24, 2024 11:54 UTC (Thu) by madhatter (subscriber, #4665) [Link] (2 responses)

Can we spare a moment to admire Mr. Brockmeier's heavy-duty alliterative headline? It's worthy of a red-top tabloid, though whether that's a good thing, each reader must judge for him/herself.

Such a headline!

Posted Oct 24, 2024 12:54 UTC (Thu) by jzb (editor, #7867) [Link] (1 responses)

Thank you... I think?

Such a headline!

Posted Oct 25, 2024 6:14 UTC (Fri) by douglasbagnall (subscriber, #62736) [Link]

Honestly I was expecting a reference to https://github.com/konstin/sudoku-in-python-packaging

Web key directory (WKD) makes GnuPG (OpenPGP) more usable

Posted Oct 25, 2024 13:11 UTC (Fri) by ber (subscriber, #2142) [Link]

A lot of complains about the web of trust and OpenPGP does not take newer developments like the Web Key Directory (WKD) protocol into account. When using email clients that implement it to a large extend, the exchange of end-to-end crypto messages has a much higher usability.

See https://wiki.gnupg.org/WKD . It uses the exsting binding of email addresses to domains and TLS certificates to bring in some basic trust. Additional trust by other methods (like the web of trust) can be used for additional trust. So it is compatible to higher security models.

(For email implementors see https://wiki.gnupg.org/WKD/UsabilityOfWKD but other use cases can also profit from WKD.)