Secure testing team - Sep 2010 - [Pkg-chromium-maint] Chromium 6 in squeeze

On Wed, Sep 1, 2010 at 4:24 AM, Giuseppe Iuculano wrote:
> Hi Release Team,
>
>
> In the next few days upstream will release chromium 6 in the stable
> channel. This means that v5 will not receive any further (security)
> update, and v6 will receive security and stability updates.
>
> I could start to backport patches, but unfortunately there are some
> important webkit security issues (SVG related) that are hard to backport
> due to at least one or two major refactoring[1] of the SVG code.
> This means that any future SVG security issue (and unfortunately they
> are frequent) will be hard to fix.
Is this a supportable approach?  Once google discontinues version 6
after perhaps 2 months from now (5 was only stable for two months or
less), you''re going to have to do the hard work of backports.  I think
we should be working on making a libwebkit-chrome binary package from
the webkit source so we only need to backport to one webkit codebase.

Mike

On 09/03/2010 01:49 AM, Michael Gilbert wrote:
> Is this a supportable approach?  Once google discontinues version 6
> after perhaps 2 months from now (5 was only stable for two months or
> less), you''re going to have to do the hard work of backports.
The problem isn''t backporting in general, the problem is that in
April/May there has been some major refactoring of webkit code base, and
chromium 5 uses an ancient webkit copy.

Most of the issues fixed in chromium 6.0.472.53 are known for a long
time, but they weren''t disclosed because they are unfixable in the
webkit copy of chromium 5.
>  I think
> we should be working on making a libwebkit-chrome binary package from
> the webkit source so we only need to backport to one webkit codebase.

Why? there isn''t any package that uses that webkit copy.

Cheers,
Giuseppe.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20100903/8ff6bb65/attachment.pgp>

On Fri, 03 Sep 2010 09:48:01 +0200, Giuseppe Iuculano
wrote:
> On 09/03/2010 01:49 AM, Michael Gilbert wrote:
> > Is this a supportable approach?  Once google discontinues version 6
> > after perhaps 2 months from now (5 was only stable for two months or
> > less), you''re going to have to do the hard work of backports.
> 
> The problem isn''t backporting in general, the problem is that in
> April/May there has been some major refactoring of webkit code base, and
> chromium 5 uses an ancient webkit copy.
What''s to say another refactor won''t happen in a couple
months?  Then
we''ll be in the same situation with difficult backports anyway.
> Most of the issues fixed in chromium 6.0.472.53 are known for a long
> time, but they weren''t disclosed because they are unfixable in the
> webkit copy of chromium 5.
Everything is fixable, its just a matter of how much effort is required.
> >  I think
> > we should be working on making a libwebkit-chrome binary package from
> > the webkit source so we only need to backport to one webkit codebase.
> 
> 
> Why? there isn''t any package that uses that webkit copy.
The goal there would be to make chromium use that lib instead of its
internal webkit copy; and thus only need to support security backports
for one webkit source package.

I don''t disagree with uploading version 6, I just think we need to find
a way to merge codebases to get things into a supportable state.

Best wishes,
Mike

On Thu, Sep 02, 2010 at 07:49:21PM -0400, Michael Gilbert
wrote:
> On Wed, Sep 1, 2010 at 4:24 AM, Giuseppe Iuculano wrote:
> > Hi Release Team,
> >
> >
> > In the next few days upstream will release chromium 6 in the stable
> > channel. This means that v5 will not receive any further (security)
> > update, and v6 will receive security and stability updates.
> >
> > I could start to backport patches, but unfortunately there are some
> > important webkit security issues (SVG related) that are hard to
backport
> > due to at least one or two major refactoring[1] of the SVG code.
> > This means that any future SVG security issue (and unfortunately they
> > are frequent) will be hard to fix.
> 
> Is this a supportable approach?  Once google discontinues version 6
> after perhaps 2 months from now (5 was only stable for two months or
> less), you''re going to have to do the hard work of backports.  I
think
> we should be working on making a libwebkit-chrome binary package from
> the webkit source so we only need to backport to one webkit codebase.
There is absolutely no way this could technically work, except with a
whole lot of upstream*s* cooperation, a lot of work, and a whole lot of
time. Not going to happen before squeeze. I''m fairly confident this
won''t be happening before wheezy either.

Mike

On 09/03/2010 05:10 PM, Michael Gilbert wrote:
> What''s to say another refactor won''t happen in a couple
months?  Then
> we''ll be in the same situation with difficult backports anyway.
It could be, and it could not be, and in that case we will have pain for
all webkit related code, not only for chromium. But now this happened
before the release and we could fix this with chromium 6.
>> Most of the issues fixed in chromium 6.0.472.53 are known for a long
>> time, but they weren''t disclosed because they are unfixable in
the
>> webkit copy of chromium 5.
> 
> Everything is fixable, its just a matter of how much effort is required.
Ok... then s/unfixable/VERY hard to fix/

>> Why? there isn''t any package that uses that webkit copy.
> 
> The goal there would be to make chromium use that lib instead of its
> internal webkit copy; and thus only need to support security backports
> for one webkit source package.
> 
> I don''t disagree with uploading version 6, I just think we need to
find
> a way to merge codebases to get things into a supportable state.
Oh sorry, I misread your previous reply. No, this isn''t possible, see
the Mike''s answer.

Cheers,
Giuseppe.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20100903/5f4a793a/attachment.pgp>