Bug#962672: buster-pu: package ca-certificates/20200611~deb10u1
On Fri, Jun 12, 2020 at 08:40:29AM +0100, Adam D. Barratt wrote:
> On Fri, 2020-06-12 at 00:50 +0300, Adrian Bunk wrote:
> > Control: tags 962669 moreinfo
> >
> > On Thu, Jun 11, 2020 at 08:18:38PM +0100, Adam D. Barratt wrote:
> > > On Thu, 2020-06-11 at 13:48 -0500, Michael Shuler wrote:
> > > > On 6/11/20 1:33 PM, Adam D. Barratt wrote:
> > > > > Just to confirm - will the certificates be automatically re-
> > > > > added (assuming that users have either the automatically trust
> > > > > or prompt options enabled)?
> > > >
> > > > (stretch-pu report cc'ed, since same applies)
> > > >
> > > > Excellent question. I believe we're going to hit #743339
> > > > "Previously removed certificates not added again". I had not
> > > > found a reasonable fix for that case in general, to preserve a
> > > > user's selections.
> > > > Maybe a "good enough" fix will have to do for the specific ones
> > > > added back.
> > >
> > > OK.
> > >
> > > In that case, how does this seem as an SUA text?
> [...]
> > > use the affected certificates, you may need to manually enable them
> > > by running "dpkg-reconfigure ca-certificates" as root.
> > > ====================
> >
> > This does not work in various embedded scenarios.
>
> Wouldn't embedded setups be more likely to have a hard-coded
> configuration?
The official way to hardcode CA configuration would be through debconf
or /etc/ca-certificates.conf, which runs into #743339.
If you are really security-focussed you might pin the actual certificate
instead of trusing a CA.
For the average embedded device the only thing that matters about
ca-certificates is something like "https works".
> > Would it work to force-enable them in /etc/ca-certificates.conf
> > from the preinst when upgrading from old-version matching 20200601* ?
This could actually be done in the postinst before the debconf
configuration, something like
sed -i "s|^\!mozilla/GeoTrust_Global_CA.crt|mozilla/GeoTrust_Global_CA.crt|" /etc/ca-certificates.conf
for all affected certificates when $2 matches 20200601*
> I'll leave the technical answer to Michael.
>
> Practically, it's then not great for users who had intentionally
> removed the certificates - or simply decided not to trust them in the
> first place - prior to the upgrade. I'm not sure how we could
> distinguish the cases automatically.
The default is to trust all new certificates, so this is what the vast
majority of users are using.
#743339 is primarily about this kind of remove+readd in the package
being the only way how any installed certificate could end up being
deactivated in the default situation.
This is permanent damage that can lead to nasty problems months or
years later.
There are likely some users somewhere who have manually activated or
deactivated these specific certificates, but this is nothing we can
handle correctly in both directions now.
> > Unrelated to that, please keep the Python 2 -> 3 build dependency
> > change out of this emergency update.
>
> ACK.
>
> Regards,
>
> Adam
cu
Adrian
Reply to: