Feature Suggestion: provide support for verifying PHAR files via GitHub Attestations
Opened this issue · 13 comments
I just heard about and read up on the new Artifact Attestations feature from GitHub, which provides another piece of the security chain - provenance checking, i.e. for PHAR files which are generated via GitHub Actions, verifying that the PHAR file has not been tampered with since its generation and allows for checking which workflow was used against which commit etc to generate the PHAR file(s).
Couldn't help but think of PHIVE when reading up on it.
Just spitballing, but I can imagine it might be a nice feature if PHIVE could run this verification as well.
I imagine that this may require an new option (toggle) in the phive.xml file to optionally turn this on if the PHAR was created via GH Actions with Artifact Attestations enabled.
References:
Sounds very interesting.
Not having looked at it at all yet, I'd assume that to require additional API calls from PHIVE to github. Making it more and more likely that an access token is required as we're almost certainly going to run out of API calls.
I'll check on it :)
Not having looked at it at all yet, I'd assume that to require additional API calls from PHIVE to github. Making it more and more likely that an access token is required as we're almost certainly going to run out of API calls.
The documentation mostly gives examples using the GH CLI tool to verify, but yes, I'm pretty sure there is an API too.
Not sure about the need for an access token though, I mean, how many PHARs do people on average install via PHIVE ? 5 ? And how many of those are already using this feature ? (PHPCS will as of the next release, but I'm probably an early adopter)
I thought the rate limit was something like a 1000 calls an hour ? Or has that gone down a lot ?
I imagine that this may require an new option (toggle) in the phive.xml file to optionally turn this on if the PHAR was created via GH Actions with Artifact Attestations enabled.
Oh and to be clear, I meant the above for the phive.xml file PHAR providers maintain listing their releases, not for the end-user phive.xml file.
I thought the rate limit was something like a 1000 calls an hour ? Or has that gone down a lot ?
Close ;) The primary rate limit for unauthenticated requests is 60 requests per hour.
I imagine that this may require an new option (toggle) in the phive.xml file to optionally turn this on if the PHAR was created via GH Actions with Artifact Attestations enabled.
Oh and to be clear, I meant the above for the
phive.xmlfile PHAR providers maintain listing their releases, not for the end-userphive.xmlfile.
I got that. But Phive, on the end user's device, needs to verify things at runtime. Otherwise it'd be kind of pointless, or?
I imagine that this may require an new option (toggle) in the phive.xml file to optionally turn this on if the PHAR was created via GH Actions with Artifact Attestations enabled.
Oh and to be clear, I meant the above for the
phive.xmlfile PHAR providers maintain listing their releases, not for the end-userphive.xmlfile.I got that.
Figured you would, but figured I'd clarify for the casual passer-by/watcher.
But Phive, on the end user's device, needs to verify things at runtime. Otherwise it'd be kind of pointless, or?
Correct, but only for those PHARs which indicate attestations are available.
But Phive, on the end user's device, needs to verify things at runtime. Otherwise it'd be kind of pointless, or?
Correct, but only for those PHARs which indicate attestations are available.
Certainly. Just saying that, in case that feature gets wider adoption, we're even more likely to run into Rate limit issues. As of now, we have to do various API calls already and if you do that on CI without access token, the IP of the system is the reference for that limit. So, 60 calls are easy to reach.
Again, this is not saying anything against this feature.
Saw this on a private discussion board as extra info on how to verify attestations. Not sure if it will help, but figured I'd share it anyway (with permission).
GitHub's attestations are Sigstore bundles under the hood, so you can use any Sigstore client to verify them. Off the top of head, a few that should support verifying these:
I help maintain
sigstore-python, so using it as an example:python -m pip install sigstore sigstore verify github some-artifact --bundle attestation.json --repository foo/bar...that will verify
some-artifactagainstattestation.json(potentially downloaded viagh attestation download) using the GitHub repository identityfoo/bar.
Source: @woodruffw
Thank you for pinging me! FYI, we've deployed a similar thing on Homebrew (all bottles in homebrew-core now have attestations), and the default rate limit limit is similarly way too low for us. We're currently still in beta and therefore relying on GH API tokens to get around that rate limit, but we're hoping that GitHub raises the limit well above 60 for public repos 🙂
Edit: some more details on that: https://blog.trailofbits.com/2024/05/14/a-peek-into-build-provenance-for-homebrew/
Is there some actual documentation on how this stuff is supposed to work other than "install this cli tool"?
For sigstore-python, the repo README has both some docs and also links to more detailed docs: https://github.com/sigstore/sigstore-python.
If you're asking about Sigstore more generally, I think this page (and the whole docs site) is a good starting point: https://docs.sigstore.dev/#how-sigstore-works.
Thanks for the pointers, but those aren't exactly what I was looking for. If I am to implement support for this, I'd need to understand what I - at a potential bare minimum - have to do programmatically.
And preferably not by reverse engineering source code in a different programming language ;)
I believe to have understood generally, what needs to be done. But I so far fail to find any actual developer documentation. All I find, is "it's easy, just run cosign with these parameters" to do X.