Add sha1 and version to boxcryptor-classic

[goodtimeaj]

Add sha1 and version to boxcryptor-classic

[nanoxd]

Any reason for adding it to the same URL?

[vitorgalvao]

This is security software and it should have a checksum.

Yes, but the people providing the link are the same people providing the checksum, which makes it useless for security purposes, only to check if it was correctly downloaded. If we wanted to give a link to malicious software and add the checksum for that, we could; you can only trust the checksum for security purposes if it comes from the official source, which means the the only thing this’ll do is break the cask when (if) the software is updated.

[vitorgalvao]

Of course anyone could add malicious casks to brew cask but that's not what I'm doing here.

To clarify, I’m in no way distrusting you.

checking if it was correctly downloaded is just as valid as the security issue. This is what they are for.

Correct, but no_checksum is also there for a reason — to prevent casks from breaking all the time, when we’re linking directly to the latest version.

You can download the file yourself and create your own hash to see that mine is the same as yours.

I can, and so can every other user, that’s the beauty of it, but if you’re going to do that anyway, you have no need for the checksum in the cask. My point is that, by merging this, we’d be sacrificing not having the cask break for checksum that may or may not be useful. Users who care that much about the integrity of it may not use the cask anyway, to be really safe, and the ones who don’t won’t gain anything by having it there.

I just saw your other pull request. That would stop the cask from breaking due to an update, and it would use the checksum. There’s still the question if it’s worth sacrificing not always having the cask at the latest version without any extra work, but to solve this security discussion, that seems like a more acceptable solution.

I’d like for some input from @phinze, @passcod, @fanquake, and/or @nanoxd, as well.

[vitorgalvao]

That quote has a context. “I can, and so can every other user, that’s the beauty of it, but if you’re going to do that anyway, you have no need for the checksum in the cask”; it applies in this case — if you’re going to get the checksum manually anyway, you don’t really need it on the cask file.

I think since this is the "Classic" version - classic meaning old here - I don't think there is going to be much churning here.

I’d agree, were it not for the FAQ on the page:

“Will you still offer updates for Boxcryptor Classic?

Yes, we will continue offering regular support for our Boxcryptor Classic versions. This means, that you will get Boxcryptor updates and that we will make sure that the Boxcryptor Classic versions are bug-free and are properly working.”.

We can’t really be sure if there’ll be many udpdates or not.

[nanoxd]

I think we are derailing from the core message of brew-cask:

Let's see if we can get the elegance, simplicity, and speed of Homebrew for the installation and management GUI Mac applications like Google Chrome and Adium.

I agree with @vitorgalvao. Between the options of having a cask that is always updated vs. a cask that needs maintenance, ease of use wins out. In the past the progression of a cask went from

version '1.1' -> version 'latest'

To return to using being versioned, would put this cask in a state of regression.

[vitorgalvao]

Homebrew doesn’t have the problem (if you can call it that) of apps that auto-update themselves. What @nanoxd quoted was the core idea of homebrew-cask; even though we do look at the main homebrew project for ideas and we share a lot of the same values, it doesn’t mean we follow everything they do — they’re different projects, for different audiences, and they have different needs.

From what I recall in all my time with the project — and I’ve seen it grow a lot — we always talked about individual users, this is the first time I recall “the enterprise” being mentioned (not to say they don’t matter, but I don’t think they’re necessarily the target audience); sacrifices to the experience of “regular” users is usually not worth it in deference of specific cases. In any case, if enterprise users will not use this simply because the checksum isn’t there, then they won’t use it at all (again, what’s to say they can trust the checksum in the cask), and they could (and perhaps should), make their own repository they control and use of casks for critical apps (the feature is there).

[vitorgalvao]

I think that your "regular users" are mostly all going to be developers and system administrators

You’d think so, and you’d be surprised (I did, and I was). The ease of installing GUI apps this provides is extremely appealing, and casks are so simple to create, I’ve merged pull requests from a lot of people who were obviously not developers, but that wanted to contribute anyway. Also, do not forget you don’t need to use a terminal for this, you can install apps from homebrew-cask even with Alfred, which makes it even quicker and reaches a broader audience.

who probably all would appreciate some sort of system integrity.

Which, again, you cannot guarantee. You’re always free to fork the project and make checksums mandatory on all casks, but we’ve decided, as @nanoxd put it, that convenience and ease of use are paramount, which is where no_checksum comes into play (and also for casks that do not provide version-specific download links, which would constantly break). Checksums are mainly used to check the integrity of the downloaded files, and if a user is that concerned about a particular piece of software, she should get it herself from the official sources, not use a system from a third-party; it only takes a few more minutes to do it, and is worth it for the really concerned. If the integrity of a pice of software is that critical, do not delegate it.

If you truly want to discuss the security implications of this with the community, please open a new issue, specific to that. Since this conversation is happening on a pull request (and a closed one, at that), it’s unlikely it’ll get picked by another user.

[passcod]

A quick answer (I agree this would be much better in a separate issue,
especially as I often ignore cask adds and updates, but always look at
separate issues) on an option you might have missed: homebrew-cask
supports taps. You are free to create your own tap that enforces
checksumming for some casks. Heck, if you would create and maintain a tap
that does this for a number of casks, and keep it up-to-date, I'm sure we
could mention it somewhere on here to boost visibility. Homebrew is
extensible that way :-)

[phinze]

Hi folks; sorry to hop in late here.

If I'm reading correctly, it seems to me the core issue here is: for a given cask, if we have available both latest / no_checksum and versioned / checksummed URLs, which should we prefer?

Let me open up a separate issue to discuss that.