21–30 of 64 posts
Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
I'd guess one MO is to delete a malicious package/url shortly after releasing it to prevent researchers from getting to it.
Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
To alleviate the issue of mutable releases I had set up a mirror of releases checksums to be able to detect releases alterations. This is not needed anymore for immutable releases.
And automatically publishing checking of releases artifacts is also a good recent change by GH: in that project mentioned above I have developed a cli downloader checking the checksums of the downloaded file [1], but to be useful, it required the project to publish checksums, and the project to be mirrored. Now both of these requirements are dropped and the tool is readily useful for all GitHub immutable releases.
Earlier quoted context omitted.
I'd guess one MO is to delete a malicious package/url shortly after releasing it to prevent researchers from getting to it.
So they wouldn't make a release immutable?
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.
Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
See the reasoning in the PEP 763 (not adopted )
Earlier quoted context omitted.
Yeah, how did it work before that it was not immutable?! > With immutable releases, assets and tags are protected from tampering after publication I really, really wonder how it worked before. Can anyone explain?
"Before", it was trivial to move or delete tags and edit release assets. The only stable identifier available was the commit hash. Immutable releases now enable permanently locking tags and releases to make supply chain attacks harder to affect users who are using release assets from before an attack occurred. The previous behavior is still available by the way, I'm not sure what you meant by "before".
I know, I was just wondering how it worked that needed this improvement.
Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
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, ...}".
Why is deletion not allowed, which supply chain attacks work by deleting a release, not changing it to a malicious one?
Deletion 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, ...}".
My instant reaction was: "Wait?! They weren't immutable before?" I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.