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

[Jonas Meurer]

Hey,

@debian-devel: this is about a bugreport against cryptsetup. The
submitter suggests that cryptsetup should print a warning at package
removal, that locking dm-crypt devices is no longer possible.

I rather think that this is a obvious information, and making it
explicit is not required.

On 14/05/2011 Christoph Anton Mitterer wrote:
> 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.

Ok, agreed on that.

> - 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).

While I do understand your motivation, I don't think that a warning as
removal time is appropriate. If people remove the cryptsetup package,
they should expect, that the functionality provided by the package goes
away with the package. After all they *remove* software.

I can imagine loads of software that whould have to warn the user while
being removed. This is valid for any kind of crypto applications at
least.

But let me think about it a bit. I'd love to hear a third opinion about
it. I've cc-ed debian-devel to see what others think.

Checking for unlocked dm-crypt devices at cryptsetup package removal,
and warn the user only in case s/he has open dm-crypt devices, might be
an option.

> 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).

This is a different case, as removing the running kernel and all related
kernel modules will most likely *break* your running system in a fashion
that you no longer can intervent. Thinks like a kernel panic are likely.

> 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.

I see your point. And I don't know the reasons why initscripts are
treated as config files in the first place (beside them being in /etc).
But this bugreport is not the place to discuss things like that. Raise
them on debian-devel if you like to propose a better solution.

Greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20110515/63e6058f/attachment.pgp>