On Mon, Mar 19, 2007 at 07:52:35PM -0600, Tony Abernethy wrote: > Lars D. Nooden wrote: > > > > On Mon, 19 Mar 2007, Dave Anderson wrote: > > > You've left out the extremely important fact that many vendors > > > interpret acceptance of blobs by any "free" OS as validating their > > > position of not releasing adequate documentation -- so accepting blobs > > > (even when "there's no other choice") actively harms the anti-blob > > > campaign. > > > > It harms more than just the campaign, it harms anyone wanting to maintain > > a modicum of options further down the road in regards to hardware > > lifecycles, operating system and kernel lifecycles, and last but not least > > security. > > > > One anecdote regarding insecurity of mysterious binaries / BLOBs: > > A local privilege escation has been known to exist, unfixed, for several > > years in nvidia's binary drivers: > > http://lwn.net/Articles/204541/ > > > > However, if you can't audit (and subsequently compile) all the code, > > including the applications, libraries, compilers and OS, then you've got > > nothing secure and nothing that can be made secure - regardless of > > anecdotes, no amount of assurances, claims, hand waving, shouting, smoke, > > noise etc. from vendors. Don't take my word for it, read what the ACM had > > to say about it: > > http://www.acm.org/classics/sep95/ > > > > But it's not just 'security' that is at risk. The lifecycle of both the > > operating system/kernel and the hardware that rely on the continued > > availability of the BLOBs become dependent on the BLOBs producers. Those > > are groups which may or may not continue to have interests and motivations > > which overlap yours. If your hardware or system needs a BLOB to run, then > > the BLOB-maker has you on a leash. > > > > Endorsing BLOBs puts *all* hardware, systems, and security at risk through > > active effort, which is reprehensible. To have one system accepting them, > > makes it all that much harder to keep them off. Think digital scab. > > > > Tolerating BLOBs or failing to eliminate BLOBs, are simply balless passive > > means of putting the above at risk. To put it another way, it's possible > > to gain control (political, economical, technical) of systems that get > > locked into BLOBs either passively or actively and encroachment into one > > system/distro can be used to marginalize the others. > > I lurk on this list and occasionally kibbitz. > Various effects make OpenBSD a very efficient leading indicator. > It works essentially thus. If the hardware gives OpenBSD trouble, it will > tend to give everybody else trouble sooner or later. > OpenBSD just finds out earlier.
The same is with software. Compiling and running on OpenBSD seems to be one method of finding bugs in programs along with electric fence etc. CL<
