[pkg-cryptsetup-devel] Bug#589686: Bug#589686: Bug#589641: Bug#589686: cryptsetup: split out keyscript in separate packages

[Christoph Anton Mitterer]

Dear Jonas.


On Wed, 2010-07-21 at 11:41 +0200, Jonas Meurer wrote:
> Christoph, please at least try to understand the maintainers point of
> view: you're correct, when supporting a setup within a package is easy
> to do, that should be done. and yes, that's the reasons why packages do
> exist in the first place. but that's one of the main tasks of a
> maintainer: chosing between complex packages, supporting many corner
> cases, and keeping the package simple by not supporting special setups
> out of the box.
> 
> in this particular case, the price to pay is to high in my eyes: neither
> splitting keyscripts into a seperate package, nor copying binaries from
> /usr to some place in root fs is an option in my eyes. that's the sole
> reason why i chose the option: let the admins take care on their own.
I reached 147 leaves,... than a big bird landed and I had to start again... :-(


Well look...
You know this one here is not the first "discussion" we've had.... and
as you've already mentioned you're annoyed by them and do not agree with
most of the things I've proposed or developed for inclusion.
For me on the other hand it's very frustrating, not only the time wasted
with such efforts, but especially the fact that improvements in code or
documentation (see the check-scripts), improvements in functionality
(OpenPGP key scripts), stronger security problems, or bugs (e.g.
that /usr/ issue here) are rejected or simply ignored or talked away by
IMHO obscure reasons.

For "simple" things which just I and perhaps some friends wanted to have
(inclusions of usable openpgp scripts) that was easy to take,... you're
the maintainer,.. you decide what goes in...

For security problems, I could at least convince you to fill some of
them (which all did not look like that big security problems on the
surface, but they actually are/were)... nevertheless even with the open
ones I had some bit of hope left, that we would finally handle them.

Atrophied documentation was already a big backlash for me, especially as
we had already some potentially security related bugs (meaning that exit
0 thingy regardless of any errors) which may have resulted from not
strict enough documentation in the code, why something is done that way.

And I guess things like that we always restrict everything quite
painfully, like the /usr on non-root-fs issue... or that we cannot agree
on allowing a "configuration framework" for the keyscripts in
crypttab... are also big motivation killers.

Last but not least,... it does not seem to me, as if there is any chance
for compromises,... which could be allowed by things like splitting such
stuff out (as asked for in this ticket).


What it all comes down to,... I guess I'll have to retreat from
cryptsetup (with respect to Debian)... it doesn't improve tattered
health either...

Guess it's pretty much useless to continue this discussion either,..
we've learned from the number of accepted patches that we have obviously
way to different opinions.
Likely even non-electronic discussion as I've offered several times,
wouldn't have helped to sort this out



Nevertheless few last comments:

> On 21/07/2010 Christoph Anton Mitterer wrote:
> > On Wed, 2010-07-21 at 01:13 +0200, Jonas Meurer wrote:
> > > the situation with keyscripts is not perfect at all.
> > Just sticking with them as it is and never allow improvement won't
> > change this however...
> right, but blowing up the current implementation is not the way to go.
Which wouldn't have happend by any of these changes (btw. neither by any
previous rejected contributions)


> > ... it would be actually rather problematic, as "normal" crypto-end-user
> > typically never see all possible implications,... I mean even we
> > don't,.. see the copy-key-to-initramfs-thingy you did, ... and I've also
> > spotted some possible security problem in my own scripts...
> Christoph, if you don't trust the local admins, then you need to
> distribute fs images which they pretty please mount read only, in order
> to circumvent any mistakes they do. you're right when trying to make the
> admins life/tasks as easy and as secure as possible, but not for any
> price.
As with so many changes,... there's a price,.. but - just
philosophically wondering - is that so high if there are people willing
to "pay" it?!


> > > either they encrypt the whole root filesystem,
> > Well that won't help,... /usr is not part of the root-fs.
> people who encrypt the root filesystem usually do have /usr on the root
> fs.
Well... but just because they must...

>  ubuntu even stopped to support sepearte /usr fs, if I remember
> correctly.
so you suggest that we should just follow that clicky-bunti toy distro
and restrict ourselfs as far as possible?


> no, the initramfs is a crafted image, it's not a directory containing
> copies of binaries. your suggestion would break intrusion detection
> systems, rootkit checkers and make it even harder for sysadmins to keep
> their system clean.
That's wrong,.. initramfs is in addition just packed and compressed....
which makes it even harder for the tools you mention... the concept is
absolutely the same...


> please elaborate. why is a gpg-encrypted keyfile more secure than a LUKS
> passphrase?
simple keyloggers spy any password entered... of course that's also true
for the encrypted key file,... but then the attacker would have just the
passphrase not the keyfile... and the passphrase on can be regularly
changed


> no, they're not. please show me the section in policy which requires a
> package to depend on all software which is needed for parituclar
> functions to work ...
"3.5 Dependencies
Every package must specify the dependency information about other
packages that are required for the first to work correctly."

Of course it's always possible to justify oneself by saying this and
that is not "core-functionality",... but IMO every functionallity is
meant here,... or at least it should be so.





Farewell,
Christoph.
-------------- 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/20100721/1728b491/attachment.bin>