Never accept a hash-free cask

[guyzmo]

Another comment I got, is that amongst all the added value of using a package manager is the fact that it has download verification against a hash. There are some packages that are having version :latest and sha256 :no_check in the cask file. I've been recommended by @vitorgalvao to do that in #9461, showing me the acorn cask as example.

It also looks like there's been a move forward no checks in that commit. I do believe this is quite wrong. I have (too) many security researchers amongst my friends, and they made demonstration of how easy it is to create a transparent proxy that tampers packages transparently by adding trojans. There are even ready made applications for that!

The best counter measure for that is actually to use an hash to check whether the downloaded package has been tampered! It's very simple, and because the whole HB and HBC system makes it so easy to update the formulas/casks there's no reason to actually have no hash checking done. If an application is downloaded from a non-versioned URL download scheme, then we can act appropriately:

1. that means that the distributed app has changed since the cask has been written and the cask might be outdated (what if the distributor changed from a .app in a .dmg scheme to a .pkg, without changing the distribution scheme?)
2. or that means that the download has been tampered in some ways during the download, and should not be installed.

Then HBC could show the hash mismatch, and offer to power users a way to force download and check the contents of the downloaded package, to see if the cask need updating (version and hash) or the package has been tampered.

All in all I believe that the move to "no hash" has been made to avoid changing every couple of days the hash value and version number of casks that don't work anymore, lowering the need of housekeeping of the casks. But I really believe that it comes at a huge price regarding security, whereas HBC has the ability to offer a security most application providers don't care to offer.

[vitorgalvao]

Please bear with me, as I’m on a phone and it’ll be a bit hard to extend all my reasonings. Also excuse any possible problems with jumping from one idea to the next.

I hope another maintainer can jump in and continue the conversation.

A few points I’ll make right off the bat (and try to explain) is you’re ignoring (failing to consider?) many things that we has maintainers encounter frequently and that guide many decisions.

Yes, a package manager can allow some integrity checking, but it’s also meant to address convenience, and your comment seems to somewhat pass by that. Convenience is multifaceted, and it means giving the best experience to users in terms of security and ease of installation, with the least amount of friction.

Not checking is many times a necessity to accomplish those goals (including in the submission you mention), not a decision based on opinion. This system is also not less secure than the alternative (just not better either).

You mention “a move towards no checks” but such a thing never happened. It was never a move. It has been like that from the start, and for good reasons.

Homebrew only allows releases tagged with versions. That is not the case with homebrew-cask, so no comparison can be made. Their model works for the types of apps they provide, but not for the ones we do, where a bunch of them are closed-source, and we have absolutely no control over anything but pointing casks to a link. Said links many times do not change, like in your submission. They don’t change because the vendor provides a versionless link and always updates de package in place. There is nothing we can do about that (apart from asking the vendor to take that into consideration, which will arguably be a waste of time in most situations).

Updating checksums is not as easy as you’re assuming, and I know because some maintainers (myself included) are here every day, checking in multiple times a day, and even then some apps routinely got open issues about mismatched checksums. The best example of such a case were nightlies. The only reason apps with versionless downloads are not an example is we never checked them.

And what needs to happen for us to get an updated checksum in those cases? A user needs to have a bad experience by having the app failing to download, and open an issue. The option to “allow the app to be installed anyway” is reasonable and has been mentioned before. But your idea that it should be an option for power users is, I strongly believe, deeply misguided. What will actually happen is power users will perhaps fix the cask, while regular users will just say “screw it” and use the option, because they just want to be done with it. They're using the system for the convenience.

Yes, pursuing checks in every case is a worthy goal. It is also likely one we’ll never completely get to due to limitations out of our control, and it is anything but simple since the problem isn’t one of technology.

The solution (workaround) will begin taking its first steps when, related to your suggestion, we show a good warning to users that a certain cask won’t be checked (there’s an open issue somewhere, but again, I’m on a phone and it’s a pain to search), and perhaps even allowing a flag to be passed to never install those apps. That is way more realistic, and something we can actually do without drastically lowering the user experience with many casks. Something better can evolve from there.

Why not follow your suggestion exactly? Because, once again, we know it doesn’t work well, due to nightlies. They’re a pain to update, and can never be reasonably kept up to date (we tried), making checks useless and nothing more than a nuisance in those cases.

I hope it is clear, though, that I agree with your sentiment and would really like this to be a possibility. Unfortunately it isn’t. Not realistically.

[guyzmo]

well, my issue-lookup-fu is not as good as it should be, because tdsmith on IRC pointed me to issue #7062 where it offers a nice way to tell the user the sha has not been checked, I guess you were talking about that! I believe though a message informing of the calculated hash should be exposed along the informations. Then the good willing people, with a secure enough connection can make a PR with a hash to fix the no-check!

About your point on single URL to download a package without version information, I believe the warning should be exposed as well when there's a checksum mismatch, so the user is informed that it's either a problem with the downloaded file, or that the version of the software changed, and take appropriate actions. What if the provider did change the install method from an app in a dmg into a pkg, without changing the URL?

I totally understand your point about convenience, and I know the triangle between convenience, security and configurability: you cannot have it all! I also know there's no such thing as security, but I still believe a good compromise can be found!

Finally, for things like nightlies, something like the --head unchecked builds of homebrew can be considered, where there's no hash check, and users taking those at their own risk!

[rolandwalker]

Hi @guyzmo !

The thoughts are much appreciated. However, we don't need to open a fresh issue.

Of course this is something that we have thought about, worked on, and are still working on. It has been amply discussed in GH issues.

The official discussion issue is #1021, which was just recently closed as we had reached consensus. The quasi-official consensus is at #1021 (comment) .

You'll also see todo items for "minimizing :latest Casks" in the tracker at #4678 .

We can also do much better than checksums: there are cryptographic signatures available for some Casks as GPG signatures (#5971). And there are cryptographic signatures for many more Casks available in Sparkle appcasts, for which we have initial support in the DSL.

Help coding the needed incremental improvements on verification would be very welcome.