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.

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

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,

Looks like there is a need to prod upstream again.

While EROFS won't guarentee other systems don't have the filesystem
mounted read-write, nor even that the same host doesn't have it mounted
read-write elsewhere it does greatly reduce the likelyhood of this being
an issue.

GPG must be able to deal with corrupt data anyway, if it cannot then this
is a security hole anyway and needs to be fixed.

Rather more fundamentally, being unable to lock the DB shouldn't cause
an operation like --list-keys to *fail*.  Outputting warnings and
returning a warning status code (alas, the man page says all non-zero
statuses are errors) would be okay, but completely failing to complete
the operation is unacceptable.

Worst case, bugs will need to be filed against APT and other packages
that expect GnuPG to behave in a conventional manner.