Consider disabling caching by default for unversioned URLs in casks

[aholland]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Add the ability to disable caching for cask formulae that use unversioned URLs, either automatically or through explicit formula directives. This could be implemented as either:

1. A new formula directive: disable_cache true
2. A URL parameter: url "https://example.com/app.dmg", cache: false
3. Automatic detection of unversioned URLs and disabling of caching for them
4. When a SHA sum check fails, automatically try downloading a fresh copy before failing the installation

Additionally, add linter warnings for unversioned URLs and enhanced error messages when SHA mismatches occur with unversioned URLs. The error messages should indicate that a fresh download is being attempted and explain why the mismatch might have occurred with an unversioned URL.

What is the motivation for the feature?

When cask formulae use unversioned URLs (e.g., app-v9.dmg instead of app-v9.6.3.dmg), developers can replace the file with newer versions while Homebrew's cache retains the old version. This leads to SHA256 mismatches and failed installations.

Example: The roboform cask recently had its v9.6.2 file (SHA 8e66a246) replaced with v9.6.3 (SHA a1aff799) at the same URL (roboform-mac-v9.dmg). Users with the cached v9.6.2 file experience SHA mismatches when trying to upgrade to v9.6.3.

How will the feature be relevant to at least 90% of Homebrew users?

All Homebrew users who install or upgrade casks with unversioned URLs are affected by this issue. While users can work around it with --no-cache, they shouldn't need to know about or remember this flag. Many popular applications use unversioned URLs in their distribution, making this a widespread issue that affects the reliability of Homebrew's core functionality for most users.

What alternatives to the feature have been considered?

1. Continue requiring users to use --no-cache manually
2. Reject cask formulae that use unversioned URLs (too restrictive as many applications distribute this way)
3. Always disable caching for all casks (wasteful for properly versioned URLs)
4. Request all application developers to use versioned URLs (unrealistic)

The proposed solution provides flexibility while maintaining backward compatibility and puts control in the hands of formula maintainers who know their formulae best.

[Bo98]

This should already happen by default for version :latest:

brew/Library/Homebrew/download_strategy.rb

Line 410 in 3b52a46

use_cached_location = false if version.respond_to?(:latest?) && version.latest?

[aholland]

This should already happen by default for version :latest:

brew/Library/Homebrew/download_strategy.rb

Line 410 in 3b52a46

use_cached_location = false if version.respond_to?(:latest?) && version.latest?

@Bo98 Hi Bo.

Thanks for pointing out the version :latest mechanism. While this would indeed solve the immediate caching issue, I have concerns about using it as the solution. I am a bit new here (and am using Claude AI to assist in this process) so forgive me if any of the below is inaccurate. But, if part 2 is correct then that would be a big concern, especially for the example that prompted this issue, Roboform, a password manager.

1. Version Tracking:

• Users can't know what version they're about to install
• System administrators lose ability to specify exact versions
• Package lockfiles and documentation become imprecise
• Reproducible builds become impossible

2. Security:

• SHA verification must be skipped, reducing security
• No protection against compromised downloads
• Can't pin to known-good versions

3. User Experience:

• brew outdated becomes less meaningful
• Can't roll back to known working versions
• No useful version history in brew log

While version :latest exists as a mechanism, encouraging its use for applications that simply haven't versioned their URLs seems to work against Homebrew's strengths as a package manager. Instead, could we:

1. Add linter warnings for unversioned URLs
2. Document best practices for formula maintainers to encourage software vendors to version their URLs
3. Only use version :latest for software that is genuinely always-latest (e.g., nightly builds)

This would help maintain Homebrew's reliability while encouraging better practices in the broader ecosystem.

PS While this issue is not about a specific formula or cask, I will mention that I have also raised an issue with Roboform about the unversioned URL. They responded with the following, which I think demonstrates that the alternative to handling unversioned URLs better is to rely on each and every provider to choose to do things correctly.

"Thank you for your suggestion and feedback. We appreciate it and will forward it to the developers for consideration.
Please note that while your suggestion will be reviewed, it may not necessarily be implemented, but it will be taken into account for future development."

[gromgit]

When a SHA sum check fails, automatically try downloading a fresh copy before failing the installation

I see a case for this being the default for all Homebrew downloads. The download cache is a cache after all, and therefore subject to invalidation at any time. I think this helps streamline the user experience:

1. If an asset is in the download cache, check its SHA256.
2. If it doesn't match, delete and download a fresh copy, then check SHA256 again.
3. If it still doesn't match, flag the usual error to the user.

[MikeMcQuaid]

am using Claude AI to assist in this process

Please don't @aholland. These LLMs are just not accurate enough. If you don't know something: ask us.

especially for the example that prompted this issue, Roboform, a password manager.

To help us better figure out this issue can you explain:

• What you were trying to do (and why)
• What happened
• What you expected to happen
• Step-by-step reproduction instructions (with as minimal input data as possible)

I see a case for this being the default for all Homebrew downloads. The download cache is a cache after all, and therefore subject to invalidation at any time. I think this helps streamline the user experience:

This is an interesting idea. I'm curious what our @Homebrew/security folks think here.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[aholland]

@MikeMcQuaid Thanks for following up. Sorry that I was not able to respond sooner. Should I open a new issue or can this one be re-opened?

Here are the details:

What I was trying to do (and why):

• Upgrade RoboForm from 9.6.2 to 9.6.3 (and now happening again with 9.6.4)
• Using standard brew upgrade workflow as I do with all my Homebrew-installed software

What happened:

• Got SHA256 mismatch errors because:
  1. Formula was updated to version 9.6.3 with new SHA
  2. But cached download was still 9.6.2 file
  3. RoboForm uses same URL (roboform-mac-v9.dmg) for all versions

What I expected to happen:

• Homebrew to recognize that the SHA changed and therefore download fresh copy
• Or at least provide clear error suggesting cache might be the issue

Reproduction:

1. Have RoboForm 9.6.3 installed via Homebrew
2. Wait for RoboForm to release new version (e.g., 9.6.4)
3. Wait for Homebrew formula to be updated with new version and SHA
4. Run brew upgrade
5. Observe SHA mismatch error because cached file is old version

Regarding cache invalidation being default: My experience provides a good example of why this could help. When SHA verification fails, a fresh download would naturally solve cases where remote content has changed while maintaining security through SHA verification.

[MikeMcQuaid]

@aholland Have you been able to reproduce this behaviour with other casks? If not: this sounds like an issue with the Roboform cask specifically and it'd be good to submit a new issue if so to Homebrew/homebrew-cask, thanks!

[aholland]

@MikeMcQuaid the issue here is that a cache, which is meant to be simply for performance improvement (eg by avoiding downloading something twice), is being assumed to hold a valid copy of something when in fact it holds an out-of-date copy. I think the issue is clearly described above. Is there a part that is unclear? I appreciate that thread has grown a bit. Would you like me to describe it again, from scratch?

[MikeMcQuaid]

@aholland No, the issue here is that the Roboform cask specifically is not being cached correctly. I understand that you'd saying this is a wider issue that should result in a behaviour change in all of Homebrew but: this seems excessive to me until it's been demonstrated that this cannot be fixed at the cask level.

[aholland]

@MikeMcQuaid if we persuade the maintainers of the Roboform formula (who are not Roboform) to adjust the formula to take into account that Roboform doesn't set a new URL for every new minor version, we solve that one problem once, and to solve it everywhere would have to invest in conversations with every other such publisher. On the other hand, if we implement what @gromgit suggested above (see #18630 (comment)) then it is fixed permanently across the board, right?

[MikeMcQuaid]

@aholland We maintain and support all the formulae in homebrew-cask. The number of maintainers involved here is fairly small.

What @gromgit suggested would be cool but we had a private conversation with Homebrew security folks who felt it would be a security regression (important information I didn't add here until now, sorry).

[aholland]

@MikeMcQuaid

Thanks for the clarification about security considerations. Since RoboForm is a core cask and this is a recurring issue (just happened again with 9.6.4), perhaps we could consider:

1. Adding specific warnings when SHA mismatches occur with known unversioned URLs
2. Documenting the manual cache-clearing solution in the error message
3. Working with RoboForm to encourage versioned URLs for their downloads

The current situation leads to a poor user experience where users need to know about Homebrew's cache behavior to resolve the issue. I've just encountered this again this week upgrading to 9.6.4—it's particularly confusing because the upgrade appears to succeed but actually installs the old version.

Would any of these alternatives be acceptable from a security perspective?

Regarding point 3 above, the screenshot below illustrates that the page is simply a link on Roboform's webpage, presenting as the install button. I have already raised this issue with Roboform. Their issue management system is not public. So I have copied and pasted the interaction (ticket) below this screenshot. The messages are in order with the most recent at the top. The original message at the very bottom is possibly not useful to read, as it is a bit out of date now.

Vito replied (2024/10/24 10:02 pm EST)

Thanks for the addition, Anthony. We will surely forward it to our development. You may close the ticket.

You wrote (2024/10/24 08:33 pm EST)

PS in case you are interested, here is the corresponding issue on Homebrew's repo: #18630
You closed the ticket (2024/10/24 07:24 pm EST)

Justin replied (2024/10/24 05:25 pm EST)

Thank you for your suggestion and feedback. We appreciate it and will forward it to the developers for consideration.
Please note that while your suggestion will be reviewed, it may not necessarily be implemented, but it will be taken into account for future development.

You wrote (2024/10/24 03:19 pm EST)

Subject: Re: Update to 9.6.2 via Homebrew failing due to SHA256 mismatch

Hi Justin,

Thanks for your response about getting RoboForm directly from your website. I understand that Homebrew is not officially supported, but I'd like to provide some technical feedback that could help improve the RoboForm distribution process.

I've identified the root cause of the SHA256 mismatch. RoboForm currently uses a single, unchanging URL (https://www.roboform.com/dist/roboform-mac-v9.dmg) to distribute different versions of the software. When version 9.6.3 was released, this file was replaced at the same URL:

Old file (v9.6.2):

• Size: 48,410,295 bytes
• SHA256: 8e66a246fc79e2f79dc5a069c8cc0f0fed13d6d5824ddea2fc01184f4cc4db55
• From: August 2024

New file (v9.6.3):

• Size: 45,322,211 bytes
• SHA256: a1aff799aae9f070cc6feef2b84e059d666ab7a107ca51e8e3490b2c1235fe00
• From: October 2024

This practice of replacing files at stable URLs can cause issues with package managers and caching systems. A more robust approach would be to use versioned URLs, such as:

• roboform-mac-v9.6.2.dmg
• roboform-mac-v9.6.3.dmg

This would ensure that:

1. Each version remains permanently accessible at its own URL
2. Package managers and download tools can reliably cache files
3. Users can access specific versions if needed
4. Version-specific checksums remain valid indefinitely

Would you consider implementing versioned URLs for future RoboForm releases? This would improve compatibility with package managers like Homebrew and provide a better experience for users who need programmatic access to specific versions.

Thanks for considering this feedback.

Best regards,
Anthony

Justin replied (2024/10/23 12:58 pm EST)

Hello,

Homebrew is not affiliated with RoboForm and operates independently. The best way to get the latest installation is directly from our website, where you'll find the most up-to-date version. Please let me know if the issue continues after installing from there. https://www.roboform.com/download
You wrote (2024/10/22 05:39 pm EST)
Hi. Sorry, I did not read your response at the time, but have read it now because there is now another update (according to Homebrew). And again it is not working. Now, I understand that this is not a supported, official way to install RoboForm, but may I ask who is distributing RoboForm via Homebrew if it does not come from RoboForm ie Siber Systems Inc. ?

FYI I am getting the following message, which is very similar to last time. But interestingly, when I try to update from RoboForm itself (RoboForm menu, Check for Update), it says "You have a latest version 9.6.2 installed." even though your download and news pages do show that a version 9.6.3 is available.
Ilya replied (2024/08/12 08:30 am EST)
Dear Anthony, we apologize, but this is not an official way to update RoboForm.

The installation was performed with errors - instead of installing the application, it put the installer in the applications folder.

We do not recommend to use any 3rd party utilities for the updates/installation of RoboForm.

You wrote (2024/08/10 06:15 pm EST)

roboform 9.6.1 -> 9.6.2
==> Downloading https://www.roboform.com/dist/roboform-mac-v9.dmg
Already downloaded: /Users/anthonyholland/Library/Caches/Homebrew/downloads/349a2b57a312c7d520b6fd0620596d72707681457e050a50badd706914674642--roboform-mac-v9.dmg
==> Purging files for version 9.6.2 of Cask roboform
Error: roboform: SHA256 mismatch
Expected: 8e66a246fc79e2f79dc5a069c8cc0f0fed13d6d5824ddea2fc01184f4cc4db55
Actual: 372251eacbe4da9019d0a60f6f796dd0e306988e6b0ab1a86b46e3d31bd10fe6
File: /Users/anthonyholland/Library/Caches/Homebrew/downloads/349a2b57a312c7d520b6fd0620596d72707681457e050a50badd706914674642--roboform-mac-v9.dmg
To retry an incomplete download, remove the file above.

I removed the file and tried again, but now there is no update.

Then I did a specific brew upgrade roboform and that worked. But the first time I ran it macOS caught and error and asked me to submit a report, which I did. Will put that report below. Then I tried running it again, and it ran not so much as an installed application but as an installer (but succeeded this time). Then I ran it a third time and at this point it opened up properly. So I am now submitted this ticket just FYI as I have succeeded in upgrading, but it was not smooth. Note that I am using the mac Sequoia Beta 15.0

Apple Ticket Text:
I’ve been attempting to upgrade Roboform to 9.6.2 via my routine morning Hombrew brew update script. I had a problem which I began reporting to Roboform via the support website, but decided to try again. I delete the offending file and did a brew upgrade roboform

Update to 9.6.2 via Homebrew failing due to SHA256 mismatch

roboform 9.6.1 -> 9.6.2
==> Downloading https://www.roboform.com/dist/roboform-mac-v9.dmg
Already downloaded: /Users/anthonyholland/Library/Caches/Homebrew/downloads/349a2b57a312c7d520b6fd0620596d72707681457e050a50badd706914674642--roboform-mac-v9.dmg
==> Purging files for version 9.6.2 of Cask roboform
Error: roboform: SHA256 mismatch
Expected: 8e66a246fc79e2f79dc5a069c8cc0f0fed13d6d5824ddea2fc01184f4cc4db55
Actual: 372251eacbe4da9019d0a60f6f796dd0e306988e6b0ab1a86b46e3d31bd10fe6
File: /Users/anthonyholland/Library/Caches/Homebrew/downloads/349a2b57a312c7d520b6fd0620596d72707681457e050a50badd706914674642--roboform-mac-v9.dmg
To retry an incomplete download, remove the file above.

I remove the file and tried again, but now there is no update.”

After this I did the brew update roboform as follows, apparently successfully:
“❰anthonyholland❙~❱✔≻ brew upgrade roboform
==> Upgrading 1 outdated package:
roboform 9.6.1 -> 9.6.2
==> Upgrading roboform
==> Downloading https://www.roboform.com/dist/roboform-mac-v9.dmg
################################################################################################################################################################...
...################################# 100.0%
==> Backing App 'RoboForm.app' up to '/opt/homebrew/Caskroom/roboform/9.6.1/RoboForm.app'
==> Removing App '/Applications/RoboForm.app'
==> Moving App 'RoboForm.app' to '/Applications/RoboForm.app'
:0: warning: using (deprecated) legacy driver, Swift installation does not contain swift-driver at: '/Library/Developer/CommandLineTools/usr/bin/swift-driver-new'
==> Purging files for version 9.6.1 of Cask roboform
🍺 roboform was successfully upgraded!
❰anthonyholland❙~❱✔≻
“

But then, on quiting Roboform and starting the new version, I got this error (the one that resulted in this feedback dialogue I am currently filling in.

Given what I know, this could be Roboform’s fault, or it could be because I am using the macOS Sequoia Public Beta (macOS Sequoia Beta 15.0 (24A5309e).

[MikeMcQuaid]

Since RoboForm is a core cask and this is a recurring issue (just happened again with 9.6.4)

@aholland Did you file a homebrew-cask issue about this like I suggested? If not: yes, it's expected this will keep happening until you file an issue and someone makes a PR to fix this there.

• Adding specific warnings when SHA mismatches occur with known unversioned URLs
• Documenting the manual cache-clearing solution in the error message

We'll consider one of these once we see a bunch of other similar reports for other casks that cannot be fixed in the casks.

• Working with RoboForm to encourage versioned URLs for their downloads

This seems sensible but Homebrew doesn't need to be part of this discussion.

I have already raised this issue with Roboform.

Don't report this to them, it's not on them to fix it.

But then, on quiting Roboform and starting the new version, I got this error (the one that resulted in this feedback dialogue I am currently filling in.

I have no idea what Roboform is or how it works. We're very off track on this issue at this point so locking in hope this moves to a more fruitful location.