Re: Testing netinst and https mirror issue

[Cyril Brulebois]

Cyril Brulebois  (2021-05-27):
> 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.

Scratch that (my focus was on other things and I kept a wrong assumption
there): it calls `debconf-apt-progress` (rather than `wget`, pointing to
a temporary file where the tentative configuration is stored).

And slightly more annoyingly, manually copying /etc/ssl(/certs) into
/target, beforehand or after a first failure before trying again, isn't
sufficient.

The error message in apt comes from:

   // Credential setup
   std::string fileinfo = Owner->ConfigFind("CaInfo", "");
   if (fileinfo.empty())
   {
  // No CaInfo specified, use system trust store.
→ err = gnutls_certificate_set_x509_system_trust(tlsFd->credentials);
→ if (err == 0)
→Owner->Warning("No system certificates available. Try installing 
ca-certificates.");
  else if (err < 0)
  {
 _error->Error("Could not load system TLS certificates: %s", 
gnutls_strerror(err));
 return ResultState::FATAL_ERROR;
  }

A quick strace shows the following file (missing in the ca-certificates
udeb, and therefore in my manual copy into /target) is desired:

/etc/ssl/certs/ca-certificates.crt

And finally, concatenating all certificates into that single file seems
to make `debconf-apt-progress` happy, so maybe we would just have to
create the directory and ship that particular file there to avoid an
installation failure, and I would expect ca-certificates to just
re-regenerate that file upon installation/upgrade, so that might not
break anything (even if not really clean)?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Testing netinst and https mirror issue

[Cyril Brulebois]

Salut Sylvain,

Sylvain Tgz  (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,
though.

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:
  
https://salsa.debian.org/installer-team/debootstrap/-/blob/master/scripts/debian-common#L30-41

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
  else
 if it can be installed
   install it, be happy
 else
   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).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#988442: unblock: linux/5.10.37-1 (pre-approval checking)

[Cyril Brulebois]

Paul Gevers  (2021-05-27):
> Control: tags -1 confirmed d-i
> 
> @boot: needs d-i ACK. As I believe you are aware of, the upload has
> already happened.
> 
> @kibi: feel free to age it if/when you see fit

We've just discussed that (with Salvatore) on IRC minutes ago, and it
seems like this unblock request will be withdrawn/recycled for another
version, that version needs fixing.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#988442: unblock: linux/5.10.37-1 (pre-approval checking)

[Paul Gevers]

Control: tags -1 confirmed d-i

@boot: needs d-i ACK. As I believe you are aware of, the upload has
already happened.

@kibi: feel free to age it if/when you see fit

Paul

On 19-05-2021 17:27, Salvatore Bonaccorso wrote:
> Control: retitle -1 unblock: linux/5.10.38-1 (pre-approval checking)
> 
> On Thu, May 13, 2021 at 09:30:29AM +0200, Salvatore Bonaccorso wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>> X-Debbugs-Cc: car...@debian.org
>>
>> Dear release team,
>>
>> As you know we follow the respective stable series as well in a stable
>> release, and usually this is then done in point releases
>> (exceptionally as well via a DSA). Now I know the time for bullseye is
>> tight, but I would still like to followup with a stable series import
>> in unstable, but wanted to double check with you in aprticular if
>> there are ny timing issues with d-i.
>>
>> I would plan to upload based ideally on 5.10.37 because it will cover
>> a big amount of bufixes but particularly recent CVEs which are
>> important to have covered in bullseye already soon. Currently already
>> covered in the imports done in git and in the packaging pending are
>> CVE-2020-25670, CVE-2020-25671, CVE-2020-25672, CVE-2021-3489,
>> CVE-2021-3490, CVE-2021-3491, CVE-2021-3493, CVE-2021-3501,
>> CVE-2021-3506, CVE-2021-23133, CVE-2021-23134, CVE-2021-29155,
>> CVE-2021-31829, but I would want do cover as well the recent
>> FragAttack fixes (not yet worked on).
>>
>> In the packaging itself there will be additional changes pending
>> currently they are:
>>
>>[ Vincent Blut ]
>>* [x86] sound/soc/intel: Enable SND_SOC_INTEL_CATPT as module
>>  (Closes: #986822)
>>* [x86] sound/soc/intel/boards: Enable SND_SOC_INTEL_BDW_RT5650_MACH as
>>  module
>>* drivers/input/rmi4: Enable RMI4_F3A (Closes: #986848)
>>* [armhf] drivers/gpio: Enable GPIO_MXC as module (Closes: #987019)
>>* [x86] drivers/misc/mei: Enable INTEL_MEI_TXE, INTEL_MEI_HDCP as modules
>>  (Closes: #987281)
>>
>> All of those are for better hardware support.
>>
>>[ Uwe Kleine-König ]
>>* [arm64] Enable more options for NXP's i.MX8 (Closes: #985862)
>>
>> Samewise.
>>
>>[ Salvatore Bonaccorso ]
>>* vfs: move cap_convert_nscap() call into vfs_setxattr() (CVE-2021-3493)
>>* Refresh "Makefile: Do not check for libelf when building OOT module"
>>* [rt] Drop "xfrm: Use sequence counter with associated spinlock"
>>* Bump ABI to 7
>>* Refresh "tools/include/uapi: Fix "
>>* Revert "net/sctp: fix race condition in sctp_destroy_sock"
>>* sctp: delay auto_asconf init until binding the first addr 
>> (CVE-2021-23133)
>>* net/nfc: fix use-after-free llcp_sock_bind/connect (CVE-2021-23134)
>>* bpf, ringbuf: Deny reserve of buffers larger than ringbuf 
>> (CVE-2021-3489)
>>* bpf: Prevent writable memory-mapping of read-only ringbuf pages
>>* bpf: Fix alu32 const subreg bound tracking on bitwise operations
>>  (CVE-2021-3490)
>>* io_uring: truncate lengths larger than MAX_RW_COUNT on provide buffers
>>  (CVE-2021-3491)
>>
>> Various CVE fixes (which will though go as well partially in 5.10.37 
>> directly),
>> the FragAttack CVEs are not yet included.
>>
>> The RT patch which can be dropped after checking with Sebastian
>> Andrzej Siewior. An ABI bump included, note that the changes are quite
>> massive up to 5.10.37, (5.10.37 will contain approximately 530
>> upstream commits, 5.10.36 was as well with 300 a bigger one). I
>> realize this might scary, but in the end this is the stragegy we
>> necessarily need to follow to keep up with upstream stable releases.
>>
>>[ Vagrant Cascadian ]
>>* [arm64] Disable USB type-C DisplayPort in pinebook pro device-tree.
>>* [arm64] Enable TYPEC_FUSB302, SND_SOC_ES8316, TYPEC and TYPEC_TCPM as
>>  modules. (Closes: #987638)
>>
>>[ Michal Simek ]
>>* [arm64] Enable clock driver for Xilinx ZynqMP SoC
>>
>> Additional support for hardware in the arm64 area.
>>
>>[ Valentin Vidic ]
>>* [s390x] udeb: Include standard scsi-modules containing the virtio_blk
>>  module (Closes: #988005)
>>
>> "Acked"/wished by KiBi, to align s390x installer support to the other
>> architectures.
>>
>> The current state is at https://salsa.debian.org/kernel-team/linux/-/tree/sid
>>
>> Let me know what you think of it, I would in any case send the usual
>> "Upload announcement" to the various involved teams before the upload
>> summarizing again the changes.
> 
> For the record, this will be 5.10.38 based. I delayed on purpose given
> the size which was forseen. 
> 
> If anybody has concern on the upload, please raise a flag.
> 
> Regards,
> Salvatore
> 



OpenPGP_signature
Description: OpenPGP digital signature

Processed: Re: Bug#988472: install-mbr doesnt create a partition

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 installation-guide
Bug #988472 [release-notes] install-mbr doesnt create a partition
Bug reassigned from package 'release-notes' to 'installation-guide'.
Ignoring request to alter found versions of bug #988472 to the same values 
previously set
Ignoring request to alter fixed versions of bug #988472 to the same values 
previously set

-- 
988472: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988472
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Bug#988472: install-mbr doesnt create a partition

[Paul Gevers]

Control: reassign -1 installation-guide

On 13-05-2021 18:32, Justin B Rye wrote:
> Marc Haber wrote:
>> Package: release-notes
>> Severity: minor
>>
>> Hi,
>>
>> Chapter 4.3.3.1 of the release notes suggest using install-mbr /dev/sdX
>> followed by mkdosfs /dev/sdX1. On a really blank medium, this doesn't
>> work since install-mbr does NOT create a partition.
> 
> You mean the Installation Guide, not the Release Notes.
> 
>  
> "https://www.debian.org/releases/stable/amd64/ch04s03.en.html#usb-copy-flexible;
> | Since most USB sticks come pre-configured with a single FAT16
> | partition, you probably won't have to repartition or reformat the
> | stick. If you have to do that anyway, use cfdisk or any other
> | partitioning tool to create a FAT16 partition[3], install an MBR using:
> |
> | # install-mbr /dev/sdX
> |
> 
> It looks to me as if this needs "(and) then" before "install", among
> other fixes.  For instance, footnote 3 is:
> 
> | [3] Don't forget to set the "bootable" bootable flag.
> 
> which is probably trying to say:
> 
>   [3] Don't forget to activate the "bootable" flag.



OpenPGP_signature
Description: OpenPGP digital signature