Add option to not install casks with insecure properties

[vitorgalvao]

Something like a --no-insecure flag (set at runtime or in HOMEBREW_CASK_OPTS) that will not install a cask and produce an error message if in the cask (only one needed):

• url starts with anything other than https.
• sha256 is :no_check.

Refs #1824 #10377 #7062.

[radeksimko]

👍 I like the idea.

[fanquake]

👍

[gtklocker]

I like the idea, however sha256 :no_check is the key issue here.

Let's say your threat model considers the brew cask maintainers as trustworthy —which it should if you're using it and have installed it in the first place—, and that you're trying to protect against running software that has been altered by someone actively man-in-the-middling your internet connection. Now, the power of that someone is a really important factor. I will try to keep it realistic and say it's someone who simply wants to play a prank on you, or try to claim your bounty (example). The bounty you see in this example is ฿ 0.8, which amounts to about 182€. It would be irrational for someone trying to claim this bounty to spend more than 182€—otherwise they'd lose money! This is the highest bounty I've personally seen for such an attack so I think it makes sense to use this as a baseline. If anyone is considering a different threat model I'll be glad to discuss.

Now let's say you download some software via cask, your download comes from HTTP but gets compared to the checksum the maintainers have personally verified. This happens before any code downloaded is run of course, so I can't see any risk here. All this, provided that you trust the maintainers.

Before someone jumps the gun and claims that using https for the download will protect him against a malicious government agent, I'd like to point out that faking an https government is a trivial task for any government in the world. (recent example)

Therefore, if you're trying to defend against governments, https can be trivially compromised, a problem, however, exists only when sha256 :no_check is used. If you're trying to defend against someone willing to spend 182€ to attack you, a valid sha256 checksum is enough. So in both cases a valid sha256 checksum is enough. Let's avoid commenting on the safety of git pulling the repository for now.

Now, you can see that the burden of having the right hashes and download links for all casks lies to the maintainers, that we all (the users) trust according to the aforementioned threat model. This is a serious issue that I'm not sure has really been tackled even in bigger package management teams like apt-get or yum. There should really be an internal discussion about what casks can be let in, how the download links and checksums are verified, if having a connection from a maintainer to someone who's signed software through the GPG WoT plays an important role, etc. I'm not in a position to critique this, however.

Finally, I suggest that brew cask should be thoroughly threat modelled by the maintainers. My quick (personal) threat model example is only a useful start for not jumping the gun where it's not needed.

[dionyziz]

To clarify, the behavior should work as follows (code A):

    if --no-insecure is specified:
        if the URL is https:
            download and install
            return
        if there's a valid SHA256:
            download and install
            return
        fail as insecure
        return
    download and install insecure

The behavior should not work as follows (code B):

    if --no-insecure is specified:
        if the URL is https and there's a valid SHA256:
            download and install
            return
        fail as insecure
        return
    download and install insecure

As @gtklocker pointed out, a SHA256 is enough when a link is http.

[fanquake]

In code A, shouldn't there be a third case? Ideally every cask should have a https link and a SHA256.

    if --no-insecure is specified:
        if the URL is https & if there's a valid SHA256:
            download and install
            return
        if the URL is https:
            download and install
            return
        if there's a valid SHA256:
            download and install
            return
        fail as insecure
        return
    download and install insecure

[dionyziz]

The first case in my code A captures your third case; if the URL is https and there's a valid SHA256 then, necessarily, the URL is https. But to answer your comment, I don't see why an https URL with a SHA256 check is more ideal than just a SHA256 for cask. HTTPS doesn't add any security in this case. (It's nice to have if you expect people to download software outside of cask of course.)

[fanquake]

Yes, I was going to raise that point. Having a checksum or GPG verification is more ideal than having a https link. Which bring us back to the point that people have to trust us as maintainers.

[vitorgalvao]

Closed in favour of #18831.

Checking for https has been abandoned for the reasons stated by various users on this issue. Additionally, it’s not as trivial to check for it, since an https url may redirect to an http, and as such we’d always need to do the appropriate network requests to check for those.