Although the patch is not very intrusive to other parts of GnuPG,
I do not like it for several reasons:

• Armored is detected by the file's suffix. That is not the Unix way.

• open and close is used - we should avoid that in new code. Always use es_ functions for better portability.

• There is new function to create some temp dir despite that we already have such functions elsewhere. I have not seen the immediate reason for it.

My suggestion was to read the file into an estream object and change
the dearmor and keydb_add_resources to be able to work with it. There
is a unarmor_pump_new function which could be a starting point.
Granted, this would be a much more intrusive change and thus I doubt
that it is useful to spend too resources on it.

Can you please back out that commit.

BTW, please do not put a "cleanup" label in the mid of a function and
according to GNU standards initialized variables deserve separate
lines and statements.

Thanks for your suggestions. We have simplified the key generation process, do
you mind to re-evaluate it?

% gpg2 --gen-key
gpg: WARNING: unsafe permissions on homedir
'/home/teythoon/repos/g10/local/gnupghome'
gpg (GnuPG) 2.1.12-beta119; Copyright (C) 2016 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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!
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Otto Normalverbraucher
Email address: otto@example.invalid
You selected this USER-ID:

    "Otto Normalverbraucher <otto@example.invalid>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 81F88C88 marked as ultimately trusted
gpg: revocation certificate stored as
'/home/teythoon/repos/g10/local/gnupghome/openpgp-revocs.d/5FB9D2A5255C94E3D06B5B563C8167E481F88C88.rev'
public and secret key created and signed.

gpg: checking the trustdb
gpg: public key of ultimately trusted key 909DD699 not found
gpg: public key of ultimately trusted key 5F2FA2F6 not found
gpg: public key of ultimately trusted key 5B81A1FD not found
gpg: marginals needed: 3 completes needed: 1 trust model: PGP
gpg: depth: 0 valid: 5 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 5u
pub rsa2048/81F88C88 2016-04-05 [S]

Key fingerprint = 5FB9 D2A5 255C 94E3 D06B  5B56 3C81 67E4 81F8 8C88

uid [ultimate] Otto Normalverbraucher <otto@example.invalid>
sub rsa2048/3E5BDFAF 2016-04-05 []

Fixed in 9354293.

gpg-agent does disable core dumps both in the stable and modern version.
Furthermore I have to agree with Werner here, if there is a process that can
ptrace your gpg-agent, then you have already lost anyway.

Fixed in abb352d.

Ok, if you agree that this is a useful feature then I will implement it.

Adding an API to the --quick-* commands of gpg 2.1 is no my shortlist for GPGME.
This will make things much easier - including key signing.

I can understand the reason to avoid binary data in a repo.

I have not checked but iff we use estream to access a plain old keyring it would
be possible to use the existing unarmor code and feed that to an es_fopenmem
object.

No, FLTK is not lightweight. It actually adds the requirement for a C++
compiler to GnuPG. And pinentry-w32 shall of course not die!

It is not trivial, but I guess we could create a temporary keyring and import
the key. But to be honest I don't understand why storing base64-encoded random
junk is somehow better than storing the junk itself, I mean it wont diff better
or something.

Just did it.

In sexp.c we use suitable_encoding to decide on how to print the value: Either
as token, as an escaped string or as a hex-string. This is only done when using
FMT_ADVANCED. We could come up with some heuristics on how to print in base64
instead of hex (i.e. |YWJj| instead of #616263#) but that has the drawback that
the output would not be readable by older versions of libgcrypt.

Hwoever, what can be done is to make do_vsexp_sscan work with base64 encoding -
as of now such a value is simply ignored.

Actually we are working on a 64 bit version.

Werner what is your opinion on this?

pinentry-w32 is broken. It does not handle variable string sizes and there is no
easy way to fix that. Afaik it was never intended as the "default" windows
pinentry but only as a crutch for windows ce experiments.

Would fltk be lightweight enough for your to replace pinentry-w32 in your
installer? In that case I think we should take a serious look at this patch as a
minimal pinentry version for windows.

(And delete pinentry-w32 instead)

I think in my previous messages the most important feature I'm missing was not
clear as I've mostly talked about subkeys and ECC curves. But what really
hinders me in making Kleopatra's key gen dialog more user friendly immediately,
even with default parameters for the key, is the API limit of only one user ID.

Meanwhile I also commited the Fedora patch.

Leaving the GUI vs. Commandline argument aside. I still think the batch keygen
API needs to be "modernized"

E.g. with improved authentication support in gnupg 2.1 it will become more
common to generate a key with an authentication subkey. Even the common case of
different Certify / Sign / Encrypt subkeys is not supported by the current API.

Maybe the Curves / Algos can be split up but I think gpgme needs API to query
supported Curves / Algos from GnuPG as this is more dynamic in GnuPG 2.1 then it
has been in previous versions.

Great! Thank you, Werner.

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.