Bug#969588: sqv: Cannot use ASCII armored key as keyring?
Daniel Kahn Gillmor writes: > On Fri 2020-10-16 12:05:48 +0200, Justus Winter wrote: >> 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. > > I understand your reasoning, but text files *do* concatenate to a longer > textfile, and textual-representations of a keyring are text files. I still think that this is an accident, but for the benefit of everyone coming from GnuPG we implemented it in Sequoia, so the next version of sqv will support this. > and, we have (i think) a pretty solid understanding of what a > concatenated ASCII-armored keyring would look like. So i'm proposing > that sop (at least) should be able to handle concatenated ASCII-armored > certificates: > >https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/28 > > Please weigh in over there! I did. Cheers, Justus signature.asc Description: PGP signature
Bug#969588: sqv: Cannot use ASCII armored key as keyring?
On Fri 2020-10-16 12:05:48 +0200, Justus Winter wrote: > 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. I understand your reasoning, but text files *do* concatenate to a longer textfile, and textual-representations of a keyring are text files. and, we have (i think) a pretty solid understanding of what a concatenated ASCII-armored keyring would look like. So i'm proposing that sop (at least) should be able to handle concatenated ASCII-armored certificates: https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/28 Please weigh in over there! --dkg signature.asc Description: PGP signature
Bug#969588: sqv: Cannot use ASCII armored key as keyring?
Hi :) Guillem Jover 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
Bug#969588: sqv: Cannot use ASCII armored key as keyring?
Hi! On Thu, 2020-10-15 at 11:40:59 -0400, Daniel Kahn Gillmor wrote: > On Sat 2020-09-05 17:09:06 +0200, Guillem Jover wrote: > > I was trying out sqv, to potentially add native support for it into > > dpkg-dev, but either it does not work as expected or I'm confused by > > the docs. :) > > > > $ apt source libbsd > > $ sqv -v --keyring libbsd-0.10.0/debian/upstream/signing-key.asc \ > > libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz > > Missing key 4F3E74F436050C10F5696574B972BF3EA4AE57A3, which is needed to > > verify signature. > > 0 of 1 signatures are valid (threshold is: 1). > > $ sqv -v --keyring /usr/share/keyrings/debian-keyring.gpg \ > > libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz > > 4F3E74F436050C10F5696574B972BF3EA4AE57A3 > > 1 of 1 signatures are valid (threshold is: 1). > > I forwarded this to upstream at > https://gitlab.com/sequoia-pgp/sequoia/-/issues/585, and Justus there > suggests that the problem is that the OpenPGP certificate in > libbsd-0.10.0/debian/upstream/signing-key.asc is not up-to-date. With a > refreshed version of the certificate, it appears to work. 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. > 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. Thanks, Guillem
Bug#969588: sqv: Cannot use ASCII armored key as keyring?
On Sat 2020-09-05 17:09:06 +0200, Guillem Jover wrote: > I was trying out sqv, to potentially add native support for it into > dpkg-dev, but either it does not work as expected or I'm confused by > the docs. :) > > $ apt source libbsd > $ sqv -v --keyring libbsd-0.10.0/debian/upstream/signing-key.asc \ > libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz > Missing key 4F3E74F436050C10F5696574B972BF3EA4AE57A3, which is needed to > verify signature. > 0 of 1 signatures are valid (threshold is: 1). > $ sqv -v --keyring /usr/share/keyrings/debian-keyring.gpg \ > libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz > 4F3E74F436050C10F5696574B972BF3EA4AE57A3 > 1 of 1 signatures are valid (threshold is: 1). I forwarded this to upstream at https://gitlab.com/sequoia-pgp/sequoia/-/issues/585, and Justus there suggests that the problem is that the OpenPGP certificate in libbsd-0.10.0/debian/upstream/signing-key.asc is not up-to-date. With a refreshed version of the certificate, it appears to work. 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! --dkg signature.asc Description: PGP signature
Bug#969588: sqv: Cannot use ASCII armored key as keyring?
Package: sqv Version: 0.17.0-1 Severity: normal Hi! I was trying out sqv, to potentially add native support for it into dpkg-dev, but either it does not work as expected or I'm confused by the docs. :) $ apt source libbsd $ sqv -v --keyring libbsd-0.10.0/debian/upstream/signing-key.asc \ libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz Missing key 4F3E74F436050C10F5696574B972BF3EA4AE57A3, which is needed to verify signature. 0 of 1 signatures are valid (threshold is: 1). $ sqv -v --keyring /usr/share/keyrings/debian-keyring.gpg \ libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz 4F3E74F436050C10F5696574B972BF3EA4AE57A3 1 of 1 signatures are valid (threshold is: 1). Thanks, Guillem
