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

Bug#610292: unblock: iceowl/1.0~b1+dfsg2-1



On Sun, Jan 30, 2011 at 02:30:17PM +0100, Moritz Mühlenhoff wrote:
> On Sat, Jan 29, 2011 at 07:52:38PM +0100, Guido Günther wrote:
> > On Sat, Jan 29, 2011 at 05:48:43PM +0000, Adam D. Barratt wrote:
> > > On Tue, 2011-01-25 at 09:16 +0100, Guido Günther wrote:
> > > > On Mon, Jan 24, 2011 at 08:43:38PM +0000, Adam D. Barratt wrote:
> > > > > The main problem I'm having with looking at this is the size of the diff
> > > > > that gets introduced as a result.  Even after ignoring the test suite,
> > > > > the embedded copy of sqlite3 and the autoconf patches, I'm still left
> > > > > with
> > > > > 
> > > > >  2061 files changed, 65055 insertions(+), 96419 deletions(-)
> > > > > 
> > > > > which isn't particularly fun. :-/
> > > > Yes, I agree - updating from 3.0.0 to 3.0.11 sucks but it will allow us
> > > > to track icedove's security releases from now on with minimal impact.
> > > [...]
> > > > I fully understand that making these changes that late in the release is
> > > > a bad thing but shipping unpatched xulrunner that reads external
> > > > calendar data isn't great either. If the changes are too big we should
> > > > reconsider pulling iceowl from squeeze. We could then come back with a
> > > > better synched package for wheezy.
> > > 
> > > So, I really should stop procrastinating on this. :-/
> > > 
> > > Would I be correct in assuming that even with the new upstream tarball
> > > the package would still not get official support from the security team
> > > and any required security updates would have to go via proposed-updates?
> > I'm cc'ing Moritz for his opinion on this. With the new version based on
> > the icedove tarball it would be simple enough to handle the xulrunner
> > flaws via that path.
> 
> If iceowl uses the same Mozilla code base branch as the iceweasel source
> package (which provides the xulrunner libs in Squeeze) and the iceowl
> maintainers provide packages, we can fix in security updates. Iceweasel
> updates are an order of a magnitude more critical, though.

We use the icedove tarball[1] not the iceweasel one but the effect is
the basically the same. We can reuse the security work done for icedove.
Cheers,
 -- Guido

[1] since both are based on comm-central



Reply to: