2 ms·

This is a good question, thanks for asking it. The specific scope here is a GitHub Acfions workflow, which presents a set of claims (username, repository, work

This is a good question, thanks for asking it. The specific scope here is a GitHub Acfions workflow, which presents a set of claims (username, repository, workflow name, git commit, etc.) that are bound into the digital signature. In other words: the signing key’s intrinsic “identity” includes a stable identifier for the workflow and source code that ran it. This doesn’t stop an attacker with access to the workflow from tampering with the build (nothing can stop that, including an HSM), but it does produce a game-theoretic disincentive: the signing identity will reflect any changes made to the workflow by the attacker, meaning that they cannot simultaneously maintain stealth and craft a malicious signature. (This assumes that the build workflow itself is relatively hermetic, i.e. is reproducible and doesn’t pull random executables from the Internet. But that’s table stakes!)

yjftsjthsd-h 3y ago
> the signing identity will reflect any changes made to the workflow by the attacker, Why? I'm not super familiar with github actions specifically, but AIUI there's a build B with properties (like git hash(es) that went in, user, repo, etc.) P(B), then a signature S(P(B)) that gets either embedded in the final artifact or shipped next to it (I think the former but doesn't really matter). So an attacker with code execution on the build host can write a fake P(B) that claims to represent the right repo+workflow and a plausible git commit hash, but combine with their own compiled binaries and sign that combination. With reproducible builds you could expose this after the fact by showing that that git commit does not build that binary, but I'm not following how end users can tell without doing the compile themselves. Edit: So reading more docs, I think you're going to meet L2 easily, but the plain language claim sounds like L3. However, it kinda reads like L3 just relies on github promising that the build machine won't get compromised, which... I guess if you accept that precondition it works.
- woodruffw 3y ago
  The piece you’re missing is that P(B) is itself digitally signed, in the form of an OIDC token from the GitHub Actions IdP. An attacker can’t contrive it without access to the IdP’s key material. (This is all compatible with reproducible builds, for the reason you’ve noted.) And yes: Build L2 is the goal here. L3 assumes trusted hardware, which is a much higher bar to clear.

yjftsjthsd-h 3y ago

> the signing identity will reflect any changes made to the workflow by the attacker, Why? I'm not super familiar with github actions specifically, but AIUI there's a build B with properties (like git hash(es) that went in, user, repo, etc.) P(B), then a signature S(P(B)) that gets either embedded in the final artifact or shipped next to it (I think the former but doesn't really matter). So an attacker with code execution on the build host can write a fake P(B) that claims to represent the right repo+workflow and a plausible git commit hash, but combine with their own compiled binaries and sign that combination. With reproducible builds you could expose this after the fact by showing that that git commit does not build that binary, but I'm not following how end users can tell without doing the compile themselves. Edit: So reading more docs, I think you're going to meet L2 easily, but the plain language claim sounds like L3. However, it kinda reads like L3 just relies on github promising that the build machine won't get compromised, which... I guess if you accept that precondition it works.

woodruffw 3y ago
The piece you’re missing is that P(B) is itself digitally signed, in the form of an OIDC token from the GitHub Actions IdP. An attacker can’t contrive it without access to the IdP’s key material. (This is all compatible with reproducible builds, for the reason you’ve noted.) And yes: Build L2 is the goal here. L3 assumes trusted hardware, which is a much higher bar to clear.