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

Re: Testing netinst and https mirror issue

Salut Sylvain,

Sylvain Tgz <tarjaizaid@gmail.com> (2021-05-25):
> Fastly mirror by using deb.debian.org
> Sorry, I did not specify on my previous message, on syslog log during
> the netinst, we can see an issue about certificate.
> The error message : Certificate verification failed. The certificate
> is NOT trusted.
> I think ca-certificate is not loaded/used.
> For me it's an issue about  missing root certificate.
> I tested with your suggestion to use mirror/protocol=https in command
> line and it works fine :).

Alright, thanks for confirming. For the avoidance of doubt, that's
definitely a workaround and not a fix. :)

It's certainly helpful to test both debootstrap and further operations
using HTTPS when testing mini.iso (which is what I've used that for),
but that's all.

> I try again without mirror/protocol=https and the issue reappears
> To reproduce the issue :
> - Start Debian netinst
> - Use Graphical expert installation mode
> - At the step " configure the package manager" chose https.
> - Use default option
> Thie issue should be reproductible.
> Could you try ?

Yes, I can definitely reproduce the issue, and I think I have figured
out what happens. I didn't think too hard about how to fix it yet,

You're using netinst, so debootstrap uses the ISO to install the base
system. Also, unless one has forced mirror/protocol=https at this stage,
there's no chance for the user to tell debootstrap https is desired.
This means that this code path doesn't help:

and we end up without ca-certificates in /target (where the installed
system is being built).

Further down the road, apt-setup runs, lets you request https, and the
various generators/* scripts run apt-setup-verify to verify the
configuration. That command basically runs wget inside /target (through
in-target) to verify stuff, and since ca-certificates wasn't installed
earlier (good guess!), that cannot work.

Now, where to go from here… I think I would call it a bug for apt-setup
not to notice we're about to use https and not do anything about it…
Maybe it could install ca-certificates from the currently configured
source (if any) in that case. As far as I can see from this test run,
using the netinst image like you did, /target/etc/apt/sources.list still
lists the NETINST image as a cdrom: source, so that should be doable.
With other installation images (e.g. netbooting) that might not work…

Maybe something like this?

    if https is configured
      if ca-certificates is installed in target
         be happy
         if it can be installed
           install it, be happy
           duplicate /etc/ssl/certs from / into /target
           queue the installation of ca-certificates

The “duplicate” part doesn't feel right but it might be better than fail
miserably if ca-certificates cannot be installed properly. Of course
that could create a discrepancy if ca-certificates-udeb (deployed in the
installer image) and ca-certificates get out of sync, and I'm not sure
how ca-certificates will react to manually-deployed certificates…

Regarding the “queue” part, I *think* there's a way to achieve that but
I'm not sure that's true or how it would be done. If there's no generic
way to achieve this, it could still be done in a finish-install script
(apt-setup already has finish-install.d/10apt-cdrom-setup).

I'll wait a little for others to comment on my diagnosis, but I think
this could be turned into a bug report against apt-setup 1:0.163; it is
very likely that it affects buster as well, and we might want to get the
fix into buster.

Since this can only (I think, feel free to prove me wrong) be triggered
in expert mode, I would probably not block #987441 with it (or do that
so that we don't lose track, while not actually blocking 11.0 with it).

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: