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.

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

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.

For 2.1 use --with-keygrip.
2.0 does not use the agent for secret key operations but merely as a passphrtase
cache.

Write a script to do that. It is fairly simple; remember to use --status-fd. I
commonly use awk for such tasks.

Well, I rename it as a reminder for the removal.

ok then, feel free to close

Not enough for my case.
You can see here the script where I met the need :
https://gist.github.com/aeris/8483548

I have to verify 3 or more signatures, and need to ensure each from a different
signer.
Using gpgv to do this will be a huge hack with multiple trustedkeys.gpg creation
with a single key inside.
Worst and more complicated solution than my current one (with only one sed).

A « --ensure-signer » option with « gpg --verify » will be definitely simpler
and more secure and robust.
Or I miss something in gpgv.

You may want to look at the gpgv tool instead.

that tool will be removed anyway. It was only used as debug aid and not a real
tools. I don't know how it happened that it eventually was installed.

No we won't do this. IIIRC, there is another rejected bug report and we also
had a discussion at the ML.

I don't think it makes sense to backport it to 1.5 - it has been this way for so
long. Users of 1.5 should upgrade to 1.6.0.

Right, --help displays only a selection of commands. This is on purpose.
gpg --server is not ready for use and you are ready that it should not be
displayed in the help pager either.

I'll go over your list as time permits. Thanks.

--load-extension is a dummy function. It does not do anything.

Yes, please add your information to the webpage, incl. the exact version numbers
and their dependency/relation to IDEA/idea.c/...

For usability reasons, the "load extension" option could check for idea.c
parameter and reject this explicitly in those versions that don't need/support
this anymore. This might be an option in contrast to change all old forum
entries around in the internet discussing this topic.... ;-)
But this would be another bug report, I guess.

Thanks.

GnUPG 2 actually supports IDEA via Libgcrypt and GnuPG also includes IDEA
meanwhile. Thus the whole idea thing does not make anymore sense.

We may eventually update that web page.

Awesome, thank you!