[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#520324: ITP: chromium-browser -- A web browser developed by Google based on the WebKit engine



On Sun, Apr 25, 2010 at 10:41:50PM +0200, Moritz Muehlenhoff wrote:
> On Thu, Apr 22, 2010 at 07:07:01PM +0200, Giuseppe Iuculano wrote:
> > Il 22/04/2010 12:25, Stefano Zacchiroli ha scritto:
> > >>> Regarding security issues, I duly notice that Giuseppe is a full member
> > >>> > > of the Debian security team, so I believe we should trust his judgement
> > >>> > > on that.
> > >> > webkit related security issues are real and I'm well placed to know about it.
> > >> > I would like to hear Giuseppe about his concerns wrt this point.
> > > Sure, I just meant to highlight that he's probably more qualified than
> > > other people (surely more than me for instance) to judge on this. I do
> > > hope he has already thought about it :), but it would indeed be nice if
> > > he can share his opinions here.
> > 
> > We are already tracking[1] chromium security issues, this is another
> > webkit fork and it is a real pain; but given the fact that now we have
> > three members in the webkit security groups (Fathi is one of them), from
> > the Security team's (CCed) point of view there is no objections.
> > 
> > 
> > Alexander Sack wrote:
> > > One example: If you look at the release channels, you will notice that
> > > there are two releases a week in average or something. Not real releases,tags
> > > or anything like that. The problem here is that chromium uses a continuous rollout
> > > and backout approach, which is fine on its own, but when it comes to reflecting
> > > this in a distro you easily become trapped to either keep up with their update
> > > frequency through the security channel :-P (e.g. going through security twice
> > > a week ;)) ... or somehow figuring how to bake stable releases from a continuous
> > > head in a way that you can release regression free security updates as those
> > > are announced.
> > > 
> > > I am not saying there is no way to do that, just that its tough and we have to
> > > learn a lot before we can consider putting chromium in a stable release for
> > > debian.
> > > 
> > 
> > After a quick look to their release blog, I noted a lot of announcement
> > for the dev tree, but not for the stable tree.
> > Anyway could you explain your plans for chromium in Debian please? When
> > do you intend to upload it in unstable or experimental?
> > 
> > BTW, yesterday I uploaded gyp.
> 
> FWIW, I concur with Alexander Sack. We should not yet include Chromium in
> Squeeze. Let's give it some time to settle down and observe if it's actually
> maintainable. The issues raised by both Alexander and Tom Callaway of Fedora
> seem very credible to me. If Chromium in Squeeze+1 can be build with the
> system copy of webkit, that's an added bonus.
> 
> Likewise, we shouldn't include libv8 yet (or exclude it from security support).

Yeah, in any case we might want to get this in experimental/unstable so we get a feeling
how this can be maintained. Also having this beast NEWed is probably a good start ;).

and yes, for now chromium-browser will use its libv8 and i dont have plans for uploading
the standalone package until that has stabilized.

 - Alexander




Reply to: