<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <div class="moz-cite-prefix">On 6/1/25 09:54, Richard Stoughton via

      Gnupg-users wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:CADmVL_7eZ6RQhnpdc+5kv0C7=LrRfCqNx9X_N2sV7j=8BedtZA@mail.gmail.com">

      <pre wrap="" class="moz-quote-pre">[...]

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.</pre>

    </blockquote>

    <p>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.)<br>

    </p>

    <p>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.<br>

    </p>

    <p>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.<span

      style="white-space: pre-wrap">

</span></p>

    <p><span style="white-space: pre-wrap">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.</span></p>

    <p><span style="white-space: pre-wrap">

</span></p>

    <p><span style="white-space: pre-wrap">-- Jacob

</span></p>

    <p><br>

    </p>

  </body>

</html>