We're currently using file type-specific signing tools (textsign, helmsign, rpmsign) for GPG packages, creating network strain by transmitting entire packages to a signing server.

To optimize this, we're considering digest signing: generating a SHA-256 hash of the package and signing that instead. However, we're unsure if this is standard practice.

Here's our approach:

Generate a SHA-256 digest of the GPG package using sha256sum or openssl. (Is there any other option?) Use the digest as input for GPG signing. Questions:

Is this approach of digest signing a standard approach for GPG packages? Are there better alternatives for optimizing GPG package signing? Since verification relies solely on the SHA-256 file, wouldn't bundling it with the signed package be necessary? We appreciate any insights or suggestions for streamlining our GPG package signing process.


1 Answer 1


It's fine to sign a manifest instead of an entire file. Git and Git LFS do this, as do many Linux distros, and it's a standard and well-known technique. As long as the digest(s) you use are secure (and SHA-256 is), it won't be possible to modify the manifest or the files without being detected.

Usually the manifest is created using something like sha256sum -b (the -b is recommended for compatibility with Windows), or a variant using --tag (which is more common on BSDs and more convenient if you want to sign multiple digests of different hashes). Either can be verified using the same tools.

However, if you're trying to sign things like RPM packages, then if you want RPM to verify them (which, typically, you do), you have to sign over the data specified in the packaging format, which is not just a hash of the file. Usually when signatures are embedded in a file, there are some chunks that don't get included so that the file can be modified to insert the signature without invalidating it.

Moreover, OpenPGP doesn't just compute a signature over a hash of the file. There is additional information, including signed subpackets, that must be included in the signature in order for it to validate. RFC 4880 has the details for a binary (type 0x00) signature. You could write a server that accepts and validates the OpenPGP signature (including subpacket) data, along with the final hash of that data, and signs it, and then compute the signature data and hash on the client side. This will be easier if you do this with a tool that mimics GnuPG's command-line functionality, since RPM typically doesn't interact with other tools, but it's still nontrivial.

I can't speak to the other formats, but I suspect they are probably similar. Whether you can offload the digest computation to the client easily depends on the format and what's being signed.

  • $\begingroup$ FWIW Java also signs a manifest -- but not MANIFEST.MF because that was already defined before signing was added, so jarsigner creates a second manifest named {keyid}.SF plus a PKCS7 detached signature named {keyid}.{RSA|DSA|EC} $\endgroup$ Commented May 9 at 0:04
  • $\begingroup$ This is very informative. Thanks. $\endgroup$
    – undefined
    Commented May 10 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.