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

instantbird: modified libpurple



Hello,
I've already written to security@debian.org a week ago and nobody
answered me, maybe here I will be luckier.
I'm trying to package instantbird [1], an instant messaging client based
on Mozilla xulrunner and libpurple.
Regarding xulrunner, upstream is using 1.9.2b1, Debian 1.9.1.5 and this
should not be a big problem.
Regarding libpurple, upstream uses a modified version and at the moment
it is not possible to build instantbird with system libpurple.
I forward you the instantbird developer explanation and Mike Hommey
point of view.

What do you think about? Can a package like this be accepted?
If you want to take a look at my package, [2]

Thanks
Gabriele Giacone

[1] http://www.instantbird.com
[2] http://mentors.debian.net/debian/pool/main/i/instantbird

-------- Original Message --------
Subject: Re: instantbird packaging
Date: Mon, 16 Nov 2009 17:13:57 +0100
From: Mike Hommey <mh@glandium.org>
To: Gabriele Giacone <losgarbo@libero.it>

On Mon, Nov 16, 2009 at 05:05:02PM +0100, Gabriele Giacone wrote:
> I've already proposed it to the developer and here the answer:
> 
> "Using a system libpurple is not likely to work. Instantbird uses a
> modified libpurple. We have rewritten the way translations,
> preferences and error messages are handled (to unify with what Mozilla
> does). The way protocol plugins are loaded is also different, all
> plugins are loaded as XPCOM binary components, so that a libpurple
> protocol plugin can be in a mozilla-style addon.
> If your real concern is about the maintenance costs of duplicating all
> the libpurple files, it may be possible to build Instantbird's
> libpurple so that it is able to load both XPCOM style purple plugins,
> and regular gmodule style libpurple plugins located in the system. I
> think this is doable with a reasonable amount of work (start by adding
> DEFINES+= PURPLE_PLUGINS in purple/libpurple/Makefile.in and see what
> you need to fix).
> Protocol plugins is probably where most libpurple security issues are
> anyway.
> Unforking completely libpurple is IMHO more work than it is worth."

On top of not being able to cope with standard libpurple plugins, that
will be a burden for security, too.

I think you should check with the security team, to see what they have
to say about it ? (I haven't checked if libpurple has a big history of
security updates)

Cheers,

Mike
.

.



Reply to: