[pkg-cryptsetup-devel] Bug#585496: Bug#585496: Bug#585496: Bug#585496: cryptsetup: replace check scripts by new versions

[Christoph Anton Mitterer]

On Wed, 2010-06-16 at 20:28 +0200, Jonas Meurer wrote:
> i disagree here. good documentation at the right place is a key feature,
> especially for security software.
But right now, this is not the case


> i agree with you on that. but simple
> scripts, cluttered with tons of comment lines, which expatiate obvious
> things, repeat information which have been documented at other places,
> and last but not least make it hard to survey the script, don't help
> anybody.
I guess one can never have too much documentation,.. if anybody is not
interested in it,.. he can simply skip over it or filter it out.
For you, as you know your code quite good, it might sound stupid to
comment parts which seem simple.
But you may leave Debian and a new maintainer will have to step up,...
and he will be confronted with large amounts of code, not easily being
able to understand, especially the intentions behind all.
Guess one learns in every first-grade lecture, that even simply
functions should be fully documented including
description/parameters/returnvalues/etc.

Nevertheless, this discussion - as you already mentioned - get's lame.


> > - Not sure whether you check e.g. for the availability of blkid which is
> > nearly guaranteed to be there, but not for whether the device exists is
> > readable and a block device.
> you don't need to check for the device, as this is already done in
> cryptdisks.
But with that argumentation,.. you also don't need to check for
blkid,... it's already there; see below.

> one could argue that this check is useless as
> util-linux is essential
That's the pint,.. and IIRC, policy even mandates to e.g. not ad
dependencies on essential packages, right?
And even if it doesn't explicitly say the same for such checks, I guess
it would be in its spirit.


> you're right, it's not that hard. but nobody asked for it yet, and i
> didn't get the impression that you intend to use that feature. you just
> want it there for the sake of "completeness".
Well,.. completeness and consistency,... and it might be (in worst
cases) exploitable to not have the cecks during initramfs.


> ... and to be honest, the mail conversations with you keep me away from
> fixing other bugs, which are much more important in my eyes. but we all
> know this phenomenon called "procrastination" :-)
Uhm... well no one forces you to answer and as maintainer you can simply
recject/close any bugs or so...


> yes, and as you might have seen in svn, i completely removed the *vol_id
> check scripts from the package.
Yeah I've seen,... although I consider that the best solution (one
cannot always be backwards compatible, especially if it's so easy for
end users to get everything back)... one can argue, why you don't to
this then for ext2/xfs/swap.

Anyway,... this closes #585418 :)


> after all, i really appreciate your dedication and the intension to help
> me with the cryptsetup packages. but if you really want the packages to
> become better, you should pick some of the longstanding open bugs and
> try to reproduce and debug them, rather than starting long discussions
> about the style of keyscripts.
As I tried to describe in my offline email, I have several expectations
on a very high security grade of cryptsetup, which I do currently not
see fulfilled by either
- open issues (that "attack" thingy and the spread your keyfiles)
- in some places, to uncertain documentation or too less checks

Although the issues you mention are important ones, I consider them less
important than stuff which is potentially security relevant.


And regarding contributions, I see only limited sense in this,... if you
do, I will likely continue the style I consider to be well documented
and safe,... and you'll likely keep your objections... this both costs
us time with no benefit.
In addition, simply "ignoring" real world attacks, makes be not believe
more in cryptsetup either...
But,.. let's really stop that discussion now :)


Bye,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3387 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20100616/9c1483ea/attachment.bin>