This won't be fixed for 2.0 but I will consider to do something about it in one
of the next 2.1 releases.

No, you do not need a second bug for --delete-secret-key.

original; report was for the dirmngr package. Won't fix it there.

The context menu of the key manager now has a "refresh key" item.

OpenPGP does not specify this. It is actually not easy to add another format
becuase that opens the path for all kind of attacks. Like with ELF comment
section you can do the same for any other data format. No, there is no ELF
parser in gpg and there won't be one for any other language.

Please take this to the gnupg-users ML or to the OpenPGP WG. Thanks.

Additionally to T1665 (wk on Jul 03 2014, 11:13 AM / Roundup) (outlining that a trust path to the global SSL companies
is available and thus resolving this):

https://files.gpg4win.org is verified by a certificate that is available over
https://ssl.intevation.de/ this site is "verified" by one of the preinstalled
companies. (You are hopefully aware that you just have to send them some bucks
and some unsigned mails with an @intevation.de address claiming that you are
intevation.de to get such a certificate)

We also bought a certificate for codesigning so that in Windows itself you get
an assurance that one of the >100 Root CA's in their certificate program earned
some money from us ;-)

Please check the openpgp signatures or the checksums in our release
announcements and decide for yourself if you trust us. We can just buy your
trust otherwise.

The language designers will almost certainly return the ball by saying that it
is not their job to define signatures :-)

Elves and dwarves aside, could we have a bottom signature format that would keep
files readable for Shellscript, Perl, Python, plain text and maybe a few more by
using the last line in the file as in my example? This is the main request here.

That is something you need to build into your language's interpreter or into the
OS proper (for the ELF, COFF, or the shebank hack). We can't do anything in gpg
with that. It is of course possible todo that. For example many years ago, I
wrote such a system for ELF with gpg used by a tool for signing and a dedicated
verification module for the OS.

If you like to discuss this, you may want to post to the gnupg-users ML.

Or use the new --quick-sign-key command ...

This was fixed in gpg4win 2.2.2

With pinentry 0.9 this works in pinentry-gtk under GNU/Linux.

With pinentry 0.8.4 This works in pinentry-qt4 under Windows.

Gpg4win includes a version with paste support since 2.1.0 (I think)

ssh-add only looks for private key information. If there is a id_rsa-cert.pub file it
will add the certificate, but one cannot add a certificate alone.

There are a couple of problems:

1. gpg-agent doesn't recognize the cert type (ssh-rsa-cert-v01@openssh.com, etc.) so if

it is added via agent forwarding it fails.

2. If the private key is on a card, then there is no private key file for ssh-add to

use. Some cards allow certificates to be stored on the card, and it looks from the
source to scdaemon that there is a way to read it and return it to the agent.

I could give this a try: in the case of #2, do you think it would be a reasonable
addition to gpg-agent's protocol to look for ~/.ssh/id_{rsa,dsa,ecdsa}-cert.pub when
handling a card-based private key? The cert is public info so only better portability
is gained by storing it on the card.

Feel free to send a patch ;-). You may want to publish this feature request on
some mailing list and ask for help.

Isn't it possisble to convert it to standard ssh format and use that with ssh-add?

I am currently lacking the time to add this to gpg-agent.

That is really not a bug but a design decision.

The keyserver interface in dirmngr is quite modular and the idea is to add new
interfaces as need arises. Simlar to the smartcard support in scdaemon.

Given that there is no more need for copyright assignments, adding patches shold
not be major problem. So, yes pacthes are accepted - please do it for now as a
complete separate ks-engine-hkpms.c. If we later see that it shares much code
with *-hpk we can merge it then. This better isolates bugs.

Please stop spamming thius bug tracker.

D263: 517_0004-Make-rsa-FIPS-186-4-compliant.patch

D264: 516_0003-PBKDF-Add-the-omitted-step-from-pksc5v2.1-specificat.patch

D265: 515_0002-Make-ecdsa-FIPS-186-4-compliant.patch

Interesting.

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

Well, I removed all support for GPG_AGENT_INFO.

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>

That was never possible.

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

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.

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.

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.

Nope. We discussed this already at the ML.

Using a question mark on prompts is a common behaviour for at least 35 years.
Thus one can expect that.

That is exactly the idea. Walk it through manually and you see what you need to
type. Adding docs bearks the risk that the docs is not in sync with the code
and thus we would need to run tests to make sure this is the case. The order of
the prompts depends on so many factors that a complete documentation si not
possible.

The same applies for the key export prompt, too. Currently it says something
generic about "the key has no passphrase, please provide one to export".

(My suggested examples also have some visual similarity between actually similar
options.)

What I implemented now is a simple one item cache for the last used passphrase.
This works in all standard cases. Trying more keys is not possible because
unprotecting a key introduces a delay to help against dictionary attacks.

Meanwhile done.

With slightly over 1000 keys in my keyring, it is surprisingly slow to list all
865 sigs on my key:

    $ time gpg --list-sigs --with-colon $keyID >/dev/null
    real    0m22.061s

At first I naively thought the major bottleneck was caused by the trust
calculation, but changing the trust model doesn't seem to help:

    $ time gpg --trust-model=always --list-sigs --with-colon $keyID >/dev/null
    real    0m22.157s

While --fast-list-mode downs the execution time by a factor of 100 (0m0.220s),
the key UIDS are not displayed (which makes it impossible to know on which of
them the signature was added). I didn't benchmark the difference myself but I
don't expect it to be significant, as if I got RFC 4880 right, the UID packets
are being looped over when gpg inspects the signature packets. (OTOH the
primary UID of the signing keys are not printed either when --fast-list-mode is
set, which I can understand as doing so would require costly lookups through
the keyring.)

I wish the user had more fine-grain control on what to skip with
--fast-list-mode.

Thanks!

Guilhem.