Page MenuHome GnuPG

"gpg --list-keys" fails when $GNUPGHOME is not writable
Closed, ResolvedPublic

Description

some read-only operations appear to fail for gpg when the gnupg homedir is not
writable.

For example:

export GNUPGHOME=$(mktemp -d)
gpg --list-keys # initialize
gpg --recv 0x249B39D24F25E3B6
gpg --list-keys
chmod u-w $GNUPGHOME $GNUPGHOME/*
gpg --list-keys

This can be worked around with --lock-never, but it seems clumsy to have to do
this when the command is read-only in the first place.

This came up at https://bugs.debian.org/771976, where a user had a debian system
with a read-only /etc, and tried to do "apt-key list", which is something that
should really work.

Details

Event Timeline

That link to the debian bts is a little wacky, somehow roundup is attaching the
comma to the end of it. it should be: https://bugs.debian.org/771976

oh, and this appears to be the case for 1.4.x, 2.0.x, and 2.1.x

werner set External Link to https://bugs.debian.org/771976.Dec 8 2014, 12:55 PM

Yes, this is the case for a very long time. I also won't call this a
bug.

There is no way to protect an update by a lock without having write
permissions to the same directory. Well, one could setup a second
file system hierarchy below /var/run and use that for the locking
file. However, this assume that all process accessing the files are
on the local machine. One of the reasons why we can't use a locking
API are remotely mounted file systems. See the comments in
common/dotlock.c .

And yes, we need lock the file even if the local process as no write
permissions to the directory - other processes may have and the
reading process may thus read garbage.

By using --lock-never you assert that there is no other processing
writing to the gpg data files. Thus using this is the Right Thing.

werner claimed this task.