[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPG Workshop during DebCamp



Hi Simon :)

Simon Josefsson <simon@josefsson.org> writes:

> Justus Winter <justus@sequoia-pgp.org> writes:
>
>> Petter Reinholdtsen <pere@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.

>> % 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.


Best,
Justus

Attachment: signature.asc
Description: PGP signature


Reply to: