5 ms·
Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
by eviks 1y ago
Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
- hiccuphippo 1y agoI'd guess one MO is to delete a malicious package/url shortly after releasing it to prevent researchers from getting to it.
- eviks 1y agoSo they wouldn't make a release immutable?
- zamadatix 1y agoWhich means the tainted release doesn't matter anymore to those consumers worried about the immutable release attestation anyways. If others are worried about that, they should probably consume only attested immutable releases as well. I'd still bet the larger portion was it was just a particularly easy path to preventing downgrade attacks or the like though. Could always be more to it as well I'm not thinking of, just feels likely.
- yjftsjthsd-h 1y agoI assume they're doing the trivial workaround to prevent renaming by way of delete and recreate?
- eviks 1y agoThen you'd ban the recreation part?
- darkamaul 1y agoI think the reason here is to prevent deletion that cause upstream disruptions. See the reasoning in the PEP 763 (not adopted ) https://peps.python.org/pep-0763/ https://peps.python.org/pep-0763/
- eviks 1y agoStrange they haven't identified negative security implications: if the owner notices the hack he can delete the malicious release before the central authority, so this would limit the blast radius (think there was a recent such issue with npm where there was a delay between discovery (by the author) and removal) Otherwise yes, leftpad/coverup risk is a thing
- kbolino 1y agoDeletion creates a hole. The hole can be filled by something else. This is a form of mutation. What you probably want instead is one-way revocation. You place a permanent marker that says "do not use this release because it is {broken, malicious, ...}".
- eviks 1y agoNo, you can make the whole immutable, that is if a tag in an immutable repo was used and deleted, it can't be used again
- kbolino 1y agoAn "immutable hole" just sounds like a "revocation marker" without an accompanying message, so I don't think we're really asking for different things, here. Nevertheless, ordinary tag deletion -- what git natively supports -- can't be supported directly.
- eviks 1y agoThe difference is the unavailability of content. For example, you attach the wrong binary and want to avoid confusion/mistaken downloads either manual or via tools that don't support your markers, in the most direct way - by deleting the binary from release. But you can't fix it if you opted into the security benefits of no hidden mutation
- danudey 1y ago1. A release turns out to contain an exploitable bug 2. A release is published to fix the bug 3. Someone malicious with access deletes the release 4. Everyone downloading the "latest" version gets the exploitable version until the developers notice and re-publish again I think about tools used in CI systems that are often re-downloaded in each run, like `helm` or `kubectl` or `crane` for example; if they're pinning a previous version they stay exploitable, and if they're downloading the 'latest' from Github then this switcheroo keeps them exploitable. Given that a lot of emergency security releases come with disclosure ("this is being released to resolve CVE-2025-12345") another 12 hours of exploitability can be critical.
- eviks 1y agoThanks, interesting scenario, but if you have access to releases like that how is this easier vs just publishing a release with an exploit and getting the same X hours before you're discovered?