Justus Winter <jus...@sequoia-pgp.org> writes: > Hi Simon :) > > Simon Josefsson <si...@josefsson.org> writes: > >> Justus Winter <jus...@sequoia-pgp.org> writes: >> >>> Petter Reinholdtsen <p...@hungry.com> writes: >>> >>>> [Justus Winter] >>>>> GnuPG no longer tracks OpenPGP, but something they call LibrePGP. If >>>>> you look closely at a certificate created from it, you can see some >>>>> troubling divergences already. For example, this is from one created >>>>> by GnuPG 2.4.4: >>>> >>>> Thank you for the details. I found <URL: https://librepgp.org/ > which >>>> explain their rationale. Seem to be quite a split in world view in >>>> place here. >>> >>> Yes, that is what the media has dubbed "the SCHISM", >>> e.g. https://lwn.net/Articles/953797/ >>> >>> I played around with GnuPG 2.4.4, and it is easy to accidentally create >>> an out-of-spec cert with it: >> >> To be fair, the spec is available, isn't it? It just isn't OpenPGP. > > I didn't say that it isn't available. But, everybody can write up such > an document, that doesn't make it a standard. And, having actually read > it, I can say that without considerable work and editing, this is far > away from the quality we expect from a standard.
Right, it is the process to gather implementations around a document that makes something a standard. Even if a document has low quality, but a sufficient mass of implementations tend to follow it in a similar enough way, I don't think the quality of the document is particular important. >>> % gpg --export >>> F3AE83A58BD3B8981C8F0AECC5AD7DC02CFAB1F1F14D7998FF87244ADDE1B6C1 | sq >>> toolbox packet dump --hex >>> Unknown or Unsupported Packet, old CTB, 2 header bytes + 73 bytes >> >> Looks like a feature request on the 'sq' tool to support this packet >> type would be useful. > > One of the more difficult, yet maybe most important aspects of > maintaining and developing software is saying no to a request. > > We believe that declining this request is in the best interest of the > OpenPGP ecosystem and its users, even if it may hurt some fraction of > users who inadvertently used the newer GnuPG versions to create new > keys, and may are stuck with unusable keys and/or messages. > > In the OpenPGP ecosystem, we have seen that people think that if GnuPG > accepts an artifact, then it must be okay to emit such an artifact. As > you can see [0], GnuPG still accepts SHA1-based signatures. And, we > have seen big players [1][2] use SHA-1 in their signing keys. > > 0: https://tests.sequoia-pgp.org/#Signature_over_the_shattered_collision > 1: https://github.com/microsoft/linux-package-repositories/issues/47 > 2: https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c19 > > We considerably improved the situation by rejecting these signatures, > even though that caused a considerable amount of pain in the short term. > > > I think Debian shouldn't be asking whether Sequoia can add support for a > proprietary format. > > I think Debian should be asking whether GnuPG can add support for a > format standardized in an international standardization body, which > enjoys broad support from the implementation community. Those are reasonable requests, but I don't think they are the only ones. Compare the situation with OpenSSH and the SSH protocol. If you implement the SSH RFCs I believe you won't be able to interoperate with OpenSSH. So all usable SSH implementations add protocol elements that OpenSSH has added. The other implementations could just have said no and regard compatibility with OpenSSH as unimportant, but they didn't. Are you saying that Debian should be asking OpenSSH to comply with the IETF RFCs? Should Debian be modifying OpenSSH to comply with the RFCs, even if that would deviate from upstream OpenSSH? Should Debian switch to a SSH server that comply with the RFCs? These are rethoric questions, but I think they illustrate my point that this matter is complex and involves chosing who you want to trust. GnuPG authors? OpenSSH authors? Sequoia authors? An international standardization body? Another analogy would be Signal vs SMS. For good or bad, the Signal authors didn't like what they saw in SMS security, so they created something else. Signal is not standardized, and SMS is governed by an international standardization body too. /Simon
signature.asc
Description: PGP signature
