Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider disabling caching by default for unversioned URLs in casks #18630

Closed
1 task done
aholland opened this issue Oct 24, 2024 · 5 comments
Closed
1 task done

Consider disabling caching by default for unversioned URLs in casks #18630

aholland opened this issue Oct 24, 2024 · 5 comments
Labels
features New features stale No recent activity

Comments

@aholland
Copy link

Verification

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.

@aholland aholland added the features New features label Oct 24, 2024
@Bo98
Copy link
Member

Bo98 commented Oct 24, 2024

This should already happen by default for version :latest:

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

@aholland
Copy link
Author

This should already happen by default for version :latest:

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
  1. Security:
  • SHA verification must be skipped, reducing security
  • No protection against compromised downloads
  • Can't pin to known-good versions
  1. 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
Copy link
Member

gromgit commented Oct 25, 2024

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
Copy link
Member

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.

Copy link

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

@github-actions github-actions bot added the stale No recent activity label Nov 16, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
features New features stale No recent activity
Projects
None yet
Development

No branches or pull requests

4 participants