Securely signing build artifacts (was: Signing a file given its hash only)

Jacob Bachmeyer jcb62281 at gmail.com
Mon Jun 2 05:56:12 CEST 2025


On 6/1/25 09:54, Richard Stoughton via Gnupg-users wrote:
> [...]
>
> So we'll try another approach to preserve the security level of M on L:
>
> H injects a secret nonce into a build run on M. M uses the nonce to
> create a MAC for each artifact it creates. M pushes the MACs along
> with the artifacts to L.
>
> To sign an artifact H fetches the artifact and the corresponding MAC
> to its local file system. Then H verifies the MAC using the secret
> nonce it has previously injected into the build on M. If the MAC is
> valid then H signs the artifact using gpg. Then H pushes the signature
> to L.

A simple variation:  the trusted build operator (someone approves the 
use of the keys stored on H...) generates an emphemeral keypair on a 
secure workstation (perhaps H itself?); the private key is injected into 
M and the public key is given to H as part of the process to approve 
signing build artifacts.  (Presumably, the ephemeral public key ends up 
in an audit log somewhere while the ephemeral private key is destroyed 
when M shuts down.)

To sign an artifact, H fetches the artifact and the corresponding build 
signature to its local filesystem.  Then H verifies M's signature using 
the ephemeral public key created for that specific build.  If the 
signature is valid, H signs the artifact using its secure keys and 
pushes the signature to L, where it is again verified.

This can be done without adding additional software to H aside from 
scripts to drive the process:  gpgv can be used to verify the build 
signatures.  Using symmetric MACs would require additional software, but 
H already needs GPG for its basic job.

The only major problem with this I see is fundamental to this 
architecture: a compromised M can generate backdoored artifacts and sign 
them as if they were legitimate, with H and L none the wiser. Since you 
have mentioned that M is an ephemeral cloud instance, I presume that a 
compromise of your hosting provider is outside of your threat model.

-- Jacob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250601/9b0bb42d/attachment.html>


More information about the Gnupg-users mailing list