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.

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.

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 - 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.

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?

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?

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".

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).