@Patrick I saw this attack discussed and was wondering if it applied to our package:
My python-gnupg module isn’t vulnerable to SigSpoof, for several reasons:
–no-options is passed by default. So if you’ve got something stupid in your gpg.conf file, you’ll still be fine while using my Python module.
Same for gpg-bash-lib. Always using --no-options and separate config directory.
–verbose is not passed. This means that my library doesn’t have to wade throught a mixture of strange stderr and GnuPG status-fd messages on the same file descriptor. You could pass --verbose to it manually, as it is in the list of allowable, whitelisted options, but the exploit still won’t work, which brings us to our next point:
Same for gpg-bash-lib. Not using --verbose.
All inputs to, and outputs from, the gnupg binary are sanitised and then forced to conform to whitelists. This means that, even if you did pass --verbose manually, the filename trick won’t work because there’s no way to safely sanitise a filename, because filenames may be arbitrary bytes.
Or, the --status-file FILE option could be used to direct the status lines to a temporary file.
This has always been the case.
If you are parsing GnuPG status output and you use a dedicated file descriptor with --status-fd you are safe. A dedicated file descriptor is one that is not shared with the log output. The log output defaults to stderr (2) but may be a different if the option --logger-fd is used.
They don’t mention --status-file explicitly but it is as good s "dedicated file descriptor with --status-fd ", i.e. log and status fd messages are separate.
It’s fixed in Debian.
So either way we’re good.