<div dir="ltr">Hello,<br><br>I have raised a request to modify the Ubuntu installation to allow for full-disk encryption.<br><br><a href="https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1773457">https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1773457</a><br><br>This is different from the current installer's full-disk encryption in two important ways.<br><br>1. The current installer doesn't play nicely with other operating systems, e.g. Windows. So, if you want full-disk encryption (for Ubuntu, at least) but to retain Windows, you can't do this.<div><br>2. The current installer doesn't encrypt /boot.<br><br>The request covers both of these points. It encrypts everything apart from the EFI System Partition (ESP) and already-existing operating systems, both for obvious reasons.<br><br>WHY<br><br>I have raised this request because it provides maximum protection both <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">against<span> </span></span>accessing or modifying data and against adding malware if the machine's physical security is compromised. It also allows the installation to proceed even if Windows is already on the system, which is the usual situation for most users. It is a great step towards tighter security.<br><br>IT'S ALREADY POSSIBLE AND DOCUMENTED<br><br>This full-disk encryption is already possible, playing nicely with other operating systems and encrypting even /boot. It uses LVM within LUKS. You can find the documentation in the Community Help:<br><br><a href="https://help.ubuntu.com/community/ManualFullSystemEncryption">https://help.ubuntu.com/community/ManualFullSystemEncryption</a><br><br>(There is one important complication in that updates to the kernel don't update Grub correctly, which must be manually updated with a script provided as part of the process. I believe that I know how to address this shortfall by automating the running of the script, but due to other priorities, it will take some time for me to test and document. Of course, fixing the kernel updates would be preferable to this workaround, but I don't know how to do so.)<br><br>OBJECTION<br><br>In the request's comments, I have been told that full-system encryption should not be done because it's possible to load malware into the EFI System Partition (ESP).</div><div><br></div><div>I personally disagree with that assessment because, if we were to accept that argument, it would mean removing the installer's current ability for full-disk encryption (where not only the ESP but also /boot are exposed), and even removing the ability to encrypt /home (for non-full-disk encryption, where the file system and even root are exposed).</div><div><br></div><div>This goes completely against current security advice, which recommends the greatest possible encryption.<br><br>Although there might conceivably be a valid reason to reject my request, this fact that the ESP is exposed absolutely isn't a good reason, and contradicts the existing two abilities to encrypt.<br><br>After some toing and froing, I was advised to post to this list to raise the issue. Hence, here we are!<br><br>IDEAS<br><br>Developers, do you have opinions, suggestions or other ideas, please?<br><br>Thank you<br><br>Paddy Landau<br></div></div>