i've now seen several instances where people have used:
gpg --verbose file.gpg
or:
gpg --verbose --with-colons file.gpg
under the assumption that it will list the OpenPGP keys in file.gpg.
For example, scan_keys() in python-gnupg does this:
However, if this kind of code encounters encrypted data or anything else, it
tries to decrypt it, sometimes creating an output file.
For example, if file.gpg in the above example is actually encrypted text, gpg
will create a file named "file" (with the current umask) that contains the
cleartext, if decryption is possible.
This is a data leak risk, which is why this is a bug.
but there's currently no way to tell gpg to just act in a filtering mode that
parses packets and emits line-by-line descriptions of them, so people will
persist in doing this.
So i guess i'm proposing a new --scan-packets command, which does not try to
decrypt, implies --with-colons, and takes either stdin or fname and produces a
machine-readable list.