Open jdoss opened 1 month ago
judging by the error, it seems the key is invalid...
we do have tests for signing with subkeys... and we haven't changed anything related to crypt lately 🤔
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 <techadmin@smallstep.com>
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 <techadmin@smallstep.com>" [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
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: https://github.com/ProtonMail/go-crypto/issues/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
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.
yeah, really weird indeed
that said, gpg is generally weird to deal with
Yeah for sure. I wish we could use cosign for RPMs and Debs but here we are.
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 https://github.com/goreleaser/nfpm/issues/276 but it was closed as fixed when nfpm moved to gopenpgp. I see with PR https://github.com/goreleaser/nfpm/pull/315 tests were added for signing with sub keys.
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
Search
Code of Conduct
Additional context
No response