Without a real example file, I don't think that the problem can be
reproduced. Thus I'm closing this issue because of the lack of activity
for more than 12 months.

Matter: Thanks for the report! As Werner suggested: Please ask on the
mailinglist if you continue to have problems, until we can somehow produce a
test case and then somebody is able to file a new report.

This is not a bug. The description of --max-cache-ttl reads:

  Set the maximum time a cache entry is valid to @var{n} seconds.  After
  this time a cache entry will be expired even if it has been accessed
  recently.  The default is 2 hours (7200 seconds).

Thus even if you set the cache-ttl-ssh > max-cache-ttl, it will expire after
max-cache-ttl seconds.

I discover patch for gpgme in gpg4win source. (patches/gpgme/01-gpg2.patch)
Claws-mail uses libgpgme-11.dll in gpg4win binary, which includes string
'gpg2.exe'.

I recognize gpgme in gpg4win is official version (on Windows).
We will use this version. Thank you.

1. Claws-mail is based on Sylpheed. but, it doesn't work my environment.

That code is only used if compiled by GCC (GNUC >= 4). Now if clang
pretends to be gcc, it needs to make sure to be 100% compatible with gcc.

Revocations are only an issue with key updates, which must be (and, in fact,
are) made on the basis of preferred keyserver URL's in self-signatures on keys.

With document signatures, the only important issue is to have the key retrieved
from somewhere, if it is not known to the verifier. I cannot see any way in
which an attacker can make things worse for anyone, if retrieval is attempted
from URL's in unhashed subpackets if the key is not available.

The application that I am working on is a pontentially very large archive of
signed documents (financial transaction authorizations) that also contains the
corresponding keys. The archive is supposed to be distributed/redundant, with
both the documents and the keys available from multiple servers and it can also
be migrated from one server to another. Servers can go online and offline all
the time, no address is permanent. It is trivially easy for a server to include
its own address into an unhashed subpacket and very useful, too. The server does
not have access to private keys.

Nothing needs to be explained to users if they can simply
gpg --verify document.asc
after retrieving it from the server. Much more needs to be explained if
instructions are necessary where to retrieve the corresponding public key.
Polluting the HKP/SKS infrastructure with all the keys (most of which are
disposable) that we use would impose an unfair burden on the infrastructure and
as such would be a very irresponsible thing to do.

Revocations are an issue as I explained. I also don't see a point in not
putting them ins signed subpackets. There is no technical problem with that.

I guess your use case is to add a keyserver URL to a signature later to have an
easier way to retrieve the key. Tinkering with a signature after it has been
created is not a good idea - you can't easily explain it to people.

I would need to look it up myself. This has been implemented back in 1998 or 99.

How would not emitting an extra LF interfere with empty messages?
Has this decision been debated? If so, could you point me to the discussion?
Thank you in advance!

I respectfully disagree:
What you write is true for certification signatures, but not for document
signatures. Updates of keys should be driven by keyserver preference indications
on self-signatures on that key and those must obviously be hashed.
However, OpenPGP very cleverly allows for keyserver URLs in document signatures
and does take them into account. They are used for only one purpose: do download
the key if it is not known. In this case, unhashed subpackets are as good as
hashed ones (actually, better), because the cryptographic binding between the
signature and the public key can be verified anyway, there is no such thing as a
wrong source for the public key, if it does correspond to the signature.

That's a known limitation of the protocol. We need this to allow for empty
mesages. Clearsigned messages are anyway only a compromise.

Well, that is clearly an installation error. You must install one of the
available pinentries. Distributions usually have a dependency on pinnentry.

See also T1370

Duplicate of T1370

cat(1) is not expecting any input thus you see the broke pipe from the first gpg(1).

David, what do you think about sending long keyids to the keyservers?

D149: 332_1340.diff

Attached is a proposed patch that should permit passing long keyIDs or full
fingerprints to the keyservers.

Given that the referenced draft was written in 2003, we now have 8 years of
documented expectations that keyservers can do this. The dominant keyserver
implementation today (SKS) can handle this with no trouble.

It may be that these days keyservers can cope with long keyids. However old
keyservers are not able to do that.

this is not a limitation of the keyservers; gpg itself is stripping all but the
short keyid. adding "--keyserver-options debug" to the command shows that in
every case, gpg is requesting the following URL:

Libgcrypt does not support 64 bit Windows yet. In particular do not use it even
if it would build and run fine. MSVC is not a supported build platform anyway.

Okay, I'll add a note to the option.

If this behavior is by design, could at least documentation (man page or
/usr/share/doc) be updated to say so? Some notice in either (or both)
--with-colons and --keyid-format entry saying that --keyid-format (and possibly
others) will be ignored when --with-colons is used.

That is not a bug. --with-colons is the machine interface and it does not
return abbreviated information as the human readable output does.

We had some other reports on the ML about similar problems. Really time to go
after it.

So, I understand this can't be fixed in software?

There is no cache for smartcards; depending on the type of smartcard they
remember their PIN until they are powered down. With the OpenPGP card you may
use the gpg forcesig subcommand to force a PIN entry for each use of the
signature key.

I've now switched from gcc4.3 to gcc4.4, and this warning is no longer emitted.

That is a limitation of the keyservers.

Sure, you import all the keys store in secring.gpg. What you need to do is to
export the keys you want to import:

Because it is a user program and not a daemon.

there was no crash or disc problem. also logs are clean. only ram+swap was a few
times nearly full (so perhaps not enough for gnupg). why gnupg don't reports
problems to syslog?

This due to a system crash or a disk problem (out of space). GPG uses a
copy,change,rename scheme for any updates of a keyring file. If a problem
occurs the old keyring is still available as .tmp file. If there was a disk or
permission problem, gpg even tells you about this backup file.

That's not a bug.

FIPS requires anyway a specific machine and a specific built binary.

That must be a problem of the FreeBSD ports. GnupG comes with a man page. On
my system I can do

man gpg

for th1 1.4 GnuPG and

man gpg2

for the 2.x gpg. Please report to freebsd.

This is not a bug but expected behaviour: We want to show the pinentry on the
correct xserver or tty and thus gpg-needs to know which one it is. The manual
has even a hint how to show the pinentry on the client machine:

That is a problem of your scanner software.

No, it is an error. See option --preserve-permissions.