Control: tags 771976 + confirmed upstream Control: forwarded 771976 https://bugs.g10code.com/gnupg/issue1781 Control: clone 771976 -2 Control: reassign -2 gnupg2 Control: found 771976 1.4.18-4 Control: found -2 2.1.0-1 Control: found -2 2.0.19-2+deb7u2
On 12/03/2014 07:58 PM, Elliott Mitchell wrote: > Package: gnupg > Version: 1.4.12-7+deb7u6 > > Hopefully the subject says it all, but for more detail: > > I found this when running the command `apt-key list` on a machine where > the root filesystem is normally mounted read-only. This results in > running gpg with "--trustdb-name", "/etc/apt//trustdb.gpg", > "--list-keys". gpg in turn attempts to create > "/etc/apt//trustdb.gpg.lock" in order to lock the trustdb, which fails. > > Seeing how --list-keys is an operation which shouldn't require writing > to anything, having it fail in this situation is bad. I can understand > wanting to lock the trustdb to ensure no one else writes to it, but if > open() returns EROFS, that nicely satisfies the reqirement. thanks for reporting this, Elliott! I can confirm the misbehavior you're describing on several other versions of gnupg (including in the 2.0.x and 2.1.x series). This is pretty clearly an upstream problem, and not an issue with the debian packaging itself. In practice, it's possible that the trustdb does need to be modified, even when doing a --list-keys. for example, when doing an automatic trustdb update (e.g. because a signature or a certificate expired) the trustdb information needs to be changed. I note that it looks like you can pass a --lock-never argument to gpg and it appears to complete the --list-keys, while warning "gpg: NOTE: trustdb not writable" However, I agree that GnuPG should handle this situation better than it currently does, and i've reported the problem upstream: https://bugs.g10code.com/gnupg/issue1781 Regards, --dkg
signature.asc
Description: OpenPGP digital signature
