dkg developed a reasonsable patch which will be included in the next 1.4 version.

Interesting.

Use "=c" does now work with commit bc8583f2.

Well, I removed all support for GPG_AGENT_INFO.

Thanks applied.

What "that" are you referring to? In all the versions of GPG I've tried, 1.4,
2.0, 2.1 including this current one in git, it is possible to create a
Certify-only master key by toggling off "Sign" (and "Encrypt", for RSA).

I am saying this should be possible for the "=flags" syntax as well. I would be
happy with either "=" or "=c". The latter is clearer, but inconsistent with the
existing syntax in git which ignores "c" completely, and just forces Certify on
for the master key and off for the subkey.

$ gpg2 --full-gen-key --expert
[..]
Please select what kind of key you want:
[..]
Your selection? 8

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt
[..]
Your selection? s

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify Encrypt
[..]
Your selection? e

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Certify
[..]
Your selection? q

[..]
GnuPG needs to construct a user ID to identify your key.

Real name: Testing
Email address: lol@test
Comment:
[..]

gpg: key 0822FCC2D521C45C marked as ultimately trusted
public and secret key created and signed.
[..]

$ gpg2 --edit-key lol@test
[..]

Secret key is available.

pub rsa1024/0822FCC2D521C45C

created: 2014-10-02  expires: never       usage: C   
trust: ultimate      validity: ultimate

[ultimate] (1). Testing <lol@test>

gpg>

and this is for i686 build

yes, i can. this is a gpg-error.h for x86_64 build.

That was never possible.

Can you please paste the generated file?

Hmm, do we need a gpgme feature for this?

setrlimit is your friend - do it right before the exec.

Thanks. Fix pushed.

No bug and I already set this bug to resolved.

Judging by the lack of reply, I assume that this bug won't be fixed, correct?

Hi, this does not currently allow me to set the master key to Certify only. If I
enter "=" or "=c" it just ignores me and goes back to the default value. Looking
at commit 7ff4ea21 I'm not sure why this is the case, since current should be 0
at the end. Setting "=a" gives me a CA-use master key as expected.

It would be good to note in the help text that a master key always has the C
flag, and a subkey does not (as far as the "=" syntax is currently implemented).

My one concern: Some programs in languages with implicit memory management
(Python, Vala) seem to use --list-packets to provide a 'detail view' of
keys etc. On 32-bit platforms, they'll try to allocate > 2^32 bytes of
memory to process a packet composition << 100 bytes; this will cause them
to crash.

This is additional patch for previous message, you'r tracker not allow to
attach more than one file.

D248: 510_07-windows-build.patch

D249: 509_09-fix-generating-union.patch

Werner, we (I'm and Alexpux) was made fix for windows build (x86_64 and i686)
and seems like it works. Patches in attachment. If you want to look at msys2's
libgpg-error package you may use this link https://github.com/Alexpux/MINGW-
packages/tree/master/mingw-w64-libgpg-error

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.

Thank you! This solution sounds good, I will test it this weekend.

Done for 2.1 and 2.0.

Use "=esa" to set all capabilities. Enter '?' for help ;-).

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

Okay, I see what you mean. We allow only toggling the flags and thus you need
to know what are thge defaults.

I propose to add a way to directly set the flags. For example by using a string
like "=cse". That is much easier.

I am not yet sure whether to keep GPG_AGENT_INFO.

FYI, just adding a "Type ? for help." after "Invalid selection." would improve
the situation massively.

Really, which prompts are those?

$ sh
$ ?
sh: 1: ?: not found
$
127

$ ed
?
?
1

$ bash
$ ?
bash: ?: command not found
127

$ zsh
% ?
zsh: no matches found: ?
%
1

$ man man
?
Pattern not found (press RETURN)

$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
?
(standard_in) 1: illegal character: ?

$ gdb
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) ?
Undefined command: "". Try "help".
(gdb) quit

Fuck, even vi tells me "type :help<Enter> or <F1> for on-line help"

$ python
Python 2.7.8 (default, Sep 9 2014, 22:08:43)
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.

?

File "<stdin>", line 1
  ?
  ^

SyntaxError: invalid syntax

$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
λ: ?

<interactive>:2:1: parse error on input `?'
λ:
Leaving GHCi.

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.

If you order such a docuemntation I'll be glad to add it. Contact me at my
company address.

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

You responded to my previous suggestions, and this is my next iteration, with me
trying to take into account your comments.

I find that making related options visually related, helps the user to better
intuitively understand what they do. The current options don't do this.

You also had a comment along the lines of "sign is not accurate because there's
also certify and authenticate", but a few current options also have this flaw. I
think it's OK, but it's better to do this consistently.

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.

If "a complete documentation is not possible", then it is not fit for purpose as
an API to be scripted, and you should stop advertising that functionality in public.

If you do not have time to do this documentation, the correct response is to say
"I do not have time to do this", but leave the bug open, because it is something
to be resolved in the future.

An exposed public interface that you expressly suggested me to use in a script,
is *supposed* to have documentation associated with it. That is basic standard
software engineering. You don't see standard library authors respond with "just
try out the function to see what happens", when someone points out missing
documentation.

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.

Sorry, there is a limit on the size of secret keys which depends on
several factors. We allow for way longer keys than can be generated
by gpg to take the fuzziness in account, but only up to some limit.
You are on your own if you want to use ridiculous long keys.

Hint: You may increase the size of the secure memory my changing the
line

    /* initialize the secure memory. */
    got_secmem=secmem_init( 32768 );

in g10/gpg.c. Use a larger value there and it will work.

Consider this a feature.