I understand you may not have time to work on this since it's not the
bug I thought.

I hope you will just answer one question for me though.

Having imported my key in the system-wide keyring defined in my
gpg.conf, can I safely do without the local pubring.gpg?

Or, is it necessary for some reason that I import my public key back
into the local pubring.gpg so that there will be a double listing of
my key when I do gpg -k?

I am finally understanding what is going on with the duplicate listing
of my key, and now wonder if I have screwed something up with the
procedure that "fixed" the double key.

The reason for getting my public key listed twice as an output to 'gpg
-k' is that it first listed the contents of ~/.gnupg/pubring.gpg (just
my key) then listed the contents of /etc/pacman.d/gnupg/pubring.gpg
which also had my key in it. The reason it listed
/etc/pacman.d/gnupg/pubring.gpg is that was the keyring defined in my
gpg.conf.

My procedure that successfully got rid of the duplicate listing has
actually made my ~/.gnupg/pubring.gpg file empty! So, I don't get a
duplicate because gpg -k only lists the contents of
/etc/pacman.d/gnupg/pubring.gpg.

Will this work as is or should I try to put my public key back into
~/.gnupg/pubring.gpg?

I figured out the steps that led to the duplicate entry in the first
place. After editing ~/.gnupg/gpg.conf to include

keyring /etc/pacman.d/gnupg/pubring.gpg

I generated the key

gpg --gen-key

Then did

sudo pacman-key --import /home/colin/.gnupg

I've filed a bug against pacman-key, but I think it translates to

sudo gpg --homedir /etc/pacman.d/gnupg/ --no-permission-warning --
import /home/colin/.gnupg

And, this is what lead to the duplicate entry. Does it make sense this
would lead to a duplicate entry? Is it a bug of gpg, or is it supposed
to do that for some reason?

This was fixed in gpg4win 2.2.2

A fix for this has been included in gpg4win 2.2.2.

GnuPG already converted the Output but to CP_ACP instead of the
"GetConsoleOutputCP" which was wrong.

Does this now also work for you? I've only tested it with the Codepage for Germany.

After reading your suggestion, I realized using the fingerprint would
be the same as deleting the secret key for "Colin N Keenan" instead of
"Colin Keenan". Since I had made a backup of .gnupg while it was
showing a duplicate public key for "Colin Keenan", I realized that's
what I wanted to do anyway. So, I solved the issue by

gpg --delete-secret-key "Colin N Keenan"
gpg --delete-key "Colin N Keenan"
cp .gnupg/pubring.gpg .gnupg-backup
rm -r .gnupg
cp -r .gnupg-backup .gnupg

But still, this seems like a bug. Is there a better way to remove a
duplicate entry? Also, why is it allowed to have a duplicate entry?

This should be fixed in 2.2.3 (Which will be released soon)

Gpgtar now handles all filenames using the windows 8bit charset. It still does
not support full unicode filenames. For this the fix would have been larger but
at least kleopatra now reacts to gpgtar errors so when you include a File that
can not be handled it will show an error and mention the file that was problematic.

Can you please try to delete it using the fingerprint of the key?

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.

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.

Fixed in master will be backported to 2.0.
That is a very well written bug report. Thanks.

Fixed with commit eecbed0

I beliive it is easier to encapsulate this all in libassuan. This way we do not
need anything on the client side. I have not yet looked on how to implement
that on the server and it may be easier to add an option there.

Nice - i was surprised this wasn't accounted for, so i'm not surprised you
expected it to come up. :)

No worries, i've reverted back to 2.0.x for now and will wait to see how this
goes. A solution using variables like you suggest would be perfect.

For my case, to replicate my previous setup (but without a lot of fussing with
environment variables, which will be nice!) all i really need is HOSTNAME. I
suspect USER and HOME would also be useful in some situations! Perhaps also UID?

Off the top of my head i can't really think of much else that would be useful
but perhaps the XDG_* variables (with appropriate defaults) might qualify?
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

I actually just re-tooled my setup to use $XDG_CACHE_HOME (with fallback to
~/.cache) but that's really over-engineering that i just figured i'd do to keep
from sticking more crap in $HOME.

So you're talking about creating a regular file S.gpg-agent in ~/.gnupg, and
using its contents to point to the actual socket?

That feels a little bit tricksy. I don't mind personally, but i wonder, would a
less surprising method be to introduce a configuration variable in
~/.gnupg/gpg-agent.conf, like:

socket-name /tmp/$USER/$HOSTNAME/S.gpg-agent

Does that make it too difficult to implement at the libassuan level?

Ack

Good, here comes the report I was waiting for. Sorry for using this way of
testing but it is easier to add a fix if tehre is a real problem.

The idea is to fix this mainly in libassuan. If the socket is a real file
libassuan will check for a keyword in the file and use the socket name given
there for access. I already expected that some variabales need to be
substituted like

Socket: /tmp/${USER}/S.gpg-agent

Any suggestions on what variables you need USER, HOME, HOSTNAME ?

Thanks for reporting this.

This is already part of T1624 although T1624 is confusingly named as it
relates to this problem triggered by gpgex.

We will try to fix it or at least report an error in that case for the next
gpg4win release.

Given the low severity of this bug, plus the assurance that v2.1 contains
significant fixes to --list-secret-key, it would be reasonable to close this issue.

FWIW, 2.1 will come with these new commands:

  --quick-gen-key user-id

    This is simple command to generate a standard key with one user
    id.  In contrast to --gen-key the key is generated directly
    without the need to answer a bunch of prompts.  Unless the option
    --yes is given, the key creation will be canceled if the given
    user id already exists in the key ring.

    If invoked directly on the console without any special options an
    answer to a ``Continue?'' style confirmation prompt is required.
    In case the user id already exists in the key ring a second prompt
    to force the creation of the key will show up.

  --quick-sign-key fpr [names]
  --quick-lsign-key fpr [names]

    Directly sign a key from the passphrase without any further user
    interaction.  The fpr must be the verified primary fingerprint of
    a key in the local keyring. If no names are given, all useful user
    ids are signed; with given [names] only useful user ids matching
    one of the- ses names are signed.  The command --quick-lsign-key
    marks the signatures as non-exportable.  If such a non-exportable
    signature already exists the --quick-sign-key turns it into a
    exportable signature.

    This command uses reasonable defaults and thus does not provide
    the full flexibility of the "sign" subcommand from --edit-key.
    Its intended use is to help unattended key signing by utilizing a
    list of verified fingerprints.

There are known problems with listing secret keys but there are no plans to fix
that for 1.4 or 2.0. 2.1 however complete fixes all these list-key vs.
--list-secret-keys differences.

You particular problem might be fixable - I have not yet checked because working
on the 2.1 release is currently more important to me.

GnuPG tried to keep the secring.gpg and the pubring.gpg in sync. However, this
is hard to achieve because it requires lots of code duplication and the syncing
two quite but not complete similar files.

Please do not post bug reports for code under develop to the tracker. You may
of course send it to gnupg-devel.

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>

That was never possible.

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

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.