Reputation: 72717
Suppose you want to distribute a file foo
along with its detached signature foo.sig
and your public key public.key
.
Suppose further you want to make signature verification as easy as possible, i.e. in the minimum number of steps: just one command. Ideally something like
gpg2 [magic option combo here involving foo, foo.sig, public.key]
I've read the gpg2 man page up and down a few times, but it seems the receiver needs to first import the public key to his key ring.
Is there a way to avoid importing the public key and specify it explicitly? I would like to avoid the receiver being spammed with a newly created $HOME/.gnupg
directory and its contents.
Or am I trying something stupid from a security point of view?
Upvotes: 2
Views: 3132
Reputation: 38722
Use gpgv
instead, which you can pass a keyring file (a single exported key also accounts as a keyring). If no slash is contained in the keyring path, gpgv
will search in the GnuPG home directory, so either pass an absolute path or at least include ./
to denote the current working directory if no slash would be involved otherwise:
# Create and sign file
echo foo >foo.txt
gpg --local-user a4ff2279 --sign foo.txt
# Create "keyring" / export key
gpg --export a4ff2279 >a4ff2279.gpg
# Verify using gpgv
gpgv --keyring ./a4ff2279.gpg foo.txt.gpg
Finally, the only difference between importing and not importing the key is whether how the key is verified. There is no verification through the web of trust, certifications and local trust if you don't import the key, if the only way to verify the key is "downloading it from a trusted source", not importing it is totally fine. If you just fetch file, signature and key from an untrusted web server without encrypted connection and certificate, the OpenPGP signature is degraded to a simple checksum to realize transmission errors, not attacks providing faked files, signatures and keys.
Upvotes: 2