Any progress on this? Thank you.

Thanks for your ideas. Nonetheless, this patch is used by OBS project for years
in production so we would like to use this solution we know works fine rather
then creating something else. If you would like to see more how it works
internally, look at sign.c[0] and sign daemon[1].

Can we please get to some resolution? Please tell me whether:
1, you will accept such a patch
2, you would accept with changes
3, you don't want anything alike in gnupg for the moment

For the maintainer of gnupg in Fedora is important that we don't include
something that you would include as well, but differently. Thank you!

[0]https://github.com/openSUSE/obs-sign/blob/master/signc
[1]https://github.com/openSUSE/obs-sign/blob/master/signd

Hi,
I see no progress on this RFE report, therefore I want to clarify it more verbosely.
In T1646 (wk on Jun 16 2014, 08:29 AM / Roundup) you asked, why we could not use:

ssh REMOTE 'cd DIR && sha256sum *dat' | gpg -s >files.sig

We could not use this because this will create sign the checksum - not the
payload of this checksum. In other words:
sha256sum create digest, then gpg2 internally create digest of this digest and
will create signature.
What we want to achieve is to bypass creating of digest in gpg2 and accept it as
parameter.

We have 'package build server' and normal signing process means:

1. copy data to signing server
2. gpg2 -sb
3. copy signature back
4. pass signature to rpmsign

But if the data is some iso/docker image or rpm package several gigabytes big,
then we have bottleneck problem. So we
changed the work-flow to:

1. make digest of the data
2. copy digest to signing server
3. gpg2 -sb --digest-algo <algo> --file-is-digest <digest>
4. copy signature back
5. pass signature to rpmsign

If we would do in step 3:

echo <signature> |gpg2 -bs

it would not be signature of header+payload which we want to sign and the
signature would not match.

To sum it up - we want to bypass computation of digest inside of gpg2. As digest
computation is in fact not secret and
it can be delegated somewhere else. Of course you have to trust those
environment which compute that digest. Which we do.
It allows separation of signing server apart from building server and allows us
to secure private keys even more, while
it allows no degradation of performance.

I hope that this clarify it little bit.

In our use case we need to sign big RPMs, DVDs and Docker images. We have a
separate signing server to sign those files and sending all content to the
signing server is a huge overhead for us. Therefore we would like to sign only
headers of that files. In our setup we trust both servers so we can assume that
the signed digest of the given file really corresponds to that file.

Is it more clear now?

It's because the signer for signing the packages lives on another server and
moving all data there to do the signing is inefficient. Therefore this patch
adds the option to sign files using file digests.

D200: 437_0001-Add-file-is-digest-option.patch

Adding the right rebased-to-master patch