Subject: bug#51038: 27.2; ELPA certificate not trusted on Windows

From: John Cummings <[email-masked]>
Date: Wed, 06 Oct 2021 16:13:35 +0000

Eli Zaretskii <[email-masked]> wrote:
>> Date: Wed, 06 Oct 2021 13:39:50 +0000
>> From: John Cummings <[email-masked]>
>> Cc: [email-masked], [email-masked], [email-masked]
>>
>> > That's not how this stuff works on MS-Windows.
>>
>> That's how it works on any system running gnutls 3.6.12, no? The bug
>> in gnutls is fixed in 3.6.14.

> Maybe we aren't talking about the same bug, then.  AFAIU, the problem
> is supposed to be solved by updating the cert bundle, isn't that so?

In my understanding, the root cause is that GnuTLS focuses on the
expired root without considering alternate paths, so removing the
expired root hides the behavior, but GnuTLS would still need fixing.

> If the bug is in GnuTLS, then simply install a newer one from the
> MSYS2 site, and that's it.

That makes sense to me as one possible way to correct this. It seems
like we all agree that the 27.2 Windows build on ftp.gnu.org has this
"potential for undesirable behavior" (if the term "bug" doesn't sit
right with anyone.) I thought this bug report would end up serving
to:

1. acknowledge the behavior in that specific binary

2. list fixes/workarounds like updating GnuTLS individually,
   or modifying the system trust store

3. communicate that this behavior will no longer happen in
   the version 28 binaries (once released), for those who might not
   be in a position to update GnuTLS independently, or would
   rather wait for an updated binary with deps.

I understand that the Windows binaries are a volunteer courtesy, so if
nothing else, I think users of that binary would benefit from some
formal thing telling them that this behavior exists and will
eventually be changed. Hopefully that's already accomplished, and
people will just find this bug if they search, and understand the
situation with respect to the v 28 Windows binaries.