Right.
https://bugs.launchpad.net/bugs/1799550 has been opened in 2018 to track
the dual boot issue. This is the security issue I was referring to. Sorry
for the confusion.

Le mar. 22 déc. 2020 à 22:30, Julian Andres Klode <
<email address hidden>> a écrit :

> The issue reported here is that /boot is not encrypted in the supported
> configurations. Which is meh - we don't have much authenticated
> encryption, so boot can still be manipulated. Sealed TPM measurements
> address the problem of verifying the bootloader, kernel, initrd, and the
> configuration better. It does not provide security by obfuscation as
> encryption does, but that obfuscation can be circumvented - you can
> modify an encrypted boot partition and still get a working system - and
> authenticated encryption that would also authenticate the content is not
> stable yet.
>
> I cannot say much on the other issue raised in recent comments on dual
> boot setups not installing encrypted, but I fail to see how it's related
> to this bug report
>
> I do want to point out that with devices now being sold with BitLocker
> out of the box, that you do have to disable BitLocker first to even get
> the ability to install another OS, so I fail to see how that improves
> the situation for dual boot users who need encryption.
>
> But in any case adding comments to bugs that are unrelated to the bug is
> not really helpful, you end up with nobody knowing what people are
> talking about anymore.
>
> Hence my suggestion would be to open a new bug report against ubiquity
> describing the dual boot setup issues so that that can be tracked on its
> own and we don't have to discuss two bugs in one bug report.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1773457
>
> Title:
>   Full-system encryption needs to be supported out-of-the-box including
>   /boot and should not delete other installed systems
>
> Status in grub2 package in Ubuntu:
>   Confirmed
> Status in ubiquity package in Ubuntu:
>   Confirmed
>
> Bug description:
>   In today's world, especially with the likes of the EU's GDPR and the
>   many security fails, Ubuntu installer needs to support full-system
>   encryption out of the box.
>
>   This means encrypting not only /home but also both root and /boot. The
>   only parts of the system that wouldn't be encrypted are the EFI
>   partition and the initial Grub bootloader, for obvious reasons.
>
>   It should also not delete other installed systems unless explicitly
>   requested.
>
>   On top of this, the previous method of encrypting data (ecryptfs) is
>   now considered buggy, and full-disk encryption is recommended as an
>   alternative. Unfortunately, the current implementation of full-disk
>   encryption wipes any existing OS such as Windows, making the
>   implementation unusable for most users.
>
>   Now, using LUKS and LVM, it is already possible to have full-disk
>   encryption (strictly, full-partition encryption because it leaves any
>   existing OS alone), while encrypting /boot. Reference:
>
>   https://help.ubuntu.com/community/ManualFullSystemEncryption
>
>   ... but with one major limitation: Grub is incorrectly changed after
>   an update affecting the kernel or Grub, so that a manual Grub update
>   is required each time this happens (this is fully covered in the
>   linked instructions).
>
>   If the incorrect Grub change is fixed, it should be (relatively)
>   simple to support full-system encryption in the installer.
>
>   Further information (2018-08-17):
>
>   The NCSC recommends, "Use LUKS/dm-crypt to provide full volume
> encryption."
>   References:
>   •
> https://blog.ubuntu.com/2018/07/30/national-cyber-security-centre-publish-ubuntu-18-04-lts-security-guide
>   • https://www.ncsc.gov.uk/guidance/eud-security-guidance-ubuntu-1804-lts
>
>   **EDIT**
>   Refer to comment #47 for an alternative version.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1773457/+subscriptions
>