Bug#610292: unblock: iceowl/1.0~b1+dfsg2-1
On Mon, Jan 24, 2011 at 08:43:38PM +0000, Adam D. Barratt wrote:
> Hi,
>
> Apologies for the delay in getting back to you.
>
> On Mon, 2011-01-17 at 09:28 +0100, Guido Günther wrote:
> > I've moved iceowl in squeeze from the comm-zentral 3.0.0 codebase (aka
> > sunbird 1.0b1) to comm-zentral 3.0.11 (thunderbird 3.0.11). This fixes
> > quiet some security related issues in the mozilla codebase. With this
> > change made we can security support iceowl by "simply" using the icedove
> > tarball as a base since both packages are built from the same
> > comm-central repository. I tried to keep the packaging changes to a
> > minimum. Any chance we can push this into squeeze:
>
> 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.
> > iceowl (1.0~b1+dfsg2-1) unstable; urgency=low
> >
> > * [d96a5b0] New upstream version based on icedove 3.0.11 this fixes the
> > following security bugs:
>
> [chomp] How many of those bugs actually affect the version of the
> package in Squeeze, rather than being introduced as part of the upstream
> tarball switch?
Given that many bugs affect iceowl's own copy of xulrunner they are real
issues found in the code we currently ship.
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.
Cheers,
-- Guido
>
> Regards,
>
> Adam
>
Reply to: