From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QpLGy-0007nN-4i for garchives@archives.gentoo.org; Fri, 05 Aug 2011 14:21:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 314A6E049A; Fri, 5 Aug 2011 14:20:55 +0000 (UTC) Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com [209.85.216.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 0B64EE049A for ; Fri, 5 Aug 2011 14:19:53 +0000 (UTC) Received: by qwb7 with SMTP id 7so1182129qwb.40 for ; Fri, 05 Aug 2011 07:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GRNGEGtQq7UzExo+aCaDe6VfNfV0vS9HbUcgwVEPZ/o=; b=gOxfpnSxjh9os7U5ohctSmiLrnTlVcmj73q07kpiLnaNTE8Wmb1jjs+li/NAjagRZe U3nIdLLBE3hL0EV/+iAnN3s9IJo31hlWO0Qkuo1j6TOBfdjQLWBZBnHdbjQzk6Yhswqg Pel4vLqWcrTekZUvxIo+MRE5E+/849E+ULfWA= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.229.25.69 with SMTP id y5mr1788587qcb.23.1312553992070; Fri, 05 Aug 2011 07:19:52 -0700 (PDT) Received: by 10.229.10.209 with HTTP; Fri, 5 Aug 2011 07:19:52 -0700 (PDT) In-Reply-To: References: <4E3B6BF6.4090801@asyr.hopto.org> Date: Fri, 5 Aug 2011 10:19:52 -0400 Message-ID: Subject: Re: [gentoo-user] www-client/chromium From: Matthew Finkel To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=0016367fa12272276704a9c2cac5 X-Archives-Salt: X-Archives-Hash: 7aee7c0035d4f5580b66d17ee0d7e056 --0016367fa12272276704a9c2cac5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/8/5 Jes=FAs J. Guerrero Botella > 2011/8/5 Matthew Finkel : > > On Fri, Aug 5, 2011 at 12:05 AM, Thanasis > wrote: > >> > >> I noticed that chromium's code has a lot of vulnerabilities. > >> https://bugs.gentoo.org/buglist.cgi?quicksearch=3Dwww-client%2Fchromiu= m > >> I suppose this is why we see so often version upgrades of it (and it's > >> not a small app to build). > >> Why is its code so, should I say prone to bugs, compared to > >> other browsers? > >> > > > > Firefox isn't perfect > > either > https://bugs.gentoo.org/buglist.cgi?quicksearch=3Dwww-client%2Ffirefox&li= st_id=3D337885 > > I think you hit the nail on the head by saying that "it's not a small a= pp > to > > build". The more code that's written increases the the chances a securi= ty > > holes will be introduced into the application. > > I don't think so. It's not the raw number of source code lines which > makes it more prone to bugs. I think that a closer and more realistic > number would be the number of lines divided by the number of full-time > developers, and don't forget to put in the middle of that formula how > skilled they are. Having that into account, chromium has a good base > since few teams in the planet will have the quantity and quality of > man power that Google has to devote to this project. > > > And as an internet browser, they're also susceptible to many more vecto= rs > of > > attack than most other packages. For chromium specifically, I haven't > looked > > at the CVEs but I suspect many are for webkit and not just Chromium. > > Just my 2c. > > The webkit branch into chromium is not the same that you can find in > any other webkit-based project. They just have a common origin, but > they are maintained separately and it is my understanding that they > have diverged enough to be considered as separate things. > > -- > Jes=FAs Guerrero Botella > > Your points on code quality and developer quality/experience are well taken= , and I completely agree; the number of lines of source code is never really = a good criterion for comparison. I also wasn't aware the chromium-base and webkit-base had diverged so much. On second look of the bug reports, all of them are linked to the Google Chrome Release blog, where the vast majority of the vulnerabilities/bugs are attributed to bounty hunters. So I believe this also heavily contributes to the quick release cycle. To Thanasis' point, I think the quick release cycle is two-fold. The first being that Google has a policy of release early-release often, so I would guess that once the new feature set is stable they push it out. Second is the fact tha= t most people like using stable and secure software as well as making money. Also, quite a few of the bugs, in the Google Chrome Team's words, were "clever", so I would assume they weren't easy to find. I didn't go digging around to see how old these bugs were, to see when they were introduced, bu= t it did appear that a large portion were due to common coding error, i.e. use-after-free, memory corruption, etc. As an aside, a similar (condensed) list of vulnerabilities in all Mozilla projects can be found here [0]. I think, overall, compared to Chrome/Chromium, there are significantly less vulnerabilities reported for Firefox. But there is also far less money going towards the discoveries, as well. 0. http://www.mozilla.org/security/known-vulnerabilities/ - Matt --0016367fa12272276704a9c2cac5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2011/8/5 Jes=FAs J. Guerrero Botella <jesus.guer= rero.botella@gmail.com>
2011/8/5 Matthew Finkel <mat= thew.finkel@gmail.com>:
> On Fri, Aug 5, 2011 at 12:05 AM, Thanasis <thanasis@asyr.hopto.org> wrote:=
>>
>> I noticed that chromium's code has a lot of vulnerabilities. >> https://bugs.gentoo.org/buglist.cgi?qui= cksearch=3Dwww-client%2Fchromium
>> I suppose this is why we see so often version upgrades of it (and = it's
>> not a small app to build).
>> Why is its code so, should I say prone to bugs, compared to
>> other browsers?
>>
>
> Firefox isn't perfect
> either=A0https://bugs.g= entoo.org/buglist.cgi?quicksearch=3Dwww-client%2Ffirefox&list_id=3D3378= 85
> I think you hit the nail on the head by saying that "it's not= a small app to
> build". The more code that's written increases the the chance= s a security
> holes will be introduced into the application.

I don't think so. It's not the raw number of source code line= s which
makes it more prone to bugs. I think that a closer and more realistic
number would be the number of lines divided by the number of full-time
developers, and don't forget to put in the middle of that formula how skilled they are. Having that into account, chromium has a good base
since few teams in the planet will have the quantity and quality of
man power that Google has to devote to this project.

> And as an internet browser, they're also=A0susceptible=A0to many m= ore vectors of
> attack than most other packages. For chromium specifically, I haven= 9;t looked
> at the CVEs but I suspect many are for webkit and not just Chromium. > Just my 2c.

The webkit branch into chromium is not the same that you can find in<= br> any other webkit-based project. They just have a common origin, but
they are maintained separately and it is my understanding that they
have diverged enough to be considered as separate things.

--
Jes=FAs Guerrero Botella


Your points on code quality and developer qua= lity/experience are well taken, and I completely agree; the number of lines= of source code is never really a good=A0criterion for comparison. I also w= asn't aware the chromium-base and webkit-base had diverged so much.=A0O= n second look of the bug reports, all of them are linked to the Google Chro= me Release blog, where the vast majority of the vulnerabilities/bugs are at= tributed to bounty hunters. So I believe this also heavily contributes to t= he quick release cycle. To=A0Thanasis' point, I think the quick release= cycle is two-fold. The first being that Google has a policy of release ear= ly-release often, so I would guess that once the new feature set is stable = they push it out. Second is the fact that most people like using stable and= secure software as well as making money. Also, quite a few of the bugs, in= the Google Chrome Team's words, were "clever", so I would as= sume they weren't easy to find. I didn't go digging around to see h= ow old these bugs were, to see when they were introduced, but it did appear= that a large portion were due to common coding error, i.e. use-after-free,= memory corruption, etc.

As an aside, a similar (condensed) list of=A0vulnerabil= ities=A0in all Mozilla projects can be found here [0]. I think, overall, co= mpared to Chrome/Chromium, there are significantly less vulnerabilities rep= orted for Firefox. But there is also far less money going towards the disco= veries, as well.


- Matt
--0016367fa12272276704a9c2cac5--