User: Password:
|
|
Subscribe / Log in / New account

2 weeks isn't completely unreasonable.

2 weeks isn't completely unreasonable.

Posted Nov 6, 2008 16:01 UTC (Thu) by pflugstad (subscriber, #224)
In reply to: 2 weeks isn't completely unreasonable. by dw
Parent article: Android's first vulnerability

I totally agree, and was also my first thought on reading that 2nd to last paragraph.

I think FOSS people (and security folks especially) tend to be extremely cavalier about the whole testing and release process that most commercial programs go through. The prevailing opinion seems to be that you can just update to the latest version of the library and away you go. And, for most FOSS software, this is usually not a problem.

But for commercial products this is just not realistic. On a product as complex as a mobile phone, it was almost certainly undergoing release testing by the time the vulnerability was known and simply upgrading an internal library is not feasible at that point in time.

Now, I certainly agree that Google probably didn't handle this especially well, and their response probably made things works. A better response would have been: "whoops - okay, the current release is already in the process of going out. Please hold off disclosure until we can get an update out with the fix in it." But well, everyone makes mistakes - hopefully they'll learn from this.


(Log in to post comments)

2 weeks isn't completely unreasonable.

Posted Nov 6, 2008 19:36 UTC (Thu) by bfields (subscriber, #19510) [Link]

I think proprietary software people (and embedded folks especially) tend to be extremely cavalier about the whole support infrastucture that most FOSS programs are distributed through. The prevailing opinion seems to be that you can just keep ship one version of the software and then go away. And, for most proprietary software, this is usually not a problem.

But for products exposed to the internet, this is just not realistic. On a product as complex as a mobile phone, it should almost certainly have had a robust security triage and upgrade-distribution system in place by the time the vulnerability was known, and simply leaving a remote exploit in an internal library should not have been an option at that point in time.

2 weeks isn't completely unreasonable.

Posted Nov 7, 2008 4:33 UTC (Fri) by pflugstad (subscriber, #224) [Link]

I'm not entirely sure if you're agreeing with me, or mocking me.

Most FOSS programs don't have a support structure at all, and they most certainly do release a product and go away (or rather, move onto the next version). The most common answer to a problem is: are you running the latest and greatest. The prevailing opinion is that if you aren't running that latest, it's rarely worth the time to debug your problem. This is not necessarily a bad thing, it's a reality for situations where there is one or a few people developing or supporting a product.

And even if the problem is in the latest and greatest, bugs can still remain outstanding for weeks or months from the time of report until the time a fix is available. Just go find one of the articles here on LWN about how long it takes the distros to fix a hole. The only good thing here is that the distros are getting better - but they still take time to fix bugs and most of that time probably ends up being regression testing.

Commercial products are no better - but FOSS is no panacea here.

And as far as this particular product is concerned, the mobile phone companies are really getting into new territory here: their standard model is to release one (highly proprietary) product and and walk away - the lifetime of a stand mobile phone these days is what, 9 months? The concept of actually releasing a patch for a phone is probably pretty foreign to them.

Could Google have done better: probably - and they probably will in the future. Same for the telco. But 2 weeks from the time of being notified of a problem to the time of a patch being available is not outrageous.

2 weeks isn't completely unreasonable.

Posted Nov 7, 2008 0:02 UTC (Fri) by ewan (subscriber, #5533) [Link]

This makes no sense. OK, it's easy to see why no-one wants to ship untested code that might have bugs in, but in what world is better to ship tested code that known to have bugs in?

Probably OK is clearly better than definitely broken.

2 weeks isn't completely unreasonable.

Posted Nov 7, 2008 4:15 UTC (Fri) by pflugstad (subscriber, #224) [Link]

Software is shipped with known bugs all the time. There have even been recent articles on LWN about the kernel devs having this type of debate and what do to about it (lack of testing vs moving forward being the main argument, IIRC - not all that different than this discussion).

In this particular case, when was the flaw discovered in the underlying library, and when was this known to Google and where was the phone in the process? Given the lead time a lot of these products require (ship software to manufacture, start making and loading them onto phones, ship phones to retailers, etc), you could easily be talking months. So it's highly likely that it was not possible to actually fix the shipping Android code.

So, how long did the update process take: 2 weeks. Which, as I was agreeing with dw, is not an unreasonable amount of time in order to make sure that the new version of the library doesn't break anything (I expect regression tests on a web browser can take a while, much less on an entire mobile phone) and from there, push it through the whole carrier/telco procss.

The only real bad part is Google response.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds