I read that. It says that RSA-2048 keys are going to be safe until 2030. Doesn't
sound like a lot to me... Considering the average human lifespan, I could be
around until 2070. So, nope, not enough.
If all the emails I sent till now have been intercepted and stored (which seems
to be the case according to Snowden), using a RSA-2048 key simply means that all
my private correspondence is going to be public (or at least accessible) in 16
years time. Now, the only thing I'm asking is to raise the amount of secure
memory allocated by GnuPG to 128k to let people use key sizes up to 16384,
something that was even allowed by the keygen itself.

GOT_IT merely tells that a line was received. There is and can't be any more
semantics.

I am not yet sure whether to keep GPG_AGENT_INFO.

I have not asked a single question in this thread; this is a bug report, not a
question. You have not explained adequately why this is not a bug.

Please discuss coding questions at gnupg-deel and not in the BTS.

Please read the FAQ starting with
https://gnupg.org/faq/gnupg-faq.html#default_rsa2048

By the way, is this all bullshit?
AES-256 == RSA-15360 / DSA-15360 (NIST)
http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2006-03/E_Barker-
March2006-ISPAB.pdf

AES=256 == RSA-15424 / DSA-15424 (ECRYPT2)
http://www.ecrypt.eu.org/documents/D.SPA.20.pdf

I could not easily figure out what I was supposed to infer from the source code
of gpa or gpgme, but after playing about with it, I suppose I can detect the
error by noticing that the next GET_LINE issues a keyedit.prompt rather than
continuing with the workflow. This means I will have to write some state-keeping
logic instead of merely switching on the GET_LINE, and all users of this
interface will need to implement a similar thing.

To reduce the complexity for scripters here, might I suggest adding an extra
parameter to GOT_IT to explicitly communicate to the client script about any
errors? At least from the gpa/gpgme code it seems there is a generic parser that
can cope with extra parameters to any status line.

If anyone is affected by this (I don't know of others using this interface),
they can easily rewrite their parsing code to cope with both the old and new
GOT_IT lines (with or without a parameter).

BTW, this is the sort of thing that documentation would be helpful for.

The starting value is Certify+Sign for some options and Certify+Sign+Encrypt for
other options. This should be output in the status file descriptor so that a
script knows what it is doing.

Alternatively, the defaults should be committed to in public API documentation
that is guaranteed to not change, rather than source code. As you said yourself
in ML, one should not rely on the CLI to remain static.

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.