> 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.
