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 ItalianWerner 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.
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.