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.

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?

Under GNU/Linux you can compare the strace output to see that there is a problem
even if it's quick because it is cached:

~> time strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 |wc -l
33383
strace gpg2 --no-auto-check-trustdb --trust-model pgp -k 2>&1 1.04s user 0.45s
system 104% cpu 1.433 total
wc -l 0.02s user 0.16s system 12% cpu 1.433 total

~> time strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 |wc -l
558528
strace gpg2 --no-auto-check-trustdb --trust-model tofu -k 2>&1 9.60s user 8.47s
system 106% cpu 17.022 total
wc -l 0.60s user 2.34s system 17% cpu 17.022 total

This is with my normal pubring that contains 790 public keys.

Now that gnupg v2 is using gpg-agent for all of the hard work,

It isn't. The agent merely decrypts the session key. gpg then decrypts the
actual data with the symmetric cipher.

and gpg-agent either gets locked

It isn't.

or isn't parallelized,

It is.

this does not work any more.

Can you please be more specific?

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.

Okay, we can then add the code to dirmngr.

The README describes that this is a one time migration and that is a Good Thing.
Anything else means the addition of additional code and surprises for 2.1 using
applications by keys suddenly appearing.

The migration code is there to help the majority of users and not to help
speical use cases.

Those who really want to create new keys with 1.4 can use the standard way of
exporting and importing secret keys.

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.

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.

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?

A year later on a new computer I had to troubleshoot this problem again, and
found my own bug report. So I am including the patch this time. Please consider
including the proposed change (or some other fix) into mainstream.

D320: 895_0001-Let-other-processes-use-OpenPGP-card-over-pcscd.patch

thanks, that seems to have resolved the problem in my tests.

I wish to work more with the bug tracker.

I run in the same issue as PRab whenever I suspend or hibernate my machine. The
machine as Broadcom BCM5880 with a smart-card reader, so I cannot unplug it.
Quickest workaround is to kill/restart scdaemon.

Is there/could there be a command that could be sent to scdaemon via the agent
so a reset could be triggered? It should be easy enough to line that up as part
of the resume scripts.

It seems to be solved now but see the comment in
2f7d4c3 agent: Move inotify code to common and improve it.

I'm attaching the lsof and strace transcript in text form so it can be read
without linebreaks

John is using 2.1.14, but this bug was fixed in 2.1.15.

So you installed GnuPG from source. If you didn't specify a --prefix during the
configure phase, it will be installed to /usr/local. Check that /usr/local/bin
is in PATH. Check what 'type -a gpg' says.

I'm sorry, but this is not a GnuPG problem, and helping you with installing
software on Linux is out of scope for us.

This is apparently just re-reported on gnupg-users:

https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056892.html

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

thank you for taking time to formulate this correctly, dkg. :)

regarding symlinks, i got the idea from reading the caff source code. after a
quick chat with the caff author, i was pointed towards that discussion:

https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029301.html

... where Werner Koch suggests symlinks as a solution.

in my opinion, the solution is sub-optimal: symlinks increases the attack
surface and adds un-necessary overhead. i would prefer an a commandline flag
(e.g. --agent-socket) or environment variable to be able to select relevant
agents...

the same applies to dirmngr, apparently - caff creates symlinks for both the
agent and dirmngr. i am not sure why, but i suspect I may have to do the same,
since I have seen stray dirmngr processes lying around in my session. a
different issue, maybe, but related, implementation-wise.

Hello,

I'm using RedHat Linux which already had a version of GnuPG installed. (2.0.14)
I'm not sure what process was used to install it. I downloaded the latest
tar-ball of GnuPG Stable 2.0.30 and installed it as per the process described in
the "HOW-TO". But when I check for the version using gpg --version, it gives me
the older version 2.0.14 instead of 2.0.30. Also , there were no errors while I
installed 2.0.30 either in compilation or installation. I'm not sure why the
--version command is still displaying the old version then.

We now have a macOS box, and are building our software on it using Jenkins.

On that box, I also see the gpgtar test failing in about 14% of all runs. There
is something to be learned here.

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'm going to close this due to inactivity. Feel free to reopen this with more
information.

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?

I'm going to close this due to inactivity. Feel free to reopen it with more
information.

Agreed, but i ran into this while looking at python-gnupg, which is now failing
when using GnuPG 2.1. so they're facing breakage either way. It would be
better to have all current releases doing the expected behavior than to imagine
that we can bump this variance in behavior along indefinitely.

I hesitate to fix this for 1.4 - if people are using this they are probably
working around it and a fix would break that.

There is a plethoria of reasons why a user ID is not valid. The most
common one has been a mssing self-signature, thus this note. Newer
releases of older branches actually know about new algorithms and may
print some info about this; but they are not able to handle them.

Here is what the current 1.4 prints for an ed25519/cv25519 key:

$ gpg1 --no-options -v --import <ed25519-cv25519-sample-1.asc
gpg: armor header: Version: GnuPG v2
gpg: can't handle public key algorithm 22
gpg: can't handle public key algorithm 18
gpg: pub 0?/2A020D0A 2016-06-22 patrice.lumumba@example.net
gpg: key 2A020D0A: unsupported public key algorithm on user ID
"patrice.lumumba@example.net"
gpg: key 2A020D0A: unsupported public key algorithm
gpg: key 2A020D0A: skipped user ID "patrice.lumumba@example.net"
gpg: key 2A020D0A: skipped subkey
gpg: key 2A020D0A: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg: w/o user IDs: 1

The problem is pretty obvious. You need to use -v (--verbose) to see
all these messages.