knitti wrote: > On 1/3/06, Ted Unangst <[EMAIL PROTECTED]> wrote: >> On 1/2/06, Travers Buda <[EMAIL PROTECTED]> wrote: >> > You've made it very clear that CGD won't be imported into OpenBSD, yet >> > you've never explained why, or why you ported it in the first place. >> > >> > Care to let us in on why? I expect your reply will be a short "no" just >> > like a few of your replys to this subject. For what it is worth, I'm >> > asking. >> >> Because, like everyone else, you've failed to pass the articulation test. >> http://marc.theaimsgroup.com/?l=openbsd-misc&m=112534721521131&w=2 >> > OK, I'll try, because I'd be interested in using it on OpenBSD. Since I won't > be able to do it myself, any or no answer will qualify ;) > > cgd gives users some choice over how to build their encrypted partition. > you're able to use different ciphers.
More stuff to test to make sure it works perfectly... "Knobs" are not a selling feature for OpenBSD developers (in fact, accusing someone of adding useless knobs is fighting words! :). Practically speaking, it is just something else to screw up, either in the code or in the operation. That's more likely to hurt you than a suddenly found fatal flaw in a particular encryption system. > you're able to use passphrases or keyfiles (with some tricks one could also > do this in OpenBSD, but it'd be a hack and far easier to screw up) ok, why not improve OpenBSD's solution, then? > you're able to change your passphrase without reencrypting your container. that could be nice. If there is a design reason this feature couldn't be added to OpenBSD's solution, you win a point. :) (I'll admit my crypto knowledge is very lame.). > in the unlikely case of a cipher getting broken, you have the possibility to > switch instantly, using a tool you know with stable code an the same way > you configured it. from: http://www.onlamp.com/pub/a/bsd/2005/12/21/netbsd_cgd.html?page=2 "Once I have an encrypted slice, can I switch cipher or disable cgd? RD: There is currently no way to change the encryption type of an existing partition in place." Doesn't quite sound "instant"... Which also means if you turn some of those knobs wrong, you have a lot of work to do to repair the problem... > this is the way it appears. if there are any reasons, why cgd shouldn't be > used at all I'd be more than interested to hear them. if there are any reasons > not to port this to OpenBSD, nobody will die not knowing them. That's not the way they work... OpenBSD does not have multiple mail clients, multiple network filtering solutions, multiple web servers, five different versions of 'vi', etc. The preference is for one well maintained, highly tested solution than several poorly maintained solutions, even if some of those poorly maintained solutions have small theoretical advantages... CGD would probably need to have a knock-out killer reason to import it, something to justify the effort and possible forced replacement of the existing svnd amoung users who use it, not just a few minor features that are arguably better and a number of features that are just different. If the features are better, port the FEATURES. If the design is just a little better, why not work on it a lot and come up with a CLEARLY better design? The point is to make the best possible OS, not a few good features on some poorly implemented and under-tested tools slapped together carelessly. And yes, avoiding slapping things in "because they are not horrible" is a difficult challenge. :) Nick.
