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