the RISKS of Red Hat (as it stands)

[Tom Lord]

------- Start of forwarded message (with minor edits) -------
Date: Sat, 31 Aug 2002 11:19:59 -0700 (PDT)
From: Tom Lord <lord@regexps.com>
To: andru@CS.Cornell.EDU
cc: bfox@ua.com, lma@lmaugustin.com, tiemann@redhat.com, bruce@perens.com
CC: lord@regexps.com
Subject: RISKS of Red Hat
X-UIDL: c,!#!XlV!!#dd"!!:R!!



Andrew, you suggested or asked for a concise argument.  There's too
many things wrong here to put the whole dispute in just one argument,
but here's a good aspect to focus on:

This is just about the risks.  The complementary arguments are about
how fixing these risks can also lead to improved business models, even
if the risks never become an issue.


        1) Red Hat is the de facto controller and/or filter (for the
           business world and many individuals) of a lot of very
           important source, including many foundational components
           upon which everything else in the system depends for
           correct and secure operation (e.g., GCC).

        2) The infrastructure they have built and defend makes many
           aspects of Red Hat a black-box single-point-of-failure for
           those components, hence for everything that depends on
           them. 

           2a) One classic attack is documented in Ken Thompson's "On
               Trusting Trust" ACM Turing Award lecture.  How many of
               the world's compilations are performed by a GCC binary
               that descends from a GCC binary that originates at Red
               Hat (for example) or from a vendor compiler of a decade
               ago that nobody has the source for?  The nice thing
               about the compiler attack is that anyone with access to
               Red Hat's facilities is likely to be able to pull it
               off without being noticed.

           2b) Another classic attack centers on the idea of
               d.o.s.'ing Red Hat before launching other widespread
               attacks on sites running Red Hat.  Presumably they have
               other paths to larger customers but "2 x very weak ==
               very weak".  Other approaches, such as intensive
               background checks and access limitations on the site
               are both expensive, liability inducing, and far less
               effective than simply managing the source better.

           2c) The volume of source handled by Red Hat, divided by the
               total number of employees (nevermind engineers), is 
               absurd.   Just that metric alone should raise red flags.


Arch is a cornerstone element for an infrastruture that can eliminate
that single-point-of-failure weakness.  In addition to the raw
technology, it might help to explore how to use arch to fully
appreciate what I'm proposing -- but if your eyes simply glaze over
when I talk about patch sets or star-topology, that's a problem.

Arch isn't rocket science -- it's just good sense.  It's also a big
challenge to figure out how to incorporate it into existing businesses
gracefully.


- -t
------- End of forwarded message -------