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

[Jonas Meurer]

Hey,

On 15/05/2011 Henrique de Moraes Holschuh wrote:
> On Mon, 16 May 2011, Christoph Anton Mitterer wrote:
> > With the most recent upload (and this is the very reason why I've reopened
> > the bug), you can have the situation (package removed but not pruged) where
> > you say:
> > /etc/init.d/cryptdisks stop
> > and it gives you just $? = 0, as /lib/cryptsetup/cryptdisks.functions is
> > gone.
> 
> A package is, as a general rule, not supposed to allow itself to be removed
> with the initscript indicating a failure state in the first place.  There
> are exceptions, but I cannot see why cryptsetup would be one.

I think that one is the trouble spot. Christoph doesn't agree with the
way, Debian manages initscripts. They're handled as conffiles by dpkg,
and for that reason aren't removed at 'apt-get remove', only if the
package is purged. For that reason, the situation that initscripts are
still around but the daemon/application they start/stop/whatever isn't,
is quite common. And it would be absurd if initscripts would exit wit $?
!= 0 in that case.

In case that this needs to be discussed, we should discuss the reasons
why initscripts are treated as conffiles in the first place, instead of
discussion symptoms of this decision.

> > If you're someone who (seriously) wants to do disk encryption, than
> 
> Then you'd better know the real limits of the system you're using, and you'd
> better know how to use it properly in the first place.

I fully agree with Henrique here. My opinion is as simple as: If people
want do do something called serious, then they _really_ should know what
they're talking about. And if these people do remove a package from
their system, they should _not_ assume that it's functionality is still
provided.

> > [0] And we shouldn't exclude "end users" without deeper knowledge from
> > having a "secure as possible system" if they can get if "for free".
> 
> End users without training will screw it up _every_ _time_.  Or they will be
> extremely easy prey to social engineering.  It amounts to the same thing.
> 
> You have to actually design a system to be impossible to be used insecurely
> in the first place for it to even last for a small while in the hands of
> someone without a clue.  Debian is not that system.  Nor is your PeeCee
> something that could be turned into such a system through the operating
> system only.

Full ACK. Christoph, I guess that this is the argument I should have
used ealier.

> I tire of this thread.  There are apparently bugs in the initscripts, well,
> if that's correct, just get them fixed.  Then, the package will not allow
> itself to be removed with crypt disks still active in the first place.
> 
> It'd have to switch to 'restart only _after_ upgrades, but stop on removal'
> logic, though.  And 'restart' will probably have to mean 'open any crypto
> disks that are not currently open, close any that are not supposed to be
> open anymore'.  Or maybe 'do nothing'.

Did I get you right that you suggest to start/stop/restart the
cryptdisks initscript in the debian maintainer scripts? Actually I don't
like that idea much. Most unlocked encrypted devices will be busy anyway
because being mounted while the system is running. And it's not the job
of debian maintainer scripts to unlock manually locked devices, or to
lock devices that are unlocked but not in use.

Appart from the general discussion about treatment of initscripts (see
above), I only see one point that's worth being discussed:

Is it appropriate to warn admins about unlocked devices when the
cryptsetup package is removed/purged? I still don't see the point, but
would be ok with adding a warning to prerm if people mind about it.

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/20110517/8217de37/attachment.pgp>