Publish PGP signatures for pie.phar (vs Sigstore build provenance)

[PhrozenByte]

Currently PIE recommends using gh attestation verify from the GitHub CLI to verify a downloaded pie.phar. However, I do not have GitHub CLI installed, nor do I wish to install it. Additionally, relying solely on GitHub attestations creates a form of vendor lock-in.

A more portable and well-established alternative would be to provide a standard PGP signature alongside the release asset. Therefore, I would like to suggest publishing a public PGP key and including a pie.phar.asc signature file next to each pie.phar release to allow independent and widely compatible verification. This is common practice for other PHAR projects, such as Composer or PHIVE.

Alternatively, projects like PHPUnit use Sigstore; while I personally prefer PGP for its simplicity and wider availability, Sigstore would also be a viable option.

Besides: Great project, thank you! ❤️

[asgrim]

PIE doesn't require GitHub CLI, there is a fallback mechanism built in to pie self-verify and pie self-update (as long as openssl ext is already installed), if you don't have gh installed.

Practically, since the phar is only ever built in CI and attestations generated there and then, it is actually slightly more secure. In order for me to sign the phar with my GPG key, I would have to download the phar, sign it, and upload the signature; there is technically (although unlikely) possibility for vulnerabilities there.

The attestation generated isn't specific to GH, it is just a Sigstore attestation anyway, but GH is just the generator. The ThePHPF/attestation library is what we're using for this, and keen to improve this library separately and address vendor lock-in concerns 👍

[PhrozenByte]

PIE doesn't require GitHub CLI, there is a fallback mechanism built in to pie self-verify and pie self-update (as long as openssl ext is already installed), if you don't have gh installed.

Assuming an attacker somehow managed to tamper with the downloaded pie.phar (e.g., in transfer, or GitHub's release asset storage is compromised), this wouldn't actually verify that the pie.phar is legit, right? As far as I understand, it only verifies integrity of updates once PIE is already installed and trusted, not the initial pie.phar download.

Practically, since the phar is only ever built in CI and attestations generated there and then, it is actually slightly more secure. In order for me to sign the phar with my GPG key, I would have to download the phar, sign it, and upload the signature; there is technically (although unlikely) possibility for vulnerabilities there.

There's indeed an ongoing universal debate about whether manual signing or fully automated CI-based signing is "more secure", but to be honest, that isn't really my concern here. Both models have Pros and Cons, and I think they are equally valid.

If manual signing is undesirable, you can also generate a dedicated PGP key used exclusively for release signing, publish the public key separately (preferably also on public key servers), and store the private key as an Actions secret so it never leaves CI. This is how many projects handle fully automated PHAR or tarball signing.

The attestation generated isn't specific to GH, it is just a Sigstore attestation anyway, but GH is just the generator.

Is there a way to access PIE's Sigstore attestation artifacts separately (like with PHPUnit)? I'm not very familiar with GitHub's API in this regard. That would already solve most of my concerns, assuming the artifacts can be used to verify the pie.phar's legitimacy with standard tools (or PIE-own tools).

[asgrim]

Assuming an attacker somehow managed to tamper with the downloaded pie.phar (e.g., in transfer, or GitHub's release asset storage is compromised), this wouldn't actually verify that the pie.phar is legit, right? As far as I understand, it only verifies integrity of updates once PIE is already installed and trusted, not the initial pie.phar download.

In the pie self-update command, PIE does not replace the existing PIE until it has verified the newly downloaded file. e.g. it'll download the new phar to /tmp/new-pie.phar (not an exact name, can't remember it off my head), then do either gh attestation verify --owner=php /tmp/new-pie.phar or use the ThePHPF/Attestation library as a fallback if gh is not available; once it is verified and the signature checks out, it will move /tmp/new-pie.phar to the currently running file (e.g. /usr/local/bin/pie or wherever you are running it).

So yes; it does verify the pie.phar you are trying to update to is genuine (specifically: what we are checking for is that the pie.phar you possess was built in the "official" PHP GitHub CI pipeline, and has not been tampered with) before PIE is installed.

If you have downloaded a pie.phar manually (i.e. you're not using pie self-update), you can run either pie self-verify after downloading it, which verifies itself using the same mechanism described, or you can separately run gh attestation verify --owner=php your-pie.phar (if you have it).

If manual signing is undesirable, you can also generate a dedicated PGP key used exclusively for release signing, publish the public key separately (preferably also on public key servers), and store the private key as an Actions secret so it never leaves CI. This is how many projects handle fully automated PHAR or tarball signing.

This is something I've used before (and was automated thanks to laminas/automatic-releases); but this approach is no better or worse than using GitHub's attestation action; ultimately GitHub holds the keys, and if compromised, that will be the weak link in either case. In fact; I had originally planned to use a GPG private key in secrets in this manner, but I had discovered the Attestation feature, which has more benefits than regular GPG signing.

Don't get me wrong, I'm personally a fan of GPG, but I always felt storing the private key as a secret was a less than ideal approach (since, you have to trust the host - GitHub in this case - does not somehow leak that key). That said, it was an adequate solution, assuming good faith from GitHub; but the GH Attestations functionality we felt packaged up a much more elegant solution, using open standards (Sigstore). This makes me quite reluctant to add a GPG signature to PIE, when we already have an arguably superior approach implemented.

Is there a way to access PIE's Sigstore attestation artifacts separately (like with PHPUnit)? I'm not very familiar with GitHub's API in this regard. That would already solve most of my concerns, assuming the artifacts can be used to verify the pie.phar's legitimacy with standard tools (or PIE-own tools).

You can download the attestation (example: https://github.com/php/pie/attestations/13387661, see also Attestations API), but it is hosted on GitHub - just like PHPUnit's is; the releases attestation (the JSON file attached to the releases page you linked to) is new, and related to Immutable releases feature, rather than verifying provenance for build artifacts (which is what PIE uses). PIE has, in fact, recently enabled Immutable releases, so the release attestation will exist on future releases (example: https://github.com/php/pie/releases/tag/1.3.0-rc.1) - but this is NOT currently checked by pie self-update.

The GitHub Attestation feature, from the perspective of "the verifier" (rather than us, "the maintainers"), there are indeed a few GitHub specific things:

• where the attestation document(s) are stored; in this case, that is our decision. We opted to use GH Attestation, rather than any separate Sigstore based system; this is for convenience, and makes our lives as maintainers easier
• how you verify the provenance of that attestation document; whilst you CAN use the gh tool, you don't have to. The attestation document itself is not in some proprietary GitHub format; it is a Sigstore formatted document, and you could use any compatible tooling to verify it. This is how we were able to build the library.
• the "trusted root" manifest. This contains certificate authorities from both Sigstore, and GitHub. In theory, you could specify your own trusted root manifest; although the library doesn't support that yet. That is an improvement that could be worked on separately (feel free to open an issue if that's something useful! https://github.com/ThePHPF/attestation/issues)

Apart from those parts (I think, off my head), the actual verification is intended to be standardised.

[asgrim]

Oh - incidentally, as a side note, I do sign my commits and tags etc; so if you were very paranoid, you could verify with for example git tag -v 1.3.0-rc.2; but this doesn't really help when all you have a is a pie.phar :)

[PhrozenByte]

Thanks for your detailed answer! This clarifies a lot ❤️

If you have downloaded a pie.phar manually (i.e. you're not using pie self-update), you can run either pie self-verify after downloading it, which verifies itself using the same mechanism described, or you can separately run gh attestation verify --owner=php your-pie.phar (if you have it).

If an attacker already tampered with the pie.phar I just downloaded, he can easily make pie self-verify print whatever he wants. Verification can only be done with tooling independent of what I've just downloaded. pie self-update is such independent tooling. gh attestation is, too. But pie self-verify is not. So it can't be a replacement for gh attestation - or what am I missing?

My first concern is solely focused on user experience: PIE currently requires me to install GitHub CLI to verify that a downloaded pie.phar is genuine. I don't have GitHub CLI installed. How do I verify that the pie.phar I downloaded is genuine without GitHub CLI? pie self-verify unfortunately isn't the answer.

With an .asc I would run gpg --recv-key with the full key fingerprint I've obtained separately earlier, and gpg --verify pie.phar.asc pie.phar. That's it. GnuPG is standard tooling available basically everywhere. GitHub CLI is not. I understand that one can, in theory, verify a pie.phar without GitHub CLI, but how do I actually do that using just standard tooling?

In fact; I had originally planned to use a GPG private key in secrets in this manner, but I had discovered the Attestation feature, which has more benefits than regular GPG signing. […]
This makes me quite reluctant to add a GPG signature to PIE, when we already have an arguably superior approach implemented. […]
The GitHub Attestation feature, from the perspective of "the verifier" (rather than us, "the maintainers"), there are indeed a few GitHub specific things: […] the "trusted root" manifest. This contains certificate authorities from both Sigstore, and GitHub. In theory, you could specify your own trusted root manifest; although the library doesn't support that yet.

My second concern is about this matter and what I call "vendor lock-in". As long as you're using GitHub's identity provider, you give GitHub full authority over PIE. GitHub decides what a genuine PIE release is - and not you (resp. the PIE team). I'm not concerned about the technology.

Let's assume Microsoft shuts down GitHub tomorrow. Switching to a different hoster is easy, so you do that. But how can users verify that a pie.phar they found on some alleged (!) new official website is actually PIE? As far as I understand, you don't sign PIE with your (or: "the project's") key, but are rather relying on GitHub's identity provider. This chain of trust can go away any time. PIE needs its own (or that of the PHP project, or The PHP Foundation, or whatever, just no 3rd party) trusted root.

With a PGP key you wouldn't do that. Yes, you trust GitHub with a private subkey, but the validity of that subkey is limited (the more limited while still being feasible the better) and you, and only you (or: "the project"), have the primary key. So, if GitHub goes away, you just sign your new pie.phar with a different subkey of the same primary key and users can easily verify that the pie.phar they found is indeed genuine.

As far as I understand reducing the required trust in e.g. GitHub is the whole idea of Sigstore and why the technology can indeed be considered superior, but as long as you're using GitHub's identity provider you actually make things worse than with a classic PGP key. But maybe I understand something wrong or totally miss something, I'm by far no expert in this matter, so please correct me then.

[1ma]

I agree with everything @PhrozenByte said. Moreover there's precedent of working this way, as both PHP and Composer have been signing their source tarballs and PHAR executables with PGP for years.

This allows users to fetch, verify and store the signer public keys once and from then on do automated verification of all subsequent releases to detect compromised binaries. This sort of supply chain attack is not theoretical. In fact I started to become more conscious about this kind of attack after being impacted by the CodeCov breach.

As an example from my own Dockerfiles, the following snippet downloads the latest Composer executable and the latest release signature. My repository has Composer's public key committed in it, which I thoroughly checked at the time (and the Git commits like the one that introduced this file are all signed, too). If a malicious actor ever gets hold of the getcomposer.org server or domain and manages to replace the legit composer.phar file with malware the signature verification will fail and abort the build process.

ADD https://getcomposer.org/download/latest-stable/composer.phar .
ADD https://getcomposer.org/download/latest-stable/composer.phar.asc .

COPY composer-pubkey.asc .

RUN gpg --import composer-pubkey.asc \
 && gpg --verify composer.phar.asc composer.phar \
 && install -m 0755 composer.phar /usr/local/bin/composer

I would very much like to be able to do the above with pie, too.

[asgrim]

@1ma as I already pointed out; since the private key used to sign the artifact would be stored in GitHub secrets, verification using GPG is only as good as the security of GitHub. The Sigstore approach we have adopted with PIE is much more modern, and overcomes many of the downfalls of using GPG in CI to sign artifacts.

One suggestion that has been made recently was that we could bundle the attestation with the release; this gives you the attestation, you can then obtain the trusted root bundle, and verify the payload anyway.

FWIW, whilst the Sigstore approach is arguably superior for this particular use case (i.e. verifying the provenance of a build artifact to secure the software supply chain), I appreciate tooling and ecosystem is quite new, and options are somewhat limited. That said, it is an open standard, and I would encourage you to use this mechanism to verify and validate PIE releases.

I am actually working when I can on a separate library (soon to be a CLI tool) that is written in PHP: https://github.com/ThePHPF/attestation - PIE uses this internally when running pie self-update to verify authenticity of the newly downloaded artifact. I am planning on expanding this and making this more generic (for example, the attestations are only downloaded from GH at the moment).

This very topic has been discussed a little on Mastodon yesterday too: https://phpc.social/@timwolla/115841642540768673

[PhrozenByte]

since the private key used to sign the artifact would be stored in GitHub secrets, verification using GPG is only as good as the security of GitHub.

Unless I'm missing something big here, due to the way PIE is currently using Sigstore, it's also only as good as the security of GitHub. Arguably, even worse actually, because it permanently depends on Github.

As far as I understand (please correct me if I'm wrong), PIE needs its own trusted root first to actually make Sigstore better than PGP. GitHub attestations basically tell an user: "This artifact was created in this exact GitHub repository, through this GitHub workflow, at this exact time." This attestation builds upon the https://github.com/php/pie identity. Whoever owns this identity, owns PIE. PIE does not own this identity. GitHub does.

PGP on the other hands tells an user: "This artifact was signed by this exact person/organization." If PIE wants GitHub to sign releases, PIE must indeed give GitHub access to a private key - but only to a restricted sub key, preferably as restricted as reasonably possible, especially in regards to the subkey's validity period. With PGP, whoever owns the root key, owns PIE. No matter what, only PIE owns the root key. Not GitHub.

To make Sigstore actually superior to PGP, PIE must not rely on GitHub's identity, but must use its own trusted root. This can be PIE's own trusted root, or the trusted root of the PHP Foundation, or the trusted root of the PHP project. But not GitHub.

[asgrim]

because it permanently depends on Github.

This is not quite true; if we were to distribute the attestation alongside the release, you would just need the trusted root (which you can save yourself, or using the https://github.com/ThePHPF/attestation library for example), you can verify the authenticity of the artifact entirely outside of GitHub. Just because the attestation was generated in GitHub, does not tie it to GitHub.

GitHub attestations basically tell an user: "This artifact was created in this exact GitHub repository, through this GitHub workflow, at this exact time."

That is exactly the same verification you get with the PGP signature using a key stored in GitHub secrets. Both approaches are equivalent, but Sigstore was really a tool designed for this job; where PGP signatures are more general purpose; and arguably designed for individuals signing an artifact, rather than an automation signing an artifact. This was already alluded to on that Mastodon thread I linked to: https://phpc.social/@timwolla/115841642540768673

PIE must indeed give GitHub access to a private key - but only to a restricted sub key, preferably as restricted as reasonably possible, especially in regards to the subkey's validity period. With PGP, whoever owns the root key, owns PIE. No matter what, only PIE owns the root key.

Indeed, I'm fully aware of this approach, and I've used it on multiple projects before - in fact this approach is used by the laminas/automatic-releases action workflow, so I am very familiar with its set up, but also with its drawbacks.

To make Sigstore actually superior to PGP, PIE must not rely on GitHub's identity, but must use its own trusted root.

This is something that could indeed be looked into eventually; it is worth noting that there are two trusted roots in the list; the organisation sigstore.dev and GitHub, Inc.. If we were to set up another trusted root that is signed by sigstore.dev, and use that going forward to generate the attestations, then the entire existing flow remains unchanged.

I completely understand the desire to "decouple" from GitHub, just the current flow means we can concentrate on developing PIE, and continue using existing tooling. I'd be open at some point to looking into getting a Foundation or PHP Group trusted root set up, but I'm reluctant to introduce a PGP signature, given the alternative approach is, (in my opinion) superior and better suited for the purpose of verifying the authentic source of the built artifacts.

The TLDR is; Sigstore is designed for this purpose, PGP signatures aren't really. I'd rather stick with Sigstore, and improve on this model, than introduce an alternative approach.

FWIW, I'm going to move this to a discussion, as it is very much a discussion now :)