TLS certificate on elpa.gnu.org

TLS certificate on elpa.gnu.org

[Neil Okamoto]

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]


elpa.gnu.org seems to be malformed in a way that causes some SSL analyzers to warn about “extra certs”.  

For instance https://www.ssllabs.com/ssltest/analyze.html?d=elpa.gnu.org <https://www.ssllabs.com/ssltest/analyze.html?d=elpa.gnu.org> reports

Certificates provided | 3 (3732 bytes)
Chain issues | Incorrect order, Extra certs
And of the three certificates found, it appears certificate[0] and certificate[1] are identical. Is the duplication considered "out of order?”

Because indeed, on older variants of Ubuntu where gnutls-cli v2.12.23 is in use (this is the case for the container infrastructure on Travis CI), we have this:

# gnutls-cli -v
gnutls-cli (GnuTLS) 2.12.23
Packaged by Debian (2.12.23-12ubuntu2.8)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Nikos Mavrogiannopoulos.
#
# gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 elpa.gnu.org
Processed 148 CA certificate(s).
Resolving 'elpa.gnu.org'...
Connecting to '208.118.235.89:443'...
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.


Which means tools like “Cask” which invoke Emacs in batch to install dependencies from package repos like ELPA or MELPA are failing on the Travis CI infrastructure.

It’s causing me to introduce workarounds, such as downloading a newer gnutls source package and compiling it locally in the Travis CI build. I would really prefer not to do this. It adds unnecessary time and complexity to the CI setup for some Emacs packages, and (conversely) one can imagine other Emacs package maintainers may be avoiding the complexity by not implementing CI for their projects.

Can someone more knowledgable about the standards, the evolution of gnutls since 2.12, and the server configuration of elope.gnu.org please weigh in on this?

thanks
Neil






[-- Attachment #2: Type: text/html, Size: 6868 bytes --]

Re: TLS certificate on elpa.gnu.org

[Clément Pit-Claudel]

On 2018-02-03 22:13, Neil Okamoto wrote:
> Which means tools like “Cask” which invoke Emacs in batch to install dependencies from package repos like ELPA or MELPA are failing on the Travis CI infrastructure.

Ah, thanks so much for tracking this down!  I'd been wanting to track that error down for a while.  Great sleuthing work!

Re: TLS certificate on elpa.gnu.org

[Eli Zaretskii]

> From: Neil Okamoto <neil.okamoto@gmail.com>
> Date: Sat, 3 Feb 2018 19:13:03 -0800
> 
> elpa.gnu.org seems to be malformed in a way that causes some SSL analyzers to warn about “extra certs”.  
> 
> For instance https://www.ssllabs.com/ssltest/analyze.html?d=elpa.gnu.org reports
> 
> Certificates provided | 3 (3732 bytes)
> Chain issues | Incorrect order, Extra certs
> 
> And of the three certificates found, it appears certificate[0] and certificate[1] are identical. Is the duplication
> considered "out of order?”
> 
> Because indeed, on older variants of Ubuntu where gnutls-cli v2.12.23 is in use (this is the case for the
> container infrastructure on Travis CI), we have this:
> 
> # gnutls-cli -v
> gnutls-cli (GnuTLS) 2.12.23
> Packaged by Debian (2.12.23-12ubuntu2.8)
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.

Isn't this an awfully old version of GnuTLS?  I have here 3.4.15, and
it doesn't complain about the GNU ELPA certificate.  It says "Status:
The certificate is trusted."

> It’s causing me to introduce workarounds, such as downloading a newer gnutls source package and
> compiling it locally in the Travis CI build. I would really prefer not to do this. It adds unnecessary time and
> complexity to the CI setup for some Emacs packages, and (conversely) one can imagine other Emacs
> package maintainers may be avoiding the complexity by not implementing CI for their projects.
> 
> Can someone more knowledgable about the standards, the evolution of gnutls since 2.12, and the server
> configuration of elope.gnu.org please weigh in on this?

I'm not such an expert on this, but in general, security assumes
latest versions of related software and databases.

Re: TLS certificate on elpa.gnu.org

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am So., 4. Feb. 2018 um 17:30 Uhr:

> > From: Neil Okamoto <neil.okamoto@gmail.com>
> > Date: Sat, 3 Feb 2018 19:13:03 -0800
> >
> > elpa.gnu.org seems to be malformed in a way that causes some SSL
> analyzers to warn about “extra certs”.
> >
> > For instance https://www.ssllabs.com/ssltest/analyze.html?d=elpa.gnu.org
> reports
> >
> > Certificates provided | 3 (3732 bytes)
> > Chain issues | Incorrect order, Extra certs
> >
> > And of the three certificates found, it appears certificate[0] and
> certificate[1] are identical. Is the duplication
> > considered "out of order?”
> >
> > Because indeed, on older variants of Ubuntu where gnutls-cli v2.12.23 is
> in use (this is the case for the
> > container infrastructure on Travis CI), we have this:
> >
> > # gnutls-cli -v
> > gnutls-cli (GnuTLS) 2.12.23
> > Packaged by Debian (2.12.23-12ubuntu2.8)
> > Copyright (C) 2012 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>.
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
>
> Isn't this an awfully old version of GnuTLS?
>

It is the version shipped with the current LTS version of Ubuntu:
https://packages.ubuntu.com/trusty/gnutls-bin


>
> > It’s causing me to introduce workarounds, such as downloading a newer
> gnutls source package and
> > compiling it locally in the Travis CI build. I would really prefer not
> to do this. It adds unnecessary time and
> > complexity to the CI setup for some Emacs packages, and (conversely) one
> can imagine other Emacs
> > package maintainers may be avoiding the complexity by not implementing
> CI for their projects.
> >
> > Can someone more knowledgable about the standards, the evolution of
> gnutls since 2.12, and the server
> > configuration of elope.gnu.org please weigh in on this?
>
> I'm not such an expert on this, but in general, security assumes
> latest versions of related software and databases.
>
>
Security requires *patched* versions, not *updated* versions. That's a big
difference. Ubuntu LTS gets security patches until the end of its lifetime,
but no bug fixes or new features. The security patches only fix
vulnerabilities.

[-- Attachment #2: Type: text/html, Size: 3362 bytes --]

Re: TLS certificate on elpa.gnu.org

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 04 Feb 2018 16:48:04 +0000
> Cc: Neil Okamoto <neil.okamoto@gmail.com>, emacs-devel@gnu.org
> 
>  Isn't this an awfully old version of GnuTLS? 
> 
> It is the version shipped with the current LTS version of Ubuntu: https://packages.ubuntu.com/trusty/gnutls-bin
>  
>  
>  > It’s causing me to introduce workarounds, such as downloading a newer gnutls source package and
>  > compiling it locally in the Travis CI build. I would really prefer not to do this. It adds unnecessary time
>  and
>  > complexity to the CI setup for some Emacs packages, and (conversely) one can imagine other
>  Emacs
>  > package maintainers may be avoiding the complexity by not implementing CI for their projects.
>  >
>  > Can someone more knowledgable about the standards, the evolution of gnutls since 2.12, and the
>  server
>  > configuration of elope.gnu.org please weigh in on this?
> 
>  I'm not such an expert on this, but in general, security assumes
>  latest versions of related software and databases.
> 
> Security requires *patched* versions, not *updated* versions. That's a big difference. Ubuntu LTS gets
> security patches until the end of its lifetime, but no bug fixes or new features. The security patches only fix
> vulnerabilities. 

To me, the fact that a newer version of GnuTLS doesn't show this
problem means that the issue was resolved by further development of
that package.  Maybe Ubuntu needs to backport more patches?

Anyway, we can continue discussing this here to Kingdom Come, but if
we want to hear from experts, this issue should be brought on the
GnuTLS mailing list, not here.

Re: TLS certificate on elpa.gnu.org

[Neil Okamoto]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]


> On Feb 4, 2018, at 9:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Philipp Stephani <p.stephani2@gmail.com>
>> Date: Sun, 04 Feb 2018 16:48:04 +0000
>> Cc: Neil Okamoto <neil.okamoto@gmail.com>, emacs-devel@gnu.org
>> 
>> Isn't this an awfully old version of GnuTLS? 
>> 
>> It is the version shipped with the current LTS version of Ubuntu: https://packages.ubuntu.com/trusty/gnutls-bin
>> 
>> 
>>> It’s causing me to introduce workarounds, such as downloading a newer gnutls source package and
>>> compiling it locally in the Travis CI build. I would really prefer not to do this. It adds unnecessary time
>> and
>>> complexity to the CI setup for some Emacs packages, and (conversely) one can imagine other
>> Emacs
>>> package maintainers may be avoiding the complexity by not implementing CI for their projects.
>>> 
>>> Can someone more knowledgable about the standards, the evolution of gnutls since 2.12, and the
>> server
>>> configuration of elope.gnu.org please weigh in on this?
>> 
>> I'm not such an expert on this, but in general, security assumes
>> latest versions of related software and databases.
>> 
>> Security requires *patched* versions, not *updated* versions. That's a big difference. Ubuntu LTS gets
>> security patches until the end of its lifetime, but no bug fixes or new features. The security patches only fix
>> vulnerabilities. 
> 
> To me, the fact that a newer version of GnuTLS doesn't show this
> problem means that the issue was resolved by further development of
> that package.  Maybe Ubuntu needs to backport more patches?
> 
> Anyway, we can continue discussing this here to Kingdom Come, but if
> we want to hear from experts, this issue should be brought on the
> GnuTLS mailing list, not here.

Ok, I’m re-posting to gnutls-help.



[-- Attachment #2: Type: text/html, Size: 7446 bytes --]