"gosop verify" emits the wrong fingerprint when a subkey signature is created

[dkg]

My OpenPGP certificate C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA has a signing-capable subkey 2DB5491C9DF0DC8F432863CF3E9D717371DE565C. When validating a signature from the subkey, gosop verify should produce a verification line like:

2023-11-06T00:18:31Z 2DB5491C9DF0DC8F432863CF3E9D717371DE565C C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA

instead, it produces:

2023-11-06T00:18:31Z C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA

this is with:

$ gosop version --extended
gosop 0.1.0
GopenPGP 2.7.3
Compiled using go1.21.3
$

[twiss]

Yeah. This is a known issue, as the fingerprint is simply taken from the verification key. There's a TODO about it, here:

gosop/cmd/verify.go

Lines 62 to 63 in 30dd70b

	// TODO: This is fake
	fgp, err := hex.DecodeString(keyRing.GetKeys()[0].GetFingerprint())

Even worse, if you pass multiple verification keys, it simply prints the fingerprint of the first one, rather than the one that signed the message.

GopenPGP doesn't really return the information we need for this; though we could use go-crypto to get it instead, of course. Thanks for the report!

[lubux]

The new gosop based on GopenPGP v3 addresses this issue.