I'm also interested in this, since i want to make it possible to easily build a
win32 version of gpgv.exe on debian systems. This is possible without iconv at
all in 1.4.x, but i would rather we ship a gpgv from 2.1.x in the future.

Ideally, there would be a mini-game, perhaps, space invaders. As the user
plays, we automatically harvest entropy!

Why is this a reasonable assumption? This proposal changes the way that GnuPG
has been working for years and will inevitably break someone's setup. It would
be much better for the receiver to use a non-critical notation to indicate the
desired behavior.

Thanks for the hint. I removed the entire section.

File? No hardware token?

I would rather add a "Sign all binaries" installed by us capability to the
packaging process then a special case handling for GpgOL. Especially for the
Uninstaller this would make sense at it requires privileged execution and is
currently unsigned.

But this would mean that we either need to split up the packaging process to
first create the binaries and on a different system (with the code signing
certificate available) create the NSIS Packages.

Or that we expose the CodeSigning certificate to the build system, which
probably makes the most sense as the build system already should be a secured
environment and we only build / execute code which we verified.

I could imagine implementing this as a configure option --with-codesigning-cert
or something thats optional during the build and which you can provide with the
certificate file.

Fixed with commit 12c665b for gnupg 2.1.11.
The patch is different to not break the translations.

The text now reads:

This is a revocation certificate for the OpenPGP key:

pub rsa2048/71201A64 2016-01-21

Key fingerprint = F6B8 598F 5E71 5104 D13C  1415 58D4 85FF 7120 1A64

uid baz@example.org

A revocation certificate is a kind of "kill switch" to publicly
declare that a key shall not anymore be used. It is not possible
to retract such a revocation certificate once it has been published.

Use it to revoke this key in case of a compromise or loss of
the secret key. However, if the secret key is still accessible,
it is better to generate a new revocation certificate and give
a reason for the revocation. For details see the description of
of the gpg command "--gen-revoke" in the GnuPG manual.

To avoid an accidental use of this file, a colon has been inserted
before the 5 dashes below. Remove this colon with a text editor

before importing and publishing this revocation certificate.

Thanks, now this works as expected for me :-)

Go ahead with T2071.

[11:26:04] <gitbot> [git] GnuPG - branch master updated by Werner Koch:
4997433 agent: New option --pinentry-timeout

Good idea.

I don't count win-iconv a small helper.
We can solve this problem more easily by moving the ut8conv.c code to
libgpg-error which alread has some of the conversion code.

I change the category to whis because this is not a bug but a build requirement.

This was implemented for 2.1. We won't backport it to 1.4 or 2.0.

Right, getkey_next had a somewhat surprising semantic. I fixed that with commit
b280aa6.

It also works with ECDSA keys.

Current master b2da3951 segfaults on me.
Btw. I think this is likely because i have a local ID without an Authentication
subkey for aheinecke@gnupg.org

(gdb) run --export-ssh-key aheinecke@gnupg.org
Starting program: /opt/gnupg/bin/gpg2 --export-ssh-key aheinecke@gnupg.org
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: enabled debug flags: memstat

Program received signal SIGSEGV, Segmentation fault.
lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116

3116 *ret_keyblock = keyblock; /* Return the keyblock. */
(gdb) bt full
#0 lookup (ctx=ctx@entry=0x6dd940, ret_keyblock=ret_keyblock@entry=0x0,
ret_found_key=ret_found_key@entry=0x7fffffffd998,

want_secret=<optimized out>) at ../../g10/getkey.c:3116
    rc = 0
    no_suitable_key = 0
    keyblock = 0x0
    found_key = 0x701980

#1 0x0000000000415bb6 in getkey_next (ctx=0x6dd940, pk=0x0, ret_keyblock=0x0)
at ../../g10/getkey.c:1636

rc = <optimized out>
found_key = 0x0

#2 0x000000000045713a in export_ssh_key (ctrl=0x6dd810, userid=0x7fffffffe420
"aheinecke@gnupg.org") at ../../g10/export.c:1437

getkeyctx = 0x6dd940
keyblock = 0x6fd160
desc = {mode = KEYDB_SEARCH_MODE_SUBSTR, skipfnc = 0x0, skipfncvalue =

0x0, sn = 0x0, snlen = 0, u = {

name = 0x7fffffffe420 "aheinecke@gnupg.org", fpr = "

\344\377\377\377\177", '\000' <repeats 17 times>, kid = {

4294960160, 32767}, grip = " \344\377\377\377\177", '\000'

<repeats 13 times>}, exact = 0}

curtime = 1452288169
pk = 0x0
identifier = 0x6ddb80 ""
mb = {len = 0, size = 4096, buf = 0x6e5d70 "", out_of_core = 0}
fp = 0x6dd810
b64_state = {flags = 7199040, idx = 0, quad_count = -153676256, fp =

0x10, stream = 0x6dd800, title = 0x6ddb80 "",

radbuf = "\000\000\000", crc = 0, stop_seen = -1, invalid_encoding =

0, lasterr = 0}

fname = 0x7fffffffe420 "aheinecke@gnupg.org"

#3 0x000000000040dc00 in main (argc=1, argv=0x7fffffffdfe8) at ../../g10/gpg.c:4193

pargs = {argc = 0x7fffffffdb9c, argv = 0x7fffffffdb90, flags = 32769,

err = 0, r_opt = 0, r_type = 0, r = {ret_int = 0,

ret_long = 0, ret_ulong = 0, ret_str = 0x0}, internal = {idx = 2,

inarg = 0, stopped = 1,

last = 0x7fffffffe420 "aheinecke@gnupg.org", aliases = 0x0,

cur_alias = 0x0, iio_list = 0x0}}

a = 0x6dd800
orig_argc = 0
orig_argv = 0x6ddb80
fname = 0x7fffffffe420 "aheinecke@gnupg.org"
sl = 0x0
remusr = 0x6ddb40
locusr = 0x0
nrings = 0x0
afx = 0x7fffffffe420
configfp = 0x7fffffffe420
configlineno = 27
parse_debug = 7198720
cmd = aExportSshKey
malloc_hooks = {malloc = 0x405ee0 <gcry_malloc@plt>, realloc = 0x406d40

<gcry_realloc@plt>, free = 0x406290 <gcry_free@plt>}

ctrl = 0x6dd810

Done with commit 4970868 to be released with 2.1.11.
This uses a new command and not an export option so that export options can be
kept in the conf file.

ECDSA keys (NIST keys) do not yet work.

Right, this is what I actually had in mind. Using the "<keyid>!" notaion it
would also be possible to export any primary of subkey in ssh format.

Hm, this is indeed fixed for pinentry-gtk2 and pinentry-gnome3, but pinentry-qt
is still broken:

0 $ DISPLAY=:3 pinentry-qt
QXcbConnection: Could not connect to display :3
Aborted
134 $

That fingerprint looks more like gibberish than something which should be
compared by the user. In that regard a SHA-1 fingerprint looks much more
serious and IMHO will be more secure than a base-64 fingerprint where you have
to explain that the users also need to match the case - if they are at all able
to compare that fingerprint.

We should take this to the mailing list.

It is base64 trimmed the last '='.

Introducing new specifier, say %f, would be good, while keeping %F as is.
%f includes the hash algorithm string as SSH does.

I confirmed that this is fixed in 2.0 and 2.1.

I wonder if this is a Problem for the new version that can send through
exchange. Available from ( https://wiki.gnupg.org/Gpg4win/Testversions ) We look
up the sender address with exchange a bit differently and I think it should
match the actual SMTP address used now.

It seems to be base64:

% ssh -V
OpenSSH_7.1p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E md5 -q
playfair.gnupg.org RSA MD5:cc:dd:46:8e:ef:3d:d9:34:97:f8:b8:5a:59:51:80:4a
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E sha256 -q
playfair.gnupg.org RSA SHA256:KCh034SD0rMKqCkJbdH2wx354s1278tqt9F+xb5cidg

The keyserver preferences are major privacy problem. They should not be used
and in fact they are ignored in Tor mode. Thus we should not put too much work
in fixing this wish.

In GnuPG 2.1 most binaries carry version information and an icon.
We won't port that back to GnuPG 2.0.

6.7 still shows MD5 fingerprints thus switching won't be easy. Does the SHA-256
fingerprint use Base32? If that is the case it might be a serious UX problem
because most people are used to look for colon separated hex digits.

Secure deletion is a hard problem that depends on the operating system and the
file system used and might even depend on the hardware. I'm not sure if the way
mentioned in this wish would result in "Secure deletion".

GnuPG is not the tool for this.

Related issue: #1166.

Now that we have a dirmngr daemon, this should be feasible. I plan to implement
it like this:

Add two flags to the KS_GET command, --enqueue and --drain-queue. --enqueue
merely enqueues the key id and returns immediately, unless --drain-queue is
given.

This will also help us address issue #1827.

I'd be happy to implement this, but it is not clear to me how. Merely base64
encode the default representation? Or the canonical representation?