Hi,
we would like to include a patch for signing file digests from the OBS project
that is used by and required for the signer[1]. Would you please consider to
include this option? We would like to start using obs-sign in Fedora and we
would prefer if this would be included in gnupg itselt.
Note: We changed the name of the option from the original patch from
'files-are-digests' to 'file-is-digest' as multiple files are not allowed.
Attached patch includes also changes to man and info pages.
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.
That still does not explain why you need to change gpg for this. I know every
well why a list of checksums is sometimes useful. It is actually a pretty
standard use pattern. I can't see the problem you try to solve.
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?
No. It still does not explain why you need a new option for gpg. Something like
ssh REMOTE 'cd DIR && sha256sum *dat' | gpg -s >files.sig
does what you want.
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:
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:
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.
You should have said this directly ;-) IIRC, we have a similar request
in the bug tracker. The problem here is that you need to save the
internal state of the hash computation, then restore the hash on the
server and continue the hashing, and finally return the state of the
hashing to the signing box which will then finalize it. There are all
kind of complication with that (e.g. marshaling and unmarshaling the
state) so most people turned to the simple and easier to understand
solution of signing a MANIFEST file.
However, with 2.1 it is possible to implement a more elegant solution:
You run gpg on the server and gpg-agent on the client. gpg-agent
takes care of the secret key operations while gpg does the bulk data
and public key stuff. To implement that the gpg<->gpg-agent IPC needs
to be changed from local sockets to TCP over some encrypted tunnel. I
have not checked whether ssh is already able to proxy a local socket -
but if it can do so, you have an instant solution.
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
No, the patch is a hack which works just for you and not for other environments.
As I already explained a proper solution will be quite complicated and it won't
be the Unix way.
I like to help with the proposed 2.1 solution. However, the fastest thing to do
is to change the system to sign a manifest file. That is more flexible and
makes it easier to add additional signatures.
Indeed and that is a standard feature of 2.1. It is even by default enabled. See --extra-socket in the the gpg-agent man page.
May I close this bug?
Updated patch
I talked to some of the team involved. The patch adds a particular switch and behavior to implement an ISO/rpm/general signing server with detached host for holding the secret keys. You already indicated that you consider it a "hack", and that the 2.1 changes regarding gpg-agent are the better upstream alternative.
(It's not a consideration for GnuPG, but it would require some downstream implementation effort, plus access control for the network transport for the agent socket)
If you think that this proposed functionality has no use case and that this has no change of getting merged you can close this bug.