Potential Mitigation for Abandoned S3 Buckets in Casks #5954
-
Hi, I wanted to bring up a potential concern regarding casks that specify As an example, the article mentioned how the GitUp cask was configured to download a .zip archive from a (presumably at the time) abandoned S3 bucket without the sha256 check until it was updated in Homebrew/homebrew-cask@fd9a0b6. Since Homebrew 4.0.0, this risk is significantly reduced because Homebrew fetches the most recently updated cask via the API, preventing installation of outdated versions with abandoned S3 buckets. However, this does rely on cask maintainers actively verifying that S3 links remain valid and secure over time. I understand this may be outside of Homebrew’s threat model, but I wanted to ask if automated checks for deregistered S3 buckets and requiring a sha256 field for verified S3 links would be reasonable mitigations against potential supply chain attacks in the future. I’d be happy to contribute, whether by updating affected casks or working on a lint check to flag casks that could be vulnerable to this issue. Would either of these be useful contributions, or would they fall outside Homebrew’s scope? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi. I'm Homebrew's Security Manager. This is indeed outside our threat model. We use The best way to handle this is to have upstreams use versioned URLs. Much like how there are upstreams who do not understand that retagging in git is the insane thing to do, there will be upstreams who are more interested in having the easiest release process. This may involve unversioned URLs. The alternative is to remove all casks without versioned URLs, but this is likely to upset many users. Unfortunately status quo is as good as it gets for this situation right now. |
Beta Was this translation helpful? Give feedback.
Hi. I'm Homebrew's Security Manager. This is indeed outside our threat model. We use
sha256 :no_check
because the casks will break when they are updated in place, and no one will be able to install/upgrade if we defined the current sha256.The best way to handle this is to have upstreams use versioned URLs. Much like how there are upstreams who do not understand that retagging in git is the insane thing to do, there will be upstreams who are more interested in having the easiest release process. This may involve unversioned URLs. The alternative is to remove all casks without versioned URLs, but this is likely to upset many users. Unfortunately status quo is as good as it gets for this si…