Re: apt.postgresql.org repo via https will fail will some users starting 2021-10-01

On Tue, Sep 14, 2021 at 04:33:01PM +0200, Magnus Hagander wrote:
> On Wed, Sep 8, 2021 at 6:42 PM Stefan Huehner <stefan(at)huehner(dot)org> wrote:
> >
> > Hello,
> >
> > sending this here as looks like https://apt.postgresql.org is affected by this so this could trigger some support/user questions.
> >
> > Note this only (!) happens when using https:// in sources.list for the pgdg repo.
> >
> > Benefit of that is debatable (see recent debian-devel discussion) but i would not be surprised if some/many people use it.
> >
> > Trigger:
> > https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
> >
> > End of this month some CA cert will expire related to Let's Encrypt which will trigger an bug in clients using old openssl/gnutls.
> >
> > apt is using gnutls backend and at least the version in Ubuntu <= 18.04 are affected and "apt update" will already fail for people starting that date.
> >
> > Note that canonical is working in patching gnutls so if that finishes in time and (!) if people update before that date all good.
> >
> > If not they will get error similar to:
> > Err:9 https://apt.postgresql.org/pub/repos/apt focal-pgdg Release
> > Certificate verification failed: The certificate is NOT trusted. The revocation or OCSP data are old and have been superseded. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 87.238.57.227 443]
> >
> > Can be triggered today i.e. with:
> >
> > faketime "2021-10-01" apt update
> >
> > Ideas:
> > - Do nothing apt.postgresql suggest http:// in the instructions
> > - Some on the website
> > - Think on reconfiguring certbot/Let's Encrypt on the server to switch to the alternative chain (avoiding this bug but breaking compatibility with old Android
> >
> > - Raise as bug to debian also (against openssl/gnutls) to maybe patch both in stable also to avoid this ?
> > - Not sure if that is a interesting/acceptable material for stable/old-stable?
>
> Hi!
>
> We've started looking into what can and should be done on the infra
> side to see if we can get this working.
>
> One question though. In my attempts to reproduce, it seems that *wget*
> on Ubuntu 18.04 has no problem with the current chain, just apt-get,
> does that match with your testing? So if one follows our instructions
> of getting the gpg key with https but the actual repo with http, it
> never actually presents a problem?

Hi Magnus,

sorry for the delay i was out travelling.

I just checked and and wget for Ubuntu 18.04/bionic is linked to libssl1.1 not having the problem in the first place.
Which explains why is it not affected here. I think wget can have both gnutls+openssl backend so need to see which is used per distro/release (As can change)

# apt show wget | grep Depends
Depends: libc6 (>= 2.17), libidn2-0 (>= 0.6), libpcre3, libpsl5 (>= 0.16.0), libssl1.1 (>= 1.1.0), libuuid1 (>= 2.16)

Also for apt itself in 18.04 Ubuntu has backported the fix into gnutls30 and it just reached the normal update repository.

Package/version containing the fix is:
libgnutsl30 3.5.18-1ubuntu1.5

So here if people install (non-security) updates they will be not affected.
Or telling them "run system updates" if they get the bug is enough.

Note for older Ubuntu 16.04+14.04 Ubuntu offers paid updates still which are not yet done /published for this issue but also in progress.

For debian also fixes are moving along after i reached our to debian-lts list ass Christoph suggested earlier.

> That's not saying we don't need to do anything about it, just to
> reconfirm our tests. For example, this appears to also break RedHat 6
> as well...

But good news is also impact is getting smaller with less distro/releases affected as some are getting fixed.

Also with few combinations being affected maybe just some extra note/section in the wiki could be enough.
wget http:// for affected + extra step to verify key fingerprint

For other distros (RHEL,Centos,Suse, ...) do we have anyone having contact's there nearby here?
I think there was yum.postgresql.org with Devrim active on that (but don't remember).
As probably reaching out to them maybe they are also interested in just backporting the libary fixes on their side.

Stefan

>
> --
> Magnus Hagander
> Me: https://www.hagander.net/
> Work: https://www.redpill-linpro.com/