I suggest that an option be added for the user to "set same as master key". This
will be the majority use-case.

But this might be done by accident, such as in old shell environments. Do you
consider GPG_AGENT_INFO with a different homedir, to be a valid use case? If
not, you should get rid of it, because otherwise it might be confusing and trip
users up.

Ok, got it. So I can just throw away my key and make a new one?
Fantastic. Thanks a lot.
Sounds a lot like "640K ought to be enough for anybody".
So long, and thanks for all the good work on GnuPG (seriously).

No.

Please read the FAQ on key sizes and if you have a lot of time the countless
discussions on gnupg-users. No, you are not paranoid but you are tuning the
wrong parameters. IT will never be a standard. There will never be any keys
larger than 4k RSA in real use.

Yes, I know how to change the code and make it work on _my_ machine.
There is the tiny problem that everyone else has to do it, too.
Can we make that change the default? I don't see a big problem in using 64k or
128k instead of 32k of secure memory.
By the way, 16k of key size is ridiculous now, but it's going to be kind of
standard in the not so distant future. Or am I too paranoid? :)
Just trying to have a GnuPG key which is future-proof, also taking in
consideration the possible use of quantum computers in the future.

No, he can't. The data received from a keyserver is by defintion unreliable.
It may be any kind of trash. gpg takes care of ensuring that the data (i.e. the
keys) are consistent.

There has been a long and heated debate over this recently on whether the
additional check introduced with 1.4.18 is at all useful. In any case what you
requested is in all recent versions of gpg. I thus close this bug.

The passphrase is taken directly from the tty but the input tdata from stdin.
These are different input sources. The passphrase prompt pops up as soon as gpg
needs it.

You won't see the output on the tty becuase the sender used the
--for-your-eyes-only feature. Here is a trick to show it anyway:

  gpg --output -

[Please send firther usage questions to the mailing list and not to the bug
tracker.]

What I am requested to do to see the output on the tty?
I do not understand that I have to close the input since I've already entered
the passphrase...

GKD hijacks the gpg <-> gpg-agent IPC. It does this for a long time now but
most users don't care about this and the mainainer keeps this as the default.
Everone using gpgsm has always run into this problem.

Yes, this is hijacking.

The gpg--agent emulation of GKD is indeed dangerous. GnuPG consists of several
closely connected components. Arbitrary replacing an compenent breaks the whole
thing. On proprietary systems such a behaviour would be called malware.

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.

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.

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 is a wiki. please fix yourself. Nio bee for BTS entry. Thanks.

No. It should not. Everything else wuld be surprising for a Unix tool.

keys.gnupg.net. 86400 IN CNAME pool.sks-keyservers.net.

As you can see from the above zone entry this is just a CNAME for the standard
SKS pool. The members of the SKS poool are added and removed on the fly and
depending on your DNS resolve it may takle a while until unresponsive servers
have been removed. Sorry. I can't do anything about it.

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?).