Call to signer failed: signing error: openpgp: s2k GNU dummy key: dummy key found

[jdoss]

What happened?

We are in the process of creating Apt and RPM repos and I cannot sign Debs and RPMs with a GPG Subkey that is meant for signing only. This seems somewhat related to #276 but it was closed as fixed when nfpm moved to gopenpgp. I see with PR #315 tests were added for signing with sub keys.

error=nfpm failed for smallstep-desktop-0.8.1~next-1.x86_64.rpm: failed to create signatures: call to signer failed: signing error: openpgp: s2k GNU dummy key: dummy key found

How can we reproduce this?

We followed this guide https://github.com/drduh/YubiKey-Guide?tab=readme-ov-file#create-certify-key for creating our GPG Certify key and Signing Subkey.

If I use the Certify key I can sign packages just fine.

nfpm version

I am using nfpm via Goreleaser Pro

$ goreleaser --version
  ____       ____      _                            ____
 / ___| ___ |  _ \ ___| | ___  __ _ ___  ___ _ __  |  _ \ _ __ ___
| |  _ / _ \| |_) / _ \ |/ _ \/ _` / __|/ _ \ '__| | |_) | '__/ _ \
| |_| | (_) |  _ <  __/ |  __/ (_| \__ \  __/ |    |  __/| | | (_) |
 \____|\___/|_| \_\___|_|\___|\__,_|___/\___|_|    |_|   |_|  \___/
goreleaser-pro: Deliver Go Binaries as fast and easily as possible
https://goreleaser.com/pro

GitVersion:    1.26.2-pro
GitCommit:     164bbeb25b631568673ed9a6b7f836d922555d19
GitTreeState:  clean
BuildDate:     2024-05-23T12:20:19Z
BuiltBy:       goreleaser
GoVersion:     go1.22.3
Compiler:      gc
ModuleSum:     unknown
Platform:      linux/amd64

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

[caarlos0]

judging by the error, it seems the key is invalid...

• https://github.com/ProtonMail/go-crypto/blob/dc5f72bd68dc8efd85ac7f34bae0d580646161c2/openpgp/errors/errors.go#L129-L136

we do have tests for signing with subkeys... and we haven't changed anything related to crypt lately 🤔

[jdoss]

Yeah, I am not sure what is going on either. I can verify that the key is not invalid.

$ gpg -K
-----------------------------------------
sec   ed25519/0x889B19391F774443 2022-11-11 [SC]
      Key fingerprint = 78E8 2890 D40D 5D39 7D19  399F 889B 1939 1F77 4443
uid                   [ultimate] Smallstep Ops <[email protected]>
ssb   rsa4096/0x1E43859CB855223C 2022-11-11 [S]
$ gpg --clearsign test.txt
$ cat test.txt.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This is a test
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEExj6yRTZfoHtxBoBJHkOFnLhVIjwFAmZ5iOoACgkQHkOFnLhV
IjymCw//WnQHSMijFoVZx3CmpOt+RDn8180Pt0Qa3mWH9DAnV0zPaQJafdQ+Idhk
H736vXsz1O/qmDe3+GqT3RDIAWpBYvLKBjTnq8TNOutBKpyrL1LVCrbvw+Z6F7Kn
dNFA0Ht5HuPJkIW8cq650lNxnJ/9d5DF6d+EMxKr5bcf+J2TlqbM+bmeapszVjmK
+TUR1PpdzeS57AzYFsukYII7QnZRLnhrfy/+pqBhfyfyw/9aT+OBxtZq0ux5Bs59
IkDUlutqilSrw50A63YXv2h30kBNl3EmOHOcyhBfs/PpsKibFltHeCQJhcrbjDeu
ZYrgc1CRPZtcLQOWB97+0tn+PmDvxiFldVBpWq9zXsftZFdFbDq4GbAyBGcSeRMr
oIuZUq5bBf1Zx7hBZF1a8UXP8+70e7HqDuCDPi+If23X3RqO5ofKSmTqzHs0rRhu
KQhIVvcLMQYsjzJSKpA9/qBPntk/kUt0e3Axes7BE2qOai8QpVEY+xGXlRex37P6
xd69C0nKN51y+n2f+hoDw6IFHTuExdG7UZ5eX41qPFFQMnQMaAA1z/RutaQ6qRxD
EZaAa0l/HuaATiW1/EfHQCfV89eigZjkkCPuaTDIBRpAb/SneOWFMxbZUq3UcFOL
tol+eYdxSJ3s7xJygOduo0j84fKSH0qdq32HoB0jreR2xSPa4iM=
=jTFM
-----END PGP SIGNATURE-----
$ gpg --verify test.txt.asc
gpg: Signature made Mon 24 Jun 2024 09:55:38 AM CDT
gpg:                using RSA key C63EB245365FA07B710680491E43859CB855223C
gpg: Good signature from "Smallstep Ops <[email protected]>" [ultimate]
Primary key fingerprint: 78E8 2890 D40D 5D39 7D19  399F 889B 1939 1F77 4443
     Subkey fingerprint: C63E B245 365F A07B 7106  8049 1E43 859C B855 223C

[caarlos0]

Looks like its considering any s2k key as a dummy key: https://github.com/ProtonMail/go-crypto/blob/140b3d6f14775c42f6544e1cc34cf77e3da56baa/openpgp/s2k/s2k.go#L304

From GPG docs:

GNU extensions to the S2K algorithm
===================================
S2K mode 101 is used to identify these extensions.
After the hash algorithm the 3 bytes "GNU" are used to make
clear that these are extensions for GNU, the next bytes gives the
GNU protection mode - 1000.  Defined modes are:
   1001 - do not store the secret part at all
   1002 - a stub to access smartcards (not used in 1.2.x)

So, maybe, it just doesn't support smartcards?

Found only one issue that seemed somewhat relevant: ProtonMail/go-crypto#199

---

I do have an yubikey somewhere, will see if I can repro this using the same tutorial and everything, probably someday this week or weekend

[jdoss]

That is really weird. These keys are not in a smart card at all. I just use the tutorial to create the keys that live on disk for now. Maybe that extension was somehow enabled by the gpg.conf provided by the tutorial.

[caarlos0]

yeah, really weird indeed

[caarlos0]

that said, gpg is generally weird to deal with

[jdoss]

Yeah for sure. I wish we could use cosign for RPMs and Debs but here we are.