That ain't no bug. gpg is waiting for input data. Enter it on the terminal,
provide a file or feed it from stdin.

----Messaggio originale----
Da: gnupg@bugs.g10code.com
Data: 13/12/2013 16.19
A: <gfrisani@libero.it>, <wk@gnupg.org>
Ogg: [issue1578] translation in Italian

Werner Koch <wk@gnupg.org> added the comment:

Send it to translations@gnupg.org. However, it is too late for 1.4.16.

---

status: unread -> chatting

---

g10 Code's BTS <gnupg@bugs.g10code.com>
<T1578>

---

For the record. This is now optional in pinentry 0.8.4 you can pass
--enable-pinentry-qt4-clipboard to configure to enable clipboard and paste support.

I did not activate debugging; but also have moved to 2.2.1 of the gpg4win tool
collection and can no longer replicate the problem.

Don't run it under debugger.

This is not a worth a bug report. If you want to discuss this topic, please use
the gnupg-users mailing list. We can't answer indivdual questions by means of a
bug tracker.

That is not a bug. During import GPG removes invalid or unneeded parts,
reorders packets to fix bugs introduced by some older keyservers, and so on.
During export some other stuff might be removed depending on certain GPG options.

If you want to learn about the details please write to the gnupg-users mailing list.

It has been told for ages that the value of the exit code is not a reliable way
to get information from gpg. Use the --status-fd information.

Someone should check whether this has been fixed in the soon to be released 2.0.20.

My guess: Whoever wants to use said certificates would add them bey themselves …
I don’t see the need for adding them by default.

Because I was able to verify the origin of these root certifciates. But see the
comments. The German signature law imposes some strict requirements on
qualified signatures; despite that GnuPG is not certified, it is prepared for
such a certification.

To me this is still a bug (why only some more or less random German CAs only?).

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.