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.
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
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.
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.
PKIX is entirely broken. Even the most expensive SSL certificate does not get
you any assurance. To avoid man-in-the-middle threats, please check the OpenPGP
signature with an existing version of gpg4win or compare the published
SHA-1checksums with those from the announcement mails.
Done for 2.1 with commit 03018ef
Fic for master with commit c434de4. However decryptyed files are not subject to
this because that would for sure breakk too man applications.
Just for my information, do you have done some tests for GnuPG2 on boot (because existant script are based on gpg) ?
okay.
Hello Werner,
Applied to master and 2.0.
I'll apply the patch. Thanks.
I don't think that it is worth the trouble. A pinpad reader make most sense on
desktop machines and there we have 2.x. 1.4 is maintained for use on servers
where card support is anyway hard to operate.
I can confirm to you as I've write last time, but this time with new gnupg2 (2.0.24)
and gnupg (1.4.16) version, than Vega reader works fine with gpg-agent, but failed without it.
It seems that you missed the patch attached to the original submission, which
has all the required info: vendor ID is VENDOR_GEMPC (0x08e6), product ID is
0x3437, and the change to be applied indeed is in the internal CCID driver.
The reader is supported by PC/SC-lite, which never uses non-null NADs.
In 2.1.x (development), scdaemon and its pinpad support has been improved
(including name change from "keypad" support), and it's backported to 2.0.x.
However, it is not backported to 1.4.x. For gpg of 1.4.x, it only works when
you use gpg-agent and scdaemon of 2.?.x.
Some fixes (such as PC/SC support for MacOS) are backported to 1.4.x, though.
For Covadis Vega-Alpha, we would need to backport pinpad support improvement, as
well as CCID driver support improvement (for no auto configuration feature).
Changes are not trivial to merge, I don't know if it's worth for 1.4.x.
Could you please give more information, such as its USB vendor ID and product ID?
I assume that you are using GnuPG's internal CCID driver.
If you have a patch, please attach it here.
Is the reader supported by PC/SC-lite? If so, we could see how it is handled.
Fixed in master.
I meant 2.0.24 of course.
Done for 2.0.14 with commit e790671c
I consider to do this for 2.1
I improved the description in GIT master. This will be used for all
new releases. For 2.1 it reads:
--export-secret-keys
--export-secret-subkeys
Same as --export, but exports the secret keys instead.
The exported keys are written to STDOUT or to the file
given with option --output. This command is often used
along with the option --armor to allow easy printing of
the key for paper backup; however the external tool
paperkey does a better job for creating backups on
paper. Note that exporting a secret key can be a
security risk if the exported keys are send over an
insecure channel.
The second form of the command has the special property
to render the secret part of the primary key useless;
this is a GNU extension to OpenPGP and other
implementations can not be expected to successfully
import such a key. Its intended use is to generated a
full key with an additional signing subkey on a
dedicated machine and then using this command to export
the key without the primary key to the main machine.
GnuPG may ask you to enter the passphrase for the key.
This is required because the internal protection method
of the secret key is different from the one specified
in the OpenPGP protocol.Thanks
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.
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?
Hello Werner,
This has recently been discussed at gnupg-devel. We have patches ready for 1.4
Ah well, you better do not use automake 1.13 - the test suite may or may not
work with that braindead new defaults of that version.
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.
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.
Hello Yutaka,
With current 2.0 branch of git repository, I believe that Vega-Alpha works fine.
Please confirm.
Please explain why you need new options in gpg.
Adding the right rebased-to-master patch
Won't happen. Please read the FAQ. IF you need to discuss this, please do that
at gnupg-users@
As it turns out the patch also prevents false negatives when
using the "verify" button on the signature file instead of
the signed file.
A couple of screenshots:
http://www.fabiankeil.de/bilder/screenshots/patched-gpa/
That was some kind of spam. The attachment was a made up page with an innocent
text linking to some other side.