You are not logged in.
When I make packages, I like to sign separately with
gpg --detach-sign --no-armor *xz
I have been doing this for more than a year and there's normally no message when it's successful. For the past month though, I've been getting the following message even though it does create the .sig file:
gpg: selecting openpgp failed: No such device
That doesn't happen when I sign with `makepkg`, but that doesn't mean anything because `makepkg` redirects the output of `gpg --detach-sign` to `/dev/null`.
I have not changed anything in my `gpg.conf` file before this message started showing up. Searching on this forum and Google both just bring up similar messages related to various types of cards which doesn't seem to be related to the message I'm getting.
Last edited by colinkeenan (2017-06-14 18:41:32)
Offline
Does the following also produce the error?
find . -name '*xz' -print0 | xargs -0 -n 1 gpg --detach-sign
Whatever is the reason of changed behaviour, the original command you have posted was never producing signatures for the files. Passing multiple file names to --detach-sign makes it produce a signature of concatenated files, not each of the files separately.
There are also two other issues. You are using a glob pattern, which may produce arguments that are themselves gpg options. Not a huge problem if you’re in control of the filenames, but — even in such case — may produce unexpected results. If you’re not in the control of filenames this is a gaping security hole. Either use -- to separate files from options, use a more specific glob pattern that ensures no ambiguity (like: ./*xz), or use find. The other, minor issue is the --no-armor option: it is the default, so no need to specify it.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
I don't have to run your command to know it would still produce the error. I was using a glob to make a simple-minded alias `signpkg` that worked in most cases. In every case, there would actually be only 1 file matching *xz. The error has nothing to do with the glob. I also tried tab-expanding the glob to be sure. It only matched one file. I was (and still am) successfully creating signature files.
Offline
Does the problem occur in gnupg-2.20.2-2 or earlier?
If not, please report this issue to GnuPG bug tracker¹ or on GnuPG mailing lists, giving as much detail as possible. Seems like NIIBE Yutaka’s commits from 2017-05-17 (386a7bbb245dd3ab7c4156a554adbe75d82bdf49, a8dd96826f8484c0ae93c954035b95c2a75c80f2 — give them these IDs!) have introduced the problem.
On the Arch’s side it’s seems like the fix for #54271 is the culprit.
____
¹ Unfortunately it seems that for reporting the error you need to both create account on their website and download/run their software (the JavaScript scripts) to be able to notify them about the problem.
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Thanks. I verified the error does not occur on gnupg-2.20.2-2. I will figure out how to file a bug report tomorrow.
Offline
The latest update (gnupg 2.1.21-3) does not have this issue so I'm not going to file the bug report.
Offline