Thanks for your patch. Due to the planned gpgme releases I also added the
override feature and hacked tests/run-decrypt to test these two features.

I submitted these patches on the gnupg-devel mailing list in November 2016:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032011.html

These are working for me to keep gpg-agent idle on platforms that support
inotify when the user doesn't use scdaemon, and we're now shipping with them
applied in debian unstable.

D276: 907_0140-agent-Avoid-scheduled-checks-on-socket-when-inotify-.patch

D277: 906_0139-agent-Avoid-tight-timer-tick-when-possible.patch

D278: 905_0138-agent-Allow-threads-to-interrupt-main-select-loop-wi.patch

D279: 904_0137-agent-Create-framework-of-scheduled-timers.patch

Regarding the original issue discussed here:
What about an option in gpg/gpgme to limit all operations to keys contained in a
"whitelist" file?

(accept --recipient keys only if they are contained in the file, --list-keys
shows only keys listed in this file, --refresh-keys only refreshes keys listed
here, etc.)

Reported the problem mentioned here in T2835
("keyid-format none" ignored for --verify and other commands)

(repost, I just noticed that neal is not in the nosy list. I'll unlink the old
entry afterwards)

neal: Interesting idea, this (or for a non-gui version: a signed list of
fingerprints available from a central source and retrieving those keys) would
solve 2 (iterating over all keys) and 3 (regularly update).

For the non-gui variant I wondered about how to use --verify and check that the
file was signed by the authority key (--verify only prints the keyid,
"--keyid-format none" does not allow --verify to print fingerprints in 2.1.15,
I'll file a separate issue). I was a bit disappointed when I saw that gpg sync
just calls the command line with --keyid-format 0xlong and does screen scraping
to verify the verification.

But still, how to solve 1 with gpg itself? Of course I could "manually" verify
in the application that only the intended keys have been used, but as shown with
gpg sync's code above: This is not always easily possible.

I fully support dkg on this. If our downstream is complaining that there is a
problem, then we need to take it seriously. I respect Werner's opinion, but
disagree specifically with the idea that this is only a problem for special
users. I think it will happen to many normal users too.

@thomas: You may want to look at gpg sync, which I think makes at least some of
what you want to do easier.
https://firstlook.org/code/2016/10/12/introducing-gpg-sync-an-open-source-tool-for-organizations-that-encrypt-email/

Sign the keys and set the signing key to fully trusted.

does not solve 1.:

Encrypt a file to any of those key (but no others!),

(because people may trust other keys)

and it does not solve 2. without keeping a separate list of keys/fingerprints:

Iterate over all keys

additionally _all_ users have to regularly update _all_ these keys, otherwise
things like expired subkeys will lead to failing encryption. (This is no theory:
We've been there and don't want to have this again)

gpgol 2.0 won't change the messages on the server anymore there might be code
paths leading to that under error conditions but i'm not aware of any. And the
fallback is first to try to revert them.

Sign the keys and set the signing key to fully trusted.

Please tell me how I should model my workflows in this case:

• There is a a centrally managed set of public keys (currently in a keyring

file, but I'm open to suggestions)

• Different users should be able to use this set of keys (and no others) for

certain tasks:

1. Encrypt a file to any of those key (but no others!), but also decrypt the

file with their secret key (which is not centrally managed)

2. Iterate over all keys and do something with them (here: publish them in the

WKD after having made changes to the set of keys)

For backward compatibily reasons.

We try to deprecate the use of the --keyring option because that is too
troublesome for many reasons. We can't remove that option from gpg proper for
compatibilty reasons. But not adding a new feature to GPGME won't raise any
compatibility problem and thus we can fortunately reject this request.

Ah, I understand. I currently have two keyrings (the default keyrings and
debian-keyring.gpg) in my user account. So I will export the keys from
debian-keyring.gpg and import them into my regular keyring.

But this is a different topic from the one described here:
This issue is about allowing gpgme to use exactly one different keyring (not an
additional keyring) that is different from the default keyring or other keyrings
configured in the user's gpg.conf.

So it is just about allowing in gpgme what is already possible via the command
line. Or maybe you would prefer to allow passing command line options to gpg via
gpgme to avoid the wrapper script mentioned below?

I have explained this several times over the last decade. The primary reason is
that it is not possible to keep a consistent vewi on the localally availabale
keys when a user is allowed to remove and add storage at will without gpg having
any control over it. You may end up with duplicated keys and gpg will only
update one of them. The next time the keyrings are "mounted" in a different
order and key is used for update. This leads to all kinds of problems. This is
not a distributed database with a 3 -phase commit system.

I have proposed a solution gor 2.3 based a on central key managing daemon, which
then has the chance to track changes. Interesting fact is that aheinecke has
strongly opposed that idea.

Besides the WKD scenario Andre describes, there are already many existing uses
of a separate keyring where having other keyrings configured via
~/.gnupg/gpg.conf already conflicts with the intended use, except when using
--no-options:

1. /etc/apt/trusted.gpg
2. /usr/share/keyrings/debian-keyring.gpg
3. our company's keyring with acceptable keys for encryption of certain

sensitive information

Basically everywhere where multiple users use a single keyring, often with
"--trust-model always", where you do not want additionally configured keyrings
to disturb the result and give a false sense of security.

Please explain why this a Bad Thing[tm] and what the correct workflow would be.

The keyring is a property of GnuPG and you should not mess around with it. Use
--export and --import to add keys. Extending the bad behaviour of using
multiple keyrings would be Bad Thing.

How many people has this happened to? how many people haven't known to find you
on freenode and ask about it? how many people have just given up on gpg
instead, or just decided "2.1 is broken"?

Shouldn't we fix this for them?

FWIW, I idle on gnupg on freenode and I've helped a bunch of people over the
past two years with exactly this problem. It is not that they want to use gpg
and gpg2, but that at some point they (or some tool) ran gpg2 while they
continued to use gpg1. They then became very surprised when they used gpg2 and
it only had a subset of their keys. My advice for these users is always the
same: remove the migration file and just rerun gpg2. As far as I can tell, this
has fixed the problem in all cases.

I am working on that...

Fixed in ab89164be02012f1bf159c971853b8610e966301.

I also don't quite understand why we restrict this to user ids resembling mail
addresses, so I'll keep issue this open for discussion.

I like this work, thanks for it! I wonder whether it would also be useful for
full-match userID, not only for a raw e-mail address?

For example, if i query for '=Peter Palfrader' or '=ssh://host.example', it
ought to give me the key with the highest-validity binding for the requested
user ID.

That's awesome aheinecke! Honestly wasn't sure if this issue would ever get much
attention. Thanks for the effort in making Gpg4win a more secure product!

GpgOL is built with DEP and and ASLR now. Need to enable this for GpgEX and some
other parts of Gpg4win, too. So not yet fully resolved but I keep it in mind.

Figuring out required iteration counts is not necessary as the only operation
performed while GNUPGHOME is still unwritable is decryption.

--passphrase-fd 0 with --pinentry-mode loopback does indeed work without the
agent but requires a potentially unsafe password entry to be programmed around
the call which is also probably not the best option. --pinentry-mode ask
requires the agent again.

Try this:

echo hello | \
gpg -ac --pinentry-mode loopback --passphrase abc --s2k-count 17659904

By giving the S1K count (iterations) there is no need to ask gpg-agent. I have
used --passphrase for easier testing; --passphrase-fd should work as well.

To get the suggested iteration count for your box, use
gpg-connect-agent 'getinfo s2k_count' /bye

You simply can't run gpg on a read-only home directory. That is not just a
matter of socket files but of lock files and tracking a lot of other things.

For symmetric-only encryption the agent is used to calibrate the KDF
interations, it might be possible to a chnage gpg to take the iteration count
from the command line.

gpgconf --create-socketdir made no difference, the agent still has to be started
manually, and honestly, even the gpgconf step is one step more than I think
absolutely necessary to make it work.

Try running "gpgconf --create-socketdir" after step 3.

If gpg does not create this directory when it is trying to start an agent, but
gpg-agent does, then I guess that is a bug. But to be honest, this is easily
one of my least favorite features of GnuPG, and I have no opinion whatsoever
regarding its design.

To be absolutely precise:

1. Log in as a test user with an existing ~/.gnupg and some (empty) keyrings
2. Lock write access to ~/.gnupg with 'chmod 0500 ~/.gnupg'
3. Create /run/user/<id> as root, chown and chmod it to be owned by that user

with write permission.

4. Run 'gpg -q -d <symmetrically encrypted file>' as that user (which is

precisely what needs to work at this point. - It does _not_ work

5. Run 'gpg-agent --daemon' as that user.
6. Retry step 4. - Now it _does_ work.

So: gpg-agent can figure out to put its socket into /run/user/$(id -u) and
subsequent calls to gpg will find the agent socket there. But calling gpg
without starting the agent manually does not perform this magic.

I've tried

What did you try?

• unfortunately the gpg-binary doesn't try that on its own

What is it that which of the gpg binaries does not try?

I've tried - unfortunately the gpg-binary doesn't try that on its own, so i
still have to extend the pre-fs-mount-magic happening during boot, but at least
it spares me thinking about how to tell the agent where to create its socket.
Modifying configs wouldn't be a good idea here, IMHO, as usually user-created
configs are there for a reason.

This is resolved. we have WITH_TOFU_INFO now.

That doesn't work then of course, unless the configuration is copied over to the
new GNUPGHOME.

Another option would be to create directories or links to directories
/run/user/0 or /var/run/user/0. If those exist, gnupg will create the sockets
there.

What about cases where a local (/root/.gnupg) config is required to decrypt the
files?
I honestly don't know about SmartCards and stuff, but doesn't setting GNUPGHOME
also hide other GnuPG configuration?

Set the environment variable GNUPGHOME to the desired location.

I'm working on a solution for this problem, but since gpg-agent does now ignore
--no-use-standard-socket, how do I tell the agent daemon on commandline where to
create its socket?

Using the original file name does not make much sense because it is common to
delete that file. Maybe the creation/ctore date and key algorithm can be used
as a default.

With the extended private key format we could add a comment field for ssh.

The idea is to change the algorithm in the case that a full mail address is
given - and only a mail address. For both -r and --locate-key. g10/getkey.c
has get_pubkey_byname which implements --locate-key and already checks for a
mail address (IS_MBOX). This function needs to be changed to figure out all
matching keys an return the best one. -r should make use of that function also
if it is a mailbox.

Thank you!

You need to find a writable place for GnuPG 2.1 to bind its sockets to. If you
do, you can also use the smart card daemon. Using a smart card to store could
increase the security of your setup considerably. Also, I consider this an
integration issue, so talking to your distribution makes more sense imho.

Otoh, if GnuPG 1.4 fits your needs, you could continue to use that. It will be
maintained forever for compatibility with older PGP versions.

Fixed in 165f0ecebc8a68bff30d5255962a3b44d8113940. Will be deployed to the
webserver soonish.

I figured out that the custom_id property also works without an toc.

Ah, no. I don't _want_ to use pinentry, it's just what happens with GnuPG-2.0,
given that pinentry is installed and GnuPG is able to find it at that point. I
can very well live with the basic (blind) prompt from GnuPG-1.x (I think
pinentry's habit of displaying * characters for each passphrase character typed
is also _not_ an improvement). So, I'm using pinentry, because I don't have the
choice not to do so.

And, honestly, I find changing an application's behaviour such way it doesn't
work anymore like it did for years without even an option to get at least part
of the old behaviour back - I'm talking _only_ symmetric _de_cryption here, for
everything else I'm fine with the agent - is not really an "improvement".

I understand there has been considerable time invested in discussing and
evaluating options here, but this decision renders GnuPG worthless for a step of
security I've had and now I need to look up alternatives, with the tradeoff of
them being probably less thoroughly scrutinized, esp. in their implementation of
the cryptography part. Also not an "improvement".

If you want to use the pinentry mechanism you need the agent in GnuPG 2.1.
There is no way around that. You need to find a writable place for GnuPG to
bind its sockets to.

Note that this is not an "issue", it is an improvement. GnuPG has been split up
into several components, a process called compartmentalization. The agent is no
longer optional.

pinentry is used to enter the passphrase, during bootup pinentry-curses is in
use, after the GUI has started, a graphical version is used.

The major problem is that the gpg-agent tries to write to the root filesystem
when gpg is called to supply the key-material to LUKS. This fails with modern
GnuPG, stable GnuPG doesn't have this issue.

I am using Gentoo Linux AMD64 stable as operating system which stabilised
gnupg-2.1.15 a few days ago for general use.
In my LUKS setup GnuPG is used to symmetrically encrypt/decrypt a file
consisting the random data which in turn is the key for the LUKS partition in
question. So GnuPG does the part of requiring a secret for a required file to
get to the data in question, like a PIN to a credit card, both are worthless
without the other.

The process is roughly this:
The kernel starts and init (no systemd) proceeds to one step prior to checking
all to-be-mounted filesystems.
Now one or more partitions are found to be LUKS-encrypted with gpg-encrypted
keyfiles.
For each partition with such a gpg-encrypted keyfile gpg is called to decrypt
the keyfile and pass it to cryptsetup.
After all partitions have either been decrypted, the regular filesystem checks
are performed and filesystems are mounted as specified by /etc/fstab.

The crucial part is that up to the last step in the process the root filesystem
is still read-only and the agent's default location for the socket
(/root/.gnupg) doesn't allow creation of the socket.

Since my disk encryption relies on being able to enter the keyfile's passphrase
prior to being able to write to the root filesystem, I'm currently stuck with
GnuPG-2.0, which doesn't need its agent (contrary to its man-page, btw).

The bug tracker has a spam problem, so new users need to be approved. I did that.

Note that the gpg-agent *does* relay comments if the private key has one. If
the key resides on a smart card, the cards serial number is used. It uses
'(none)' to indicate that no comment has been set.

I agree that '(none)' while technically correct is not very helpful, I'll have a
look if I can come up with a more helpful fallback comment.

How do you supply the passphrase? Modern GnuPG uses the gpg-agent to ask for
passphrases.

Also note that 'S.gpg-agent' is not a file, but a socket. Nothing is written
there, it is merely used for interprocess communication. Are you sure that
there is no writable location that can be used to create the sockets?

Please tell us more about your setup. What operating system are you using, how
is GnuPG used in the LUKS setup?

I wish to work more with the bug tracker.

It seems you missed the creative commons links (on all pages).

Also some more:

• Download page contains links to gpg4win, gpgotools (mac) and rpmfind which

are all available over https.

• documentation page contains another http twitter link.

(Hint: The moartls browser addon for chrome and firefox is extremely useful to
do this)

Fixed in 1e6073ff.

Please clarify the plan a bit. Shall we use the algorithm currently used by
--recipient, the one used by --locate-key, or implement a new one?

another item for consistency is gpg-agent's different behavior between
--enable-ssh-socket and --extra-socket (and the undocumented --browser-socket,
for that matter, but since it's not documented maybe it's fine to just change
that one).

I have created two sample commits, pushed to

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/justus/issue2700

The second one does indeed change translated strings. If I don't update
translated strings, then the messages will still refer to the old version of the
options, which will still work but won't show up in '--help'. Is there a
problem with updating the strings when I also update the .po files?

FWIW, the use of file suffixes to determine the content of a file is pretty
fragile. On Unix this is not used due to the availibility of the file command.

The recent gpgme version has enhanced detection capabilities (even better than
file) for OpenPGP and S/MIME file types. If there is a way to hook into the
Explorer to determine the file type and set an icon we might be able to add this
to GpgOL