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.
smime.p7s
Description: S/MIME cryptographic signature
