[pkg-cryptsetup-devel] Bug#626641: Bug#626641: Bug#626641: cryptsetup: bug #587220 re-introduced

[Christoph Anton Mitterer]

On Sat, 14 May 2011 16:22:30 +0200, Jonas Meurer <jonas at freesources.org>
wrote:
> If people remove the package cryptsetup from their system, I hope they
> know what they do. And I hope that they don't remove the package in case
> that they still need it.
> 
> Once the cryptsetup package is removed, they will not be able to setup
> and/or unlock encrypted dm-crypt devices anyway.
> 
> And if people really remove the cryptsetup package and still expect its
> initscript to work afterwards, we really cannot help them.


I don't think that's the appropriate way to solve this... so I'd suggest
the following compromise:

- We agree that it's fine to "break" if people are stupid and delete the
cryptdisk.functions.

- But if the package is installed and removed (but not purged) some
additional caution should be taken. I'd suggest using e.g. debconf (with a
priority of "high", to warn that cryptdisks are still open (if any) any
might not be closed anymore correctly afterwards.
This does not only solve any meta-security issues (as people are now
explicitly warned), but it also prevents any problems of dm-crypt-mappings
that are still open any cannot be closed anymore (well at least not with
cryptsetup itself).
Perhaps specifically adding a notice there, which tells that this could be
security relevant, as the user cannot use cryptsetup to close the devices
/dev/abc ... to /dev/efg anymore (as well as scripts depending on it)....
and that he'll probably not even be noticed.

The later is IMHO good and common practise, e.g. all linux-image-*
packages warn you if you're about to remove the running kernel (and even
give you the opportunity to abort).


I guess this is a good compromise in following the debian policy, having
the best possible user experience (no situations in where he cannot close
already open devices anymore) and also warning about the fact that he might
not be able to reliably close his dm-crypt mappings.


Still I think that an exit code != 0 is the better solution,... but that's
a general problem of the way debian handles it's initscripts.


Cheers,
Chris.