Hi :) Guillem Jover <[email protected]> writes:
> I was also embarrassed for a moment, :) then realized this should have > failed with GnuPG, and rechecking the signing-key.asc recalled it > contains the two certificates concatenated one after the other, which > GnuPG seems to be able to import correctly. Now I'm also embarrassed, I should have tried with gpgv :D >> So i don't think this is a bug in sqv, and i'm closing the ticket. Feel >> free to reopen if you think that there is still a problem! > > I guess that depends on whether sqv is supposed to support > concatenated certificates, or whether they need to be in a single > ASCII armored block? > > I'm not sure how prevalent this is in the archive, but I expect other > instances to exist there. ISTR concatenation being documented > somewhere as a way to add new certificates. It is true that GnuPG supports reading certificates from concatenated armor blocks. But that is not widely supported by other OpenPGP implementations. Most just look at the first armor block and discard the rest: https://tests.sequoia-pgp.org/#Concatenated_ASCII_Armor_Keyring To be clear: Concatenating binary certificates to generate a keyring is possible. A keyring is just a series of certificates, and a certificate is a series of packets, there is no additional framing, so concatenation works out fine. It is not obvious that the same expectation should hold for armored certificates. As an analogy, concatenating two text files works, but concatenating two tar balls containing a text file each does not. And in general, the expectation that you can join two files does not hold. Concatenating two photos doesn't yield a slideshow, etc. So my position on the matter is that concatenating two binary certificates yielding a keyring is a happy accident of an implementational detail, but shouldn't be relied upon, and certainly does not extend to other representations of certificates. Cheers, Justus
signature.asc
Description: PGP signature
