Fixed for gpg as of 6b16b02109f4bb5b934e456667ff4c0ba7bc85fd.

--quick-keygen fixed in dd3dde07a9a46130ac01d849f8edf0566e44f11f.

The default expiration interval has been discussed on the mailing list. There
was a rough consensus on two years, which has been challenged by Neal who thinks
it is too short given the current state of the tools, but the ensuing discussion
did not revolve around the time span, so I'm keeping my two years for now. In
any case, it is easy to adjust.

I decided to not change the --full-key-gen, because a) the user asked for it, b)
changing that requires breaking up a large chunk of translated text, and I do
not want to do that right now (a release is imminent).

Partially addressed in d568a1561642ed9b7b7b6282b86c56786d10a956.

This would emit the "content-encryption key", as specified in
https://tools.ietf.org/html/rfc5652#section-6.3

Okay, I implemented --status-fd for gpg-wks-client.

Regarding a return code as text lines: Do you need this due to the double-fork
we use in gpgme?

I think so, at least I did not find a way to return an exit code from
gpgme_op_spawn.

If we provide this we should resort to the GnuPG standard
which is to required --status-fd N to print
[GNUPG:] ERROR ....
okay?

Yes. In that case i could use op_spawn with status-fd 2 and would get the error
I think.

Okay, try "gpg-wks-cleint --check ADDR" So see details use -v.

Regarding a return code as text lines: Do you need this due to the double-fork
we use in gpgme? If we provide this we should resort to the GnuPG standard which is
to required --status-fd N to print
[GNUPG:] ERROR ....
okay?

Would you mind to write to gnupg-devel and ask for comments on your proposal?
In particular on how long the default expiration time shall be. 12, 18, or 24
months?

Thanks!

--quick-set-expire now available.

I'll take the --quick-set-expire command. -wk

That is becuase we consider a mail address to be a unique indentifier and thus
and algorithm to figure out the best matching makes sense. Other kinds of user
IDS not not need to be unique and should at best return an ambigious key error.
Well, expired keys and such should be sorted out, though.

On Thu, Dec 1, 2016 at 10:33 AM, Werner Koch via BTS <gnupg@bugs.g10code.com

wrote:

Can you please switch to 2.1.16? We fixed the inotify based socket removal
detection (issue2756).

On Wed, Nov 30, 2016 at 10:28 AM, Werner Koch via BTS <
gnupg@bugs.g10code.com> wrote:

If you are on Linux you may simply remove the socket files and the daemons will
terminate.

On Tue, Nov 29, 2016 at 7:14 PM, Werner Koch via BTS <gnupg@bugs.g10code.com>
wrote:

[...]
thanks for the clarifications, I was 95% there but that rounds it up to the full
picture.

   GNUPGHOME=$(pwd) gpg-agent --daemon -v MYSCRIPT

This starts the agents and runs MYSCRIPT (/bin/sh is nice for testing). After
MYSCRIPT terminates the agent will be terminated within the next minute.

We more or less do that already, and I can confirm it does "terminate the next
minute".
Unfortunately "the next minute" isn't soon enough for my umount.

So I thought for now I might have to rely on an extra call of "gpgconf --kill
dirmngr" to be sure. But I have found that this doesn't end it for me - maybe
related to our custom GNUPGHOME?
It doesn't seem to stop as intended via gpgconf: (neither with nor without
GNUPGHOME):

$ ps axlf | egrep 'gpg|dirmngr'
1 0 18021 1 20 0 176840 6236 - Ssl ? 0:00 dirmngr --
daemon --homedir /tmp/tmped9zl1ip
$ gpgconf --kill dirmngr
$ ps axlf | egrep 'gpg|dirmngr'
1 0 18021 1 20 0 176840 6236 - Ssl ? 0:00 dirmngr --
daemon --homedir /tmp/tmped9zl1ip
$ GNUPGHOME="/tmp/tmped9zl1ip" gpgconf --kill dirmngr
$ ps axlf | egrep 'gpg|dirmngr'
1 0 18021 1 20 0 176840 6236 -
(Also did the same as root without effect, but avoid filling this report only
with logs)

The more obvious but less graceful "sudo killall dirmngr |:" cleans it up.

The reason why your bind mount fails are likely the socket files created there.

via lsof I only found the following to be related (the /dev bind umount is what
fails).
dirmngr 6771 root 1r CHR LG,0x80000 1,9 0t0
11 /tmp/tmptmucmfm0/target/dev/urandom
dirmngr 6771 root 2w CHR W,LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null
gpg-agent 6776 root 0r CHR LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null
gpg-agent 6776 root 1w CHR W,LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null
gpg-agent 6776 root 2w CHR W,LG 1,3 0t0
6 /tmp/tmptmucmfm0/target/dev/null

Not sure, but I'd not expect these are the sockets.
My assumption would be the open /dev/urandom - especially as I found that I only
need to get rid of dirmngr to proceed.

The solution to this are //run/user based sockets. If you create a directory
/run/user/UID gnupg will create a gnupg sub-directory and place the socket
files there.

gpg-conf --list-dirs

can be used to check that.

I created a log based on that check and lsof (the view from inside the chroot):
gpgconf --list-dirs
lsof +fg /dev
gpgconf --kill dirmngr
lsof +fg /dev
pkill gpg-agent
pkill dirmngr
lsof +fg /dev

I'll attach the full log with this post.
You can find there that the agent and dirmngr do not go away on the gpgconf --
kill.
The socket path OTOH looks ok with "agent-socket:/root/.gnupg/S.gpg-agent"

I added this as first command in chroot to give it a try at least:
$ mkdir -p /run/user/$(id -u)
It "worked" in the sense that the dirs changed e.g. from:
dirmngr-socket:/root/.gnupg/S.dirmngr
to
dirmngr-socket:/run/user/0/gnupg/S.dirmngr
But as I expected that did not change the behavior of blocking to umount the /dev

I really think it is not the sockets but e.g. the /dev/urandom it keeps open.

Is there any way to get the agent&dirmngr from "away next minute" to be "away
before exiting the calling command"?

BTW - I wondered if it would be enough if gpg-agent can stay and to only kill
dirmngr - but it seems I need both gone to let me umount.

The agent is not directly involved in keyserver lookups. Instead the dirmngr is
spawned and does this for you. In fact, all network access goes through dirmngr.
However the agent is a mandatory part of gnupg-2 - all private keys are
processed solely by the agent. Thus removing the agent is not an option.
In your case the agent is launched to check whether a private key is available
for an imported public key.

You can stop the agent or the dirmngr using "gpgconf --kill dirmngr"
("gpg-agent"). For your use case a better solution will be to run your script
under the control of the agent (ie. explicily starting the agent):

  GNUPGHOME=$(pwd) gpg-agent --daemon -v MYSCRIPT

This starts the agents and runs MYSCRIPT (/bin/sh is nice for testing). After
MYSCRIPT terminates the agent will be terminated within the next minute.

The reason why your bind mount fails are likely the socket files created there.
I had the same problem with my g13 based disk encryption. The solution to this
are //run/user based sockets. If you create a directory /run/user/UID gnupg
will create a gnupg sub-directory and place the socket files there.

gpg-conf --list-dirs

can be used to check that.

Anything I can do to help?

The major trouble we have here is that dirmngr is not abale to detect network
failures. This is due to ADNS which keeps on trying to send UDP packets for 30
sesonds desipte a ENETUNREACH. I tried with a patched ADNS versions and did
not anymore suffer from these problems.

However, when a keyserver is not answering in time, there is indeed a problem.
A problem we may be able so solve with queuing the requests after a short
timeout. gpg already tells dirmngr that it is prepared for such a "soft
failure" but we need to implement this in dirmngr.

The whole thing is not new (except for ADNS) and has been with us since the
introduction of --auto-key-locate and --auto-key-retrive. WHich is a LONG time ago.

Note that gpg-agent has been changed years ago to make up at the full second so
that all daemons with a need to wakeup are running at the same time.

Released with 1.8.0

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?