You better take that to ArchLinux. We can't debug the system for you. Of
course I will help fixing the problem if you post your findings to gnupg-devel.

Fixed for 2.1. I don't think backporting makes much sense. Upgrading to 2.1 is
for sure the better solution if you have a real problem with that behaviour.

Recently fixed.

Fixed for the next releases. The exact key depends on the Windows versions; I
added a repective note. Thanks.

Fix will go into 1.4.17.

Fixed in 2.0.23.

Right, it should work in 2.0.23.

@werner: I think, you mean 2.0.23

Should work in 2.0.13

Backported to 1.4. It has also been applied to master some time ago.

Backported parts of the change to 1.4.

I took the simpler solution of removing that outdated man page.

The man page is outdated and we do not use docbook for a long time
now.  If someone wants to revive such a man page, it would be best to
translate the respective parts of the GnuPG manual in git master.

You need to configuire gnome-keyring-daemon not to hijack the gpg-agent. This
is done by not adding gpg to the
--components
options. It is a long standing GNOME problem that they willfully hijack the
interprocess connection to gpg-agent. This leads to lots of bug reports
directed to GnuPG and thus I finally added this warning.

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?

The reason codes have been introduced for gpgms and when adding them to gpg it
was not easy to get the required information (think subkeys and primary keys).

As a first take on this I just pushed some fixes to master and introduced two
new reason codes. At least this one should be easy to backport to 2.0.

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.

I agree.
In fact, there is no README.GIT in this repo (at least not in commit
2f4e8c33b88d), but only a README.SVN

The correct fix for the issue on my system (OpenSUSE 13.1) is to run "automake
--add-missing" before running autogen.sh
This will add "build-aux/test-driver"

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.

Fixed for master.

Fixed for 2.0.23 and master.