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.