American Airlines Experiences Suck
More American Airlines Experiences Suck More
First was the debacle which was a 7 hour delay getting to Nashville after a flight was cancelled. Now, at 9pm the day before my 6am flight from Nashville to London tommorrow they cancel my flight and are unable to get me to London in time for my Monday meeting. So I miss my meeting and total for the week I'll have had 18 hours of delays. Although perhaps I shouldn't blog this until I'm home as I'm still in Nashville and, nice that it is, don't want to spend another year here. So thats four out of my last six AA trips that have gone significantly wrong, and I only used AA this time because I wanted to upgrade and had miles left.
However, rant aside, this trip was all about the Red Hat Summit. I was pleasantly suprised by how smoothly it ran and how useful it was to have face-to-face meetings with some of the people I interact with daily by computer. There's a few cool things that the trip acted as a catalyst for, but you'll need to wait to find out ;) I tried to speak to many different attendees over breaks in the days, and consensus was positive with all the first-timers wishing to attend again in the future.
Whilst you could perhaps argue that users don't really care if an advisory fixes one critical issue or ten (the fact it contains "at least one" is enough to force them to upgrade), all this time the Microsoft PR engine has been churning out disingenuous articles and doing demonstrations based on vulnerability count comparisons.
So from March 2005-March 2006 we had 336 vulnerabilities with source metadata that were fixed in some Red Hat product:
111 (33%) vendor-sec 76 (23%) relationship with upstream project (Apache, Mozilla etc) 46 (14%) public security/kernel mailing list 38 (11%) public daily list of new CVE candidates from Mitre 24 (7%) found by Red Hat internally 18 (5%) an individual (issuetracker, bugzilla, secalert mailing) 15 (4%) from another Linux vendors bugzilla (debian, gentoo etc) 7 (2%) from a security research firm 1 (1%) from a co-ordination centre like CERT/CC or NISCC(Note that researchers may seem lower than expected, this is because in many cases the researcher will tell vendor-sec rather than each entity individually, or in some cases researchers like iDefense sometimes do not give us notice about issue prior to them making them public on some security mailing list)
This vulnerability was introduced into the Linux kernel in version 2.6.12 and therefore does not affect users of Red Hat Enterprise Linux 2.1, 3, or 4. An update for Fedora Core 4 was released yesterday.
For 2005, Microsoft fixed 37 critical issues with an average of 46 days from the flaw being known to the public to them having a patch available.
For 2005, Red Hat (across all products) fixed 21 critical issues with an average of 1 day from the flaw being known to the public to having a patch available. (To get the list and a XML spreadsheet, grab the data set mentioned in my previous blog and run "perl daysofrisk.pl --distrib all --datestart 20050101 --dateend 20051231 --severity C").
(The blog also looks at the time between notification to the company and a patch, whilst daysofrisk.pl currently doesn't report that, the raw data is there and I just need to coax it out to see how we compare to the 133 days for Microsoft)
But don't take my word for it, a people.redhat.com/mjc download the raw data files and the perl script and run it yourself, in this case
perl daysofrisk.pl --datestart 20050101 --dateend 20051231 --severity C --distrib rhel3
Different distributions, dates, and so on will give you different results, so you might like to customize it to see how well we did fixing the vulnerabilities that you cared about. (Zero days of risk doesn't always mean we knew about issues in advance either, the reported= date in the cve_dates.txt file can help you see when we got advance notice of an issue).