Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707

[Cyril Brulebois]

(Cc: debian-boot@ added.)

Martin Pitt <mpitt at debian.org> (2015-04-16):
> Hello release team,

(With my d-i release manager hat.)

> yesterday I discovered that systemd breaks a common way of setting up
> plain cryptsetup partitions. Turns out that this has already been
> known for a while, but the impact wasn't appreciated enough:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707
> 
> What happens is that systemd's cryptsetup integration ignores the
> "offset=" parameter in crypttab and instead uses the whole device. So
> if you had a swap or other partition underneath in order to identify
> the partition via UUID or label instead of an unreliable hardcoded
> device name, switching to systemd destroys the underlying metadata,
> and causes a boot hang as crypttab now refers to a nonexisting
> UUID/label. This is quite a common way to set up encrypted swap, the
> way that ecryptfs' own swap setup tool does it (the Ubuntu installer
> calls that if you select "encrypt my home directory"; I'm not sure
> whether Debian's installer does the same).

Grepping for hash= in partman-* d-i packages led to partman-crypto,
which seems responsible for this (no surprise here):
  http://anonscm.debian.org/cgit/d-i/partman-crypto.git/tree/finish.d/crypto_config

There's no offset= there.

Looking into partman-* in Ubuntu vivid, it turns out that one of them
look at user-setup, and that's where the following is defined:
| Template: user-setup/encrypt-home
| Type: boolean
| Default: false
| # :sl2:
| _Description: Encrypt your home directory?
`---[ debian/user-setup-udeb.templates ]---

which is then used in user-setup-apply where there's a lot more
(encryption-related) code than in Debian, which e.g. calls adduser with
an option to encrypt home, which then calls some commands from the
ecryptfs-utils package, but I don't see any offset in the
ecryptfs-setup-private script.

Anyway, asking for home encryption indeed leads to swap encryption,
through a ecryptfs-setup-swap call, which in turn triggers:
|        echo "cryptswap$i UUID=$uuid /dev/urandom swap,offset=1024,cipher=aes-xts-plain64" >> /etc/crypttab
`---[ src/utils/ecryptfs-setup-swap ]---

The same file in the Debian package has no offset, so I guess that means
Debian is rather safe.

> IMHO this qualifies as data loss, and we cannot repair this
> automatically after the damage happened. So I'd really like to fix
> this in jessie, and I upgraded it to RC.
> 
> The patch is quite straightforward. It got a first review by upstream,
> I made it a bit more defensive since the first version, and it'll
> probably land today. I attached my test script to the upstream bug [1]
> which allows you to play around with various offset= options and
> verify that it doesn't destroy the initial part of the partition.
> 
> I realize this is a somewhat awkward timing as we want to deep-freeze
> in two days, and this means an udeb change (although only formally as
> there are no effective changes in udev). 215-16 should go into testing
> tonight, and I'm prepared to upload 215-17 with that fix right after
> that with urgency=high.
> 
> What would you recommend how to proceed?

Provided a review by the release team, I'm OK with letting this go into
testing between D-I Jessie RC3 (to be released at the end of this week)
and a possible extra debian-installer upload (before the release).

I'm not exactly entirely sure how to deal with D-I for Jessie past RC3
anyway:
 - Do nothing?
 - BinNMU to make sure it's built against last-migrated components?
 - Sourceful upload in case there's any changes staged in git during the
   last week? (I hope that won't be necessary.)


Mraw,
KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150416/bc05a2cc/attachment-0002.sig>