Page MenuHome GnuPG
Create Task
Maniphest T4608

gpgv --enable-special-filenames documentation appears to claim that it works for keyrings, but it does not
Open, LowPublic
Actions

Description

gpgv(1) says:

--enable-special-filenames
       This option enables a mode in which filenames of the form ‘-&n’,
       where  n is a non-negative decimal number, refer to the file de‐
       scriptor n and not to a file with that name.

but it fails to work for keyrings:

gpg --export $FPR | gpgv --enable-special-filenames --keyring '-&0' sample-file.asc

gives the following warning:

gpgv: keyblock resource '/home/dkg/.gnupg/-&0': No such file or directory

It appears that --keyring's weird special treatment of filenames without a / is taking precedence over the explicitly-specified --enable-special-filenames.

This makes it more cumbersome than it needs to be to build a curated keyring on the fly without touching the filesystem.

Details

Version
2.2.16

Event Timeline

dkg created this task.Jul 3 2019, 9:02 PM
• werner closed this task as Invalid.Jul 3 2019, 9:06 PM
• werner added a subscriber: • werner.

We need random access and the name of the file. Thus a file descriptor is not sufficient.

dkg reopened this task as Open.Jul 3 2019, 9:07 PM

In that case, you can treat this ticket as a bug in the documentation, which still needs to be resolved.

dkg renamed this task from gpgv --enable-special-filenames does not appear to work for keyrings passed as file descriptors to gpgv --enable-special-filenames documentation appears to claim that it works for keyrings, but it does not.Jul 3 2019, 9:17 PM
dkg added a comment.Jul 3 2019, 9:30 PM

out of curiosity, why does gpgv need the name of the file?

also, not all file descriptors come from a pipe the way my example above does. It's possible to provide a file descriptor that has random access (e.g. gpgv --keyring -&3 3< /path/to/validator.key test.asc)

Finally, aside from implementation constraints within gpgv, it really is concretely useful to be able to create a keyring on the fly without having to touch the filesystem. In the event of getting a file descriptor that is not random-access, couldn't gpgv just read the entire keyring into memory and operate on it from there?

• werner triaged this task as Low priority.Jul 4 2019, 8:41 AM

Because we use dot-locking in GnuPG and copy-update-write for keyrings. Granted: For gpgv this is not required but the code is identical to the gpg code and adding new code does not make much sense. After all gpgv is a stripped down version of gpg I once wrote for Debian. I see your use case but tehre are other ways to do this and thus anthing here has low priority.