-
-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
[TRIAGE] The bottle for $foo has an invalid build provenance attestation #177384
Comments
Thanks for the report @noelleleigh! Could you attempt to run the following for me locally?
...that should help me determine why the GitHub API call failed to authenticate here. |
In the mean time as well: you can disable this feature (it's in beta, but you're receiving it because you have developer mode enabled) by setting |
I had the same issue, and a It seems that the attestation-checking code is sensitive to a stale gh token in a way that other parts of Also the way the error surfaces isn't very helpful |
Agreed; we rolled this out to people with developer mode enabled to discover exactly these kinds of rough edges. I'll look into improving this error message. |
I encountered a similar error for the
Running I'm using the SSH git protocol if that makes a difference. |
Using SSH for @lblackstone could you run |
|
Thanks. That looks pretty close to what I have, so I don't think that's the source of problems here. It's possible that there's another (stale) credential elsewhere that Homebrew is giving priority to; I'll look into that. Edit: @lblackstone do you happen to have a different API credential configured via |
Ah, sure enough. It looks like my |
Yep, that'll do it. I'll look into improving the error message on that case as well. In the mean time, you should be able to re-enable attestations and delete that old env var (Homebrew will use your |
Sorry for the delay:
|
No problem, thanks for checking. Could you try running (This feature won't require this kind of auth flow once it's out of beta; you can leave the beta either by disabling Homebrew's developer mode or by explicitly setting |
This comment was marked as resolved.
This comment was marked as resolved.
That's unrelated, but thank you for raising it. You can use the same Edit: I've kicked off a rebottle for Edit 2: The rebottle has completed and |
After completing the |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
I use |
This comment was marked as resolved.
This comment was marked as resolved.
Thanks @rlucas7. Could you please provide the logging information that you elided here? I need that information to triage this.
Edit: for context, I'm unable to reproduce this with the
|
yep, apologies for omitting here it is: Additional context:
attestation verification failed: Failure while executing; `/usr/bin/env GH_TOKEN=****** GH_HOST=github.com /usr/local/bin/gh attestation verify /Users/rlucas/Library/Caches/Homebrew/downloads/a69f6815965ac498390ce6a33fa2b0f3f67a970097aa33e329f401a79698e073--wget--1.24.5.ventura.bottle.tar.gz --repo Homebrew/homebrew-core --format json` exited with 1. Here's the output:
unknown command "attestation" for "gh"
Usage: gh <command> <subcommand> [flags]
Available commands:
alias
api
auth
browse
cache
co
codespace
completion
config
extension
gist
gpg-key
issue
label
org
pr
project
release
repo
ruleset
run
search
secret
ssh-key
status
variable
workflow In case you want/need this I'm using Lucass-MacBook:data rlucas$ gh --version
gh version 2.42.1 (2024-01-15)
https://github.com/cli/cli/releases/tag/v2.42.1
Lucass-MacBook:data rlucas$ Also FWIW I'm on ventura 13.6.7 |
Thanks, that's helpful! That looks like a case of your |
Yes. I already had installed via the Thanks @woodruffw 👍 bash stuff for posterityLucass-MacBook:1 rlucas$ brew uninstall wget Uninstalling /usr/local/Cellar/wget/1.24.5... (92 files, 4.5MB)Warning: The following may be wget configuration files and have not been removed! ==> Downloading https://ghcr.io/v2/homebrew/core/wget/manifests/1.24.5 This may indicate that the bottle was not produced by the expected Additional context: attestation verification failed: Failure while executing; Usage: gh [flags] Available commands: Lucass-MacBook:1 rlucas$ brew upgrade gh |
Have the same issue with I added notes to the closed issue above I was able to install by using |
Nothing other than disabling attestation fixes this for me. Is there something wrong with these specific packages? GH APIs also seem fully operational. |
Deleting the manifest locally fixed it for me somehow - |
Hmm, that's interesting -- I can't reproduce that fix. Can you confirm that it's still emitting a "has a valid attestation" message on installation? |
I've had nothing but those Right now I'm seeing failures (on x68_64) |
let me recheck by uninstalling + installing. |
Can you please paste the exact output you're seeing? That will help me pin down the exact tags/bottles that aren't working for you. |
I think I've identified a likely break point here: Homebrew began generating multi-subject attestations yesterday. I'm looking into this now. |
yep, no longer works.
|
[...]
[...]
[...]
A few packages that were failing a few hours ago worked this time ( |
Yeah, I think I can see what happened here: when we switched to multi-subject attestations, we didn't sufficiently generalize the subject handling to allow any subject to match. As a result, verification will only accept whichever subject happens to be first, which is typically I'm working on a MVR and fix now. In the meantime, you can disable developer mode or attestations to work around this, if you'd like. |
This should fix the behavior observed in Homebrew/homebrew-core#177384 (comment) and below. Signed-off-by: William Woodruff <[email protected]>
Homebrew/brew#18883 should address the above, once merged. |
Thanks for the super quick triage and fix @woodruffw. |
No problem, thank you and @mitchblank for your reports -- it's only with that kind of detail that I can triage effectively 🙂 |
The fix has landed on
Edit: Similar for the x86-64 bottles that @mitchblank reported:
|
@hashhar @mitchblank could one or both of you confirm that the fix on |
No change... or is an auto-update not enough to get this fix?
[...]
|
Do you have developer mode enabled? |
Sorry, was away for a bit there.
Yes, I did have it enabled already. I just did another |
Ah yeah, that's possible. We just did a point release of |
brew gist-logs <formula>
link ORbrew config
ANDbrew doctor
outputbrew config
brew doctor
Verification
brew doctor
output saysYour system is ready to brew.
and am still able to reproduce my issue.brew update
and am still able to reproduce my issue.brew doctor
and that did not fix my problem.What were you trying to do (and why)?
Upgrade nano from 8.0 to 8.1
What happened (include all command output)?
What did you expect to happen?
Install without error
Step-by-step reproduction instructions (by running
brew
commands)The text was updated successfully, but these errors were encountered: