Prefer checksummed versioned or no_checksum latest casks? #1021
Comments
|
Maybe just some warning when checksum changes |
Could you please elaborate? How would this help? If the checksum changes, there is no need for a warning (since it’ll be checked anyway, and if it does not match, you’ll get a warning anyway), and that still entails always using it. |
|
I think @sheerun means something of the kind "Warning, checksum doesn't match, continuing anyway..." |
|
Yes, exactly. |
|
I see how it would work, just not how it would help — if the checksum doesn’t match, you likely wouldn’t want the installation to continue, you’d prefer to know what is wrong, and try again after solving the issue. Having the trouble of checksumming everything and just showing a warning instead of preventing the installation, seems a bit pointless to me. In short, I don’t see that solution as an argument for or against any of the proposals. |
|
I fully support @phinze 's view that user's benefit should be above maintainers' benefit, within reason. Have we come to a decision and a guideline? My reasons from #1410
Where applicable, a Cask should include the version and checksum. [Remove gripe] Please consider giving contributor a chance to amend their Pull Request before closing. Linking issues rather than closing. |
When have you seen that happen? If a new cask is added, the url points to a link without a version in the name but it has a version number and checksum, we ask the contributor to change it; if the contributor changes an already present cask to have a version and checksum, the issue is closed and directed to the relevant discussion. How could the issue, in the latter case, be further amended? It changed something that is not yet agreed upon, so naturally it will be rejected/put on hold until we reach a consensus; if we do, and we change it, then we start changing it for every cask. My vote is still to continue using latest. Let’s not forget that having an application link to a url without a specific version, but with a checksum, will break the cask all the time — it happened before — latest has a reason for existing, and it’s a good one, it doesn’t just facilitate the work for contributors, it’s also less annoying for users. |
Can we agree to disagree here? :) My reasons are in #1410 |
Not really. We’ll eventually have to stick with one, so the community has to reach some kind of agreement — specially since the options are mutually exclusive.
You are correct.
No, they should not. This issue is not a case of “should we do it this way or that way”, it’s a case of “we’ve been doing it a certain way, should we change it”. This means that until a decision is made, the old way (read, current way) should be in place. Consistency is the word; let’s not have a bunch of casks that all follow different rules, that’s why there are people that triage, discuss, and manage what changes are best for the project as a whole (with the help and opinions of the rest of the community, naturally). I’ve seen pull requests pile up on this project waiting on something (the
Since @nanoxd already answered that, my question remains
|
|
IMHO, user benefit should prime, and security is part of it: we should use checksums when possible. Having one vulnerability in any of the casks could compromise the reputation of the whole project. Having packages updated regularly is another great way to fix potential bugs, thus (in general) improving security. Maintainers are often users who love to crowdsource their work and thanks to the workflow design, this is quite easy to achieve. |
|
I'm maybe having a little bit different perspective as an osx server manager with a few workstation clients. I am installing apps on the server in a shared directory which clients have access to. So no need to install each app on each client. The shared directory is ro of course, because otherwise the apps could be modified by a malicious user. But this means, apps cannot autoupdate itself, either. From this perspective it is essential that casks are updated by a I am using homebrew cask on my local laptop, too, and even there this would be how I'd like it to be (run one command, have latest version for all apps). It might even be an idea to have the cask directory ro for the current/local user for versioned apps. That would mean an upgrade of the app is only possible from the command line (but that is what we want - or why did we use homebrew to install the app?). This does not work well for all apps of course (latest scheme or alpha/beta apps with update every other day), but for an app like e.g. firefox, releasing an update about every 6 weeks, storing the version and checksum in the cask would be my favorite approach. If enough people use homebrew cask, there will be always someone who updates the casks when a new version arrives for popular apps. So my vote (as a server admin and local cask user for just some few days) is:
Btw the checksummed approach is what homebrew uses, and other similar projects (like arch aur) do and it works well for them. |
|
[Emphasis mine on the following quote]
Because it’s faster, easier, and I can uninstall it just as easily later, if I so wish. Making it read-only sounds like an awful idea, to me — the amount of open issues we’d have due to repercussions on that would be staggering; not to mention the bug reports on those other apps, from users that see a prompt asking them to update, and when they try to it does not work (and have, naturally, no idea why). If apps can auto-update, why would we block that functionality without a really strong reason? We want to facilitate a process, not enforce a way of doing things. Regarding
and
Keep in mind that will not always be possible, in our case. Different projects warrant different approaches, and it is quite common for sites of OS X apps to provide only the “latest” download option (see github’s app itself, for an example). These cases are problematic. Going back to a previous comment
Saying
sound good in theory, but will likely not happen as you’re envisioning. As mentioned, apps that only provide the latest version will be constantly breaking and needing to be fixed. |
|
@vitorgalvao the thing with read only was an unfinished thought as an osx server admin. I did not think much about it's possible consequences for osx, but having a strong linux background, too, where nearly all software is read only for the user (even it is the only user on the machine) and managed by a package manager, I know this can work (but is a different philosophy, of course). And that's also the way it currently works with my osx server/workstation combination, but that is only a side show for homebrew cask. So let's not focus on the ro thing for now. But then this brings me to the question what homebrew cask wants to be: That osx apps don't provide old versions to download on their homepage does not make this easy, of course. But then I'd still have a version number in the cask file with no checksum and pointing to the latest download url. When the app is updated the version number in the cask is amended to match again - and this triggers a redownload for all users that have installed it. To summarize my proposal:
This would have the great benefit of having apps upgradable by homebrew cask with two negative points:
So my final proposal to handle updating of casks and whether to checksum or not is:
|
|
@doits perhaps regarding the issue of the user updating an app manually, and then the caskfile downgrading it: perhaps we can work in some way to read the |
|
@alebcay this is a good idea but cannot be handled generally for every cask, so it requires extra work per app. Thinking this one step further and to make it work for generally, one could even define a shell command in a cask file to get the latest version of an installed app. For a plist this would be something like This would be, of course, the best possible case: In the cask file is the latest version written (whether for With this, casks update process would only be distinguished by whether it is possible to detect the installed version (best case) or not. If not, one could elaborate further whether to simply always update them when a new version comes out (possibly overwriting an auto updated one) or whether to handle them like written in my last comment. But if let's say for 90 % of casks we can get the installed version, I'd leave the other 10 % simple and just overwrite it on an update to not make things overly complicated. |
|
Just in case someone missed it: I've worked towards an automatic update mechanism in #3084 - definitely not finished (e.g. tests missing) but open for discussion. |
|
I tried to add versions in #3470, #3471 without reading this issue first. I came from the main homebrew, and my expectation was, that it is supposed to be that way. After reading this issue I think that using "latest" versions is a must until upgrade mechanics is implemented, but not a tad later. A lot of "package managers" value is ability to do centralised updates. My personal usecases are:
|
|
Playing with the concept of getting an app’s version via a script, here’s an idea that could get us the best of both worlds. The best thing here is that between the project and script mentioned on the linked comment, we already have most of the work done, it’s just a matter of tweaking things a bit and we could get up and running pretty soon. |
|
Just a note to tie other conversations onto this issue. As described in #4688 and #4678, I think we should (eventually) get to the point of minimizing
However, there are many qualifiers on that general opinion:
|
|
Closing this as I think the core maintainers are all on the same page. @rolandwalker's last update accurately represents the state of the union. Anybody who disagrees is welcome to chime in and we can talk about reopening. 👌 |
Do you mean that when the download URL of the binary contains no version (e.g. http://company.com/download/latest_version.dmg) we must go to unversioned formula? I am fully aware that a set of expert contributors to homebrew-cask are already thinking of a design of automatic-update mechanism, and I thank them for their efforts that should lead to a future solution. But meantime,
With this proposal, current formulae with The drawback being that the cask could be stored in a subfolder named x.y.z whereas the installed version is a newer one. If this is really a problem, a possible solution for this could be inspired from above proposals. Why not write '
Isn't it sensible meantime, before a real update mechanism? |
This issue comes from a long discussion in #1011 between @gregstallings @vitorgalvao @nanoxd and @passcod.
If anybody believes the core issue to be different than the one I've titled; please let me know and I'm happy to edit.
Here's the way I put it over there:
So to lay out some differences...
Preferring latest
Preferring checksummed
There are a few things I'd like to highlight as we continue this conversation:
Users and Maintainers are Different
There is an important distinction between user benefit and maintainer benefit. I believe we should strive for both, but in situations where they are at odds where should always prefer users over maintainers (within reason). Obviously hours of maintainer work for a minor user benefit is a bad idea. But something somewhat inconvenient for maintainers that provides a major benefit to users deserves to be considered.
Mostly I want to make sure we distinguish the two in our conversations about features and stuff, so we can properly talk about the needs of the two groups.
There was one more thing but now I've forgotten it.
Maybe it will come back to me. 😊
The text was updated successfully, but these errors were encountered: