Well it took quite some time but I have now commited all 10 patches to master.
I have a fixed a few things (mostly style).

I have not yet added the Fedora patch. I'll ask Tomáš whether he can send me a
signed off patch.

Applied to master will go into 1.7.

There won't be any output if the keyserver responds with success. In other
cases you will see an error message (modulo the resolved bug T1832).
However, even if the keyserver responded with OK, there is no guarantee that the
keyserver worked as expected or that it properly syncs with other keyservers.

To make sure that you key is really on the keyservers, you should ask an
arbitrary keyserver for your key after giving it a few days to sync up.

The actual plan is to restrict the wauys how gpgme can create keys. In the
future there will be only one way to create a key and no way to select an
algorithm. Those who want to use non-default algorithm should resort to the
command line and the --expert option.

Updated patch to check that the requested key usage is SIG before checking for a
secret key.

D296: 793_sign-fix.patch

Marking as resolved since this is available in 2.1 and we are not going to
backport this to 1.4 or 2.0. Thanks.

Reading about
http://www.heise.de/security/meldung/Erpressungs-Trojaner-verschluesselt-mit-PGP-3116677.html

made me think that signing all binaries may not be the best idea. For our
installer we can rule out that it does something malicious as we control what it
does. So signing it is fine. Same goes probably for GpgOL etc.

But the actual encryption stuff (libgcrypt / gnupg) can, of course, be used for
malicious purposes. So there would be the potential for malware using binaries
signed by us. This could hurt our reputation. (technically in terms of Windows
Code Signing Reputation or Anti Virus software)

At least something we should keep in mind while thinking about changes to what
we sign.

I have done some experiment with it, and it works (though I had
to add ASSUAN_*_FDPASSING flags to a couple of places in gnupg).
However, I think I still need some more opinions to make it a
reviewable state.

First, to make all the things work, gpg would need a new
option (or an envvar?) to tell the FD number. Naively, it could
be named as --emacs-fd, which only works if INSIDE_EMACS is set.
However, it might be too specific, and sounds over-engineering to
me.

Instead, we could add a more generic option, say, --pinentry-fd.
With that option, any pinentry could talk to the caller through
the FD with the Assuan protocol. For security, the effect of the
option shall be restricted only when --pinentry-mode=loopback is
set and working.

In that case, it's tempting to make gpg-agent directly talk to
the FD, instead of spawning pinentry. However, it cannot take
advantage of pinentry's libsecret support and the diversion to
other pinentries (GTK+, ...). Also, it might be a similar
concept of --pinentry-program, which I proposed and was rejected.

What do you think?

Actually, I'm not sure about the current recommendation on the
custom passphrase input options. Given the recent bug fixes,
could --pinentry-mode=loopback be publicly promoted? If so,
I'm happy to withdraw this (and perhaps INSIDE_EMACS stuff) and
add a hack to use --pinentry-mode=loopback.

I think this is reasonable. If you want to implement it, I'll review the
patches. Thanks.

Attached a patch to call agent_probe_secret_key() during finish_lookup().

This partially solves the problem by not trying to use subkeys that have no
secret key present. This does not unexpectedly change the existing behaviour
because GnuPG will currently return an error if the automatically selected
secret key is not present.

It does not solve the issue of having multiple potential signing subkeys on
different smartcards, because these are always considered to be present (if the
subkey has been associated with a smartcard).

D297: 785_sign-fix.patch

I wonder if we could / should use this as a replacement for Pinentry-w32?

Pinentry-w32 should die and FLTK could be lightweight enough that werner would
include it in gnupg-w32?

Does this mean that pinentry-emacs will only work when an emacs instance calls

gpg?

Yes, it is the intention of this proposal.

Does pinentry-emacs need to support the case that a program other than

emacs calls gpg?

I don't think it is worth being supported. It would be rather confusing if a
GUI program internally using gpg asked passphrases from Emacs window.

I tend to agree with Werner: adding another pinentry program increases our
maintenance burden, but the new pinentry doesn't add any convincing features,
AFAIK. If there are some significant benefits, please add them. Otherwise, I
think I'll change this issue to wont-fix. Sorry. Nevertheless, thank you for
your contribution! I hope you'll find another way to contribute.

Does this mean that pinentry-emacs will only work when an emacs instance calls
gpg? Does pinentry-emacs need to support the case that a program other than
emacs calls gpg?

Given that FLTK is a C++ library and we already have a Qt frontend, I am not
sure whether adding this is a good idea. The problem is the usual ABI break due
to compiler or library changes. We already had our problems in the past with
the two Qt versions we supported. Adding FLTK would introduce those problems again.

Why are Qt or GTK+ not sufficient for small boxes?

I've pushed this.

"There are not many comments."
The code should comment itself, and /* some comment for block */ really need
only for description the strongly non-obvious actions - like complex math,
optimization (with answer why optimize here) or factorization algorithm O(1) :-).

Dear Neal, I thank you for answer.

This issue's the main goal is getting an answer to a question - Do you plan
support FLTK. I suppose that it may be closed with comment "not need this
toolkit" - so I do not format according to the GNU coding standards - There are
many contentious issues about the format code - 80 chars per line is more then
enough for assembler, but for C++ with templates - not sure.
Your code is your rules, so If you plan to accept FLTK support - I fix all notes.

"Using email"
email "madrat@users.noreply.github.com" is also my email, which I use in
github.com and because I use local git, it will be inserted automatically.

"the rest of the code has a fair number of violations"
For my studies and knowledge - can you post sample of violation?

fwiw, i've now got most of GnuPG cross-building for win32 from a debian platform
using win-iconv. win-iconv doesn't seem to be a terrible choice to me.

Great

I guess you are reporting for GnuPG 2.0 or 1.4.
We already implemented your suggestion in 2.1.

Yes, that patch works for me.

This is Linux From Scratch, pinentry 0.9.7, pinentry -> pinentry-gtk-2, with
fallback to ncurses. No other pinentry program works.

This is KDE environment, Qt pinentry crashes. I can confirm that there's a
keyring password in the Login keyring, which is the only keyring I use.

Nonetheless, the password won't be asked again while the gpg-agent is running,
the password was entered at least once, and the "Remember password (or
whatever)" box was checked.

As soon as gpg-agent is terminated or a session restarted (which also terminates
gpg-agent), next time I try to use the pgp key, I get asked for its passphrase.

What distribution are you using? What pinentry program? Can you take a look
using seahorse to make sure that your password is saved. Once it is saved, it
shouldn't be removed.

The following simple patch works for me and make check still passes. I think it
makes sense to apply this patch given that this workaround is no more
complicated than an existing workaround for something similar (immediately
preceding my change). Can you please test to make sure it works for you?

D351: 776_0001-gpg-Make-ASCII-armor-decoding-more-robust-to-encodin.patch

Thanks for your contribution! A few comments based on a quick skim of the code:

Why are you using the apparently invalid email address
"madrat@users.noreply.github.com" in the headers?

The code is not formatted according to the GNU coding standards (indentation
using tabs instead of 2 spaces; some lines are longer than 80 characters). I'm
not sure how important this is since the rest of the code has a fair number of
violations.

There are not many comments.

When commenting out large blocks of code (as you do in main.cxx), please use #if
0 ... #endif rather than using /* ... */.

@werner: Do we want to add support for FLTK? If so, I'll take a closer look at
this. My main concern is that this is another thing that we have to maintain
and I'm not sure the gtk pinentry is really just a burden for weak computers.

FL/fl_utf8.H in some distros is Fl/fl_utf8.h

D354: 774_fltk.patch

input field tests removed

D355: 773_fltk.patch

D356: 772_fltk.patch

forget add resources

D357: 771_fltk.patch

Patch adds fltk support to pinentry

D358: 770_fltk.patch

D352: 769_gnupg2-2.1.11_redirect_socket_for_tests.patch

D353: 768_gnupg2-2.1.11_gpg_preset_passphrase_socket_redirect.patch

It seems like detecting and correcting this simple manging would be
straightforward to do and relatively self contained.

My mistake. I was talking about gpg-preset-passphrase.
Redirect in gpg-agent works as expected.

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.