Page MenuHome GnuPG

no status-fd message indicating current flags
Closed, ResolvedPublic

Description

When generating a key and "setting my own capabilities", --status-fd shows me

[GNUPG:] GET_LINE keygen.flags
[GNUPG:] GOT_IT
[GNUPG:] GET_LINE keygen.flags
[GNUPG:] GOT_IT

and so on. However, it does not tell me the original starting value for the
flags. The starting value is not easily predictable across the different
algorithms, and I cannot expect GPG to keep it constant across releases.

The status fd should at least show me the current flags when it outputs GOT_IT,
so that my script can know it did the right thing.

Details

Version
2.1.0

Event Timeline

There are no starting values. Please use the source code.

werner claimed this task.
werner added a project: Not A Bug.

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.

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

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.

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.

Done for 2.1 and 2.0.

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

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

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

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>

Interesting.

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

werner removed a project: Restricted Project.