Yossarian

> Because PyPI (or an attacker) could always substitute a new key.

No, they couldn't. The old package would authorize a later update. Think blockchain.

> This might be a misunderstanding, but I don't think you actually want this: lots of large packages have multiple release managers (and contributors who come and go); you don't want to manually resolve each new human identity that appears for a package distribution.

I'm not sure you actually know how organizations release software:

You wouldn't have signatures of individuals in that case of course, but stuff signed by keys owned by the organization.

Think signed Linux packages from distributions.

> What most people actually want is a strong cryptographic attestation that the package distribution came from the same source as the thing hosting the source code […]

No, that's completely uninteresting. Nothing could bother me less.

I know already that every time I'm downloading something from e.g. Microsoft GitHub it comes form Microsoft GitHub. There is strong E2E encryption in place making that sure (TLS). Same for any other hoster.

> […] since both that service and the owner of the repository are presumed trusted.

Wrong again.

I'm not trusting any hosting service any more than any other random people on the internet. Not only that a service can get malicious for any reason at any time, get hacked, or be forced by authorities to perform targeted attacks, I actually don't have any trust relationship with them…

> And if they do, is it good design to install back-ends for (say) 23 such target architectures that you're never going to cross-compile for, in practice? Does that benefit the user?

rustc --print target-list | wc -l 287 I'm kinda surprised at how large that is, actually. But yeah, I don't mind if I have the capability to cross-compile to x86_64-wrs-vxworks that I'm never going to use.

I am not an expert on all of these details in clang specifically, but with rustc, we take advantage of llvm's target specifications, so you that you can even configure a backend that the compiler doesn't yet know about by simply giving it a json file with a description. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/spec/index.html

While these built-in ones aren't defined as JSON, you can ask the compiler to print one for you:

rustc +nightly -Z unstable-options --target=x86_64-unknown-linux-gnu --print target-spec-json It's lengthy so instead of pasting here, I've put this in a gist: https://gist.github.com/steveklabnik/a25cdefda1aef25d7b40df35a026144d

Anyway, it is true that gcc supports more targets than llvm, at least in theory. https://blog.yossarian.net/2021/02/28/Weird-architectures-werent-supported-to-begin-with

> which GitHub goes to extents to document GitHub Actions policies as applying to `uses:` clauses

If it were phrased like this then you would be right. The docs would give a false sense of security, would be misleading. So I went to check, but I didn't find such assertion in the linked docs (please let me know if I missed it) [0]

So I agree with the commenter above (and Github) that "editing the github action to add steps to download a script and running" is not a fundamental flaw of this system designed to do exactly that, to run commands as instructed by the user.

Overall we should always ask ourselves: what's the threat model here? If anyone can edit the Github Action, then we can make it do a lot of things, and this "Github Action Policy" filter toggle is the last of our worry. The only way to make the CI/CD pipeline secure (especially since the CD part usually have access to the outside world) is to prevent people from editing and running anything they want in it. It means preventing the access of users to the repository itself in the case off Github Actions.

[0] https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass

(Author of this post.)

If you’re interested in how this went down, the timeline section[1] in particular is worth jumping to: my key takeaway is that this vulnerability was reintroduced, and that there’s only limited evidence that the Ultralytics team have done a full revocation and rotation of all accounts and credentials that the attacker may have had access to.

Given that, it’s not inconceivable that a third round of backdoored packages will occur. I would recommend that people exercise extreme caution when installing the current versions; most users would probably be best served by pinning to an older version from before any indicators of compromise.

[1]: https://blog.yossarian.net/2024/12/06/zizmor-ultralytics-injection#appendix-rough-timeline-of-events

Isn't it worth the balance between stability and effort to go with LTS (long term support / security updates only)?

You know the updates on LTS will be relatively much safer. The limit of potential breaking updates to every 2 years is mostly the point. But if you're just talking about a home lab where you want to use the latest advances without the latest exploits, try a dependency cooldown. Simon Willison recently pointed out this post by William Woodruff about dependency cooldowns [0]. Wait a day between update release and adoption to identify supply chain compromises.

In other words: Don't move fast. Don't break things.

Or: Move slow. Keep things.

[0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns

> were previously supported

I think it was over this debacle, definitely over some debacle, someone made a great blog post that pointed out this wording is usually incorrect (edit: Link https://blog.yossarian.net/2021/02/28/Weird-architectures-werent-supported-to-begin-with HN Thread: https://news.ycombinator.com/item?id=26294397).

It previously worked, but no one was promising support for niche architectures. It just happened to work (at least enough that there weren't obvious bugs, who knows if fully). Expecting support for every non-standard way you can use the software is usually not a reasonable expectation of maintainers.