Buggy, under-maintained, not fit for main anymore; alternatives exist

Bug #1756840 reported by Dimitri John Ledkov ๐ŸŒˆ on 2018-03-19
70
This bug affects 11 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Undecided
Ubuntu Security Team

Bug Description

The preffered way to get encrypted disks, these days, is to do full disk encryption using LUKS.

If per-directory encryption is required, it is recommended to us fscrypt support in e.g. ext4.

Support for installing using ecryptfs encrypted /home has been disabled in the installers.

Please demote ecryptfs-utils to universe for bionic+

Changed in ecryptfs-utils (Ubuntu):
assignee: nobody → Ubuntu Security Team (ubuntu-security)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ecryptfs-utils (Ubuntu):
status: New → Confirmed

It is in universe now, marking as fixed released.

Changed in ecryptfs-utils (Ubuntu):
status: Confirmed → Opinion
Tyler Hicks (tyhicks) on 2018-04-03
Changed in ecryptfs-utils (Ubuntu):
status: Opinion → Fix Released

Ok but what am I supposed to do on a dual boot machine??
I cannot use full disk encryption as I have other partitions for the other OS (or can I??)

fscrypt ? where is it documented??

Seth Arnold (seth-arnold) wrote :

"Full disk encryption" doesn't actually mean the full disk -- it means a specific block device, so you could leave your NTFS partitions alone and encrypt only your ext4 partitions (and swap partitions, if you use them).

You've got two real options:

- block device encryption such as via dm-crypt or LUKS
- fscrypt front-end to filesystem-native encryption

Probably a bug report is the wrong place to learn about the alternatives. They serve different threat models and interact with the user in different ways, and one or the other may be better integrated into other tooling.

Thanks

airone (airone) wrote :

fscrypt is not yet ready. As of now, ubuntu 18.04 "LTS" does not offer encryption support for directories. Several use cases cannot be satisfied with full-partition encryption.

https://askubuntu.com/a/1031509

[Linus Torvalds' gracious mode on] Quit the corpo-crap. This is a loss in functionality. Acknowledge it, maybe do nothing about it, but don't lie telling that alternatives exist if you can't support them.

Jeremy Bicha (jbicha) wrote :

> Acknowledge it

It is acknowledged. That's why it's mentioned in the Release Notes.

David (dave400) wrote :

No way to encrypt Ubuntu AND swap file when dual-booting with Windows?

On 24 May 2018 at 22:26, David <email address hidden> wrote:
> No way to encrypt Ubuntu AND swap file when dual-booting with Windows?
>

Yes there is. Use dm-crypt / LUKS. for the partitions that are used by Ubuntu.

Dmitry Savvateev (savvdm) wrote :

> Yes there is. Use dm-crypt / LUKS. for the partitions that are used by Ubuntu.

Is it possible to do this automatically from (alternative) installer? Or should I learn to do this manually? Full disk encryption is not an option for me. I can only encrypt individual partitions.

Consider also this comment: https://askubuntu.com/questions/1029249/how-to-encrypt-home-on-ubuntu-18-04/1031509#comment1673761_1029249
It should be mentioned clearly in release notes that you can't even log into your encryptfs-encrypted home with Ubuntu 18.04.

Seth Arnold (seth-arnold) wrote :

On Wed, Jun 06, 2018 at 11:30:59AM -0000, Dmitry Savvateev wrote:
> It should be mentioned clearly in release notes that you can't even log
> into your encryptfs-encrypted home with Ubuntu 18.04.

Dmitry, if do-release-upgrade uninstalled the ecryptfs-utils package
when upgrading, please file a bug against do-release-upgrade.

Thanks

Redsandro (redsandro) wrote :

@Seth-Arnold I don't think your comment is relevant to the problem. Let expand on @savvdm Dmitry's comment, for I feel that a couple of balls were dropped, too.

Some of us have caught the habit of using a separate /home partition from the early days for the convenience of data-, settings-, and project retention. We have learned - and do so for years - that we can do a fresh install of a Ubuntu, and re-use the /home partition. When /home encryption was introduced, all we needed to do on a fresh install is use the same password, and things would be fine.

Now, without a clear warning, without a working alternative, and without an automatic conversion option, doing what we always did results in a broken/unusuable/reset home.

There's some mention of some deprecation in the release notes for the people who read those, "but surely the installer will take care of the necessary steps involved in transcoding this once promoted and defaulted feature, no?" (Spoiler: No, it does not.)

It should indeed be mentioned clearly in release notes (and in the installer imo) that you can't even log into your encryptfs-encrypted home with Ubuntu 18.04. Otherwise you'd expect something like this in the installer:

"We've detected an unsupported home encryption for user foobar. Would you like to:"

* Remove your prevous home (this will remove all your files);
* Leave your old files in the `.ecryptfs directory` for recovery purposes;
* Decrypt your previous home (all multiboot distros can use this user);
* Pick a different username (other multiboot distros can keep using this user);

Urop (urop) wrote :

I currently have several installs with encrypted homes. Today I was going to upgrade the first of them, in this case, from 17.10 to 18.04. Having one last scan of the release notes before upgrading, I spotted this issue (https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base_system_changes_since_16.04_LTS, 4th bullet). The text there makes it sound like you can no-longer setup encrypted homes using the installer... but that existing encrypted homes should continue to work fine. To be sure, I clicked through to this bug report, and read the summary. Again, there is nothing there to give any indication that existing encrypted home directory setups will be affected adversely. The following surely applies to setting up new encrypted home directories, not to upgrading setups with encrypted homes to new Ubuntu versions? "Support for installing using ecryptfs encrypted /home has been disabled in the installers." But then I read through to comment 11, and now I'm not sure.

I need certainty before I upgrade, so some clarification would be greatly appreciated.

If I upgrade a pre-18.04 system that has an existing encrypted home directory setup, will it continue to just work after upgrading, or will it be broken in some way? If the latter, what exactly needs to be done to fix this? (Also, if the latter, why on earth would you take a deliberate decision to break the systems of people using an advertised feature for years without providing a suitable upgrade path and without even properly advertising it?)

Thank you.

Chris Rainey (ckrainey) wrote :

It _WILL_ work. I've done it.

17.10 --> 18.04 _upgraded_ with ecryptfs 'home'.

Tools remain installed and unaffected.

As always: BACKUPS-FIRST !! BACKUPS-FIRST !! BACKUPS-FIRST !!

Urop (urop) wrote :

Thank you Chris. Having first checked my backup, your post gave me the confidence to start the upgrade. It was a complete nightmare. I thought my system was completely borked. The upgrade (using do-release-upgrade) froze part way through, immediately after reporting the following to the console:

Generating a new Secure Boot signing key:
Generating a 2048 bit RSA private key
....+++
..................................................................+++
writing new private key to '/var/lib/shim-signed/mok/MOK.priv'

Waited about an hour, but it was clear that it was stuck and it didn't appear than anything of significance was going on. Finally, I was forced to CTRL-C the upgrade and hope for the best. The upgrade wasn't able to restart itself because it thought something was using apt. So, I had to manually kill various processes that had locked apt, including the bionic process (which was presumably the upgrade process itself?), and was then able to get the upgrade going again... but somehow it left my system with broken dependencies.

Also the upgrade was producing extremely confusing messages such as:

The software on this computer is up to date.
There are no upgrades available for your system. The upgrade will now be cancelled.
Do you want to start the upgrade?
Continue [yN] Details[d]
> d
No longer supported: .... ecryptfs-utils ...

What does that mean? It's completed the upgrade, and it says the software is up-to-date (great!), but that is just after it has told me that there are broken dependencies that can't be resolved... So, when it says the upgrade will be cancelled, does this mean it will try to roll back the changes to recover... and what does it mean by 'starting' the upgrade, when it should have finished already... and what do the responses y and n mean in this context ... and when it says that ecryptfs-utils is no longer supported, so what? Is it planning to remove it, which I don't want, or is it just a warning? It's completely opaque, and ultimately you just have to choose y or n at random and hope for the best, and then go around the loop again when the first thing you tried results in you being presented with the same prompt after something may or may not have changed...

I was finally able to complete the upgrade, but then had to manually resolve the broken package dependencies. There appeared to be multiple problems, but I fortunately tackled what appears to have been the root cause first, which was gir1.2-freedesktop. Neither

dpkg --configure -a

nor

apt-get -f install

worked, so I had to force remove it using

sudo dpkg --remove --force-remove-reinstreq gir1.2-freedesktop

Then I reinstalled it and the packages that were removed with it to recover. I was finally able to boot into an upgraded system, enter my secure boot password and ...

it worked, *including the encrypted home*. How about that for a seamless upgrade! That was from an Ubuntu 17.10 server install, on which xubuntu-core had been installed. Let's hope the other upgrades go a bit more smoothly than that!

Chris Rainey (ckrainey) wrote :

Good work Urop and great follow-on documentation of your experiences!

Trial by fire, my friend. Truly. You have been baptized and reborn. >:-]

I hope your next upgrade(s) go smoother.

โ€œWas mich nicht umbringt macht mich stรคrker." ~Friedrich Nietzsche
["what does not kill me makes me stronger."]

Seth Arnold (seth-arnold) wrote :

On Tue, Jun 12, 2018 at 06:35:56PM -0000, Urop wrote:
> it worked, *including the encrypted home*. How about that for a seamless
> upgrade! That was from an Ubuntu 17.10 server install, on which xubuntu-
> core had been installed. Let's hope the other upgrades go a bit more
> smoothly than that!

I strongly recommend waiting on further upgrades until this python issue
is sorted out:

https://lists.debian.org/debian-devel/2018/06/msg00138.html
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1768379
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1763844

I don't know why some people hit it and other people do not. It is not
a fun one to hit. Even with a full local archive mirror and decades of
experience with Debian and Ubuntu it took me several hours to repair.

Urop, if you hit something similar but not python, please file a bug.
It'd be nice to sort out as many of these upgrade issues before 18.04.1
as we can. (If you hit py3clean / py3compile issues then a fix is probably
already in progress.)

Thanks

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers