Re: Dropping 'fringe' pixbuf loaders

2015-09-24 Thread Bastien Nocera 
On Tue, 2015-09-22 at 01:20 +0200, Bastien Nocera wrote:
> On Mon, 2015-09-21 at 18:38 -0400, Matthias Clasen wrote:
> > 
> > On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi 
> > wrote:
> > > 
> > > On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor 
> > > wrote:
> > > > Do we trust this code or not? If not, we should either a)
> > > > sandbox
> > > > it or b) delete it.
> > > > 
> > > > Moving less-trusted loaders into a separate repo is a blame-
> > > > the-
> > > > user or blame-the-os-vendor move, depending on who installs
> > > > them
> > > > onto the system.
> > > The only way to prevent the blame game you mention in a typical
> > > distribution where everything is installed through packages would
> > > be to stop supporting out of tree modules entirely, if I
> > > interpret
> > > your concern correctly.
> > > 
> > > My point is that as long as that's the case, at least maintaining
> > > them in a central location gives people an aggregation point for
> > > fixes.
> > > 
> > But they are not being maintained by anybody, and the fixes have
> > not
> > been aggregating... every few years some security researchers
> > decide
> > to have a look at image loaders, and then we get a bunch of
> > overflows
> > and corruptions reported, and either me of Benjamin grudgingly fix
> > them. And both of us are tired of doing that.
> 
> I would argue that at least I have taken care of some of that work at
> the end of 2014. I didn't get to see coverity scans or cppchecks, but
> this isn't the most complicated code to fix up and review.
> 
> If removing some of those loaders helps lighten the number of
> potential
> bugs, sure, go for it.
> 
> As for removing those loaders, I'd double-check whether GIMP has
> native
> support for those (not through a gdk-pixbuf loader), so that at least
> some modicum of support is left for those, making it less likely that
> we'll crash when somebody has a duff file in their file manager.

I tested all those formats, and I think we can remove the PCX and TGA
loaders, and leave those to be loaded by GIMP, in the very short term.

For QTIF, either support in GIMP or in GStreamer (it's usually only
used along with QuickTime) would be fine.

ANI files really need to be supported by GIMP before we remove the
support for it.

In short, remove all the mentioned modules, except ANI, and file bugs
against GIMP/GStreamer for the unsupported ones.

Cheers

Supported by GIMP:
PCX [2]
TGA [2]

Unsupported by GIMP:
ANI [1]
QTIF [3]
WBMP [4] (display broken in gdk-pixbuf)
RAS [5] (broken/unsupported in gdk-pixbuf)

[1]: Tests in shared-mime-info and gdk-pixbuf
[2]: Tests in shared-mime-info
[3]: 
https://github.com/daeken/QtChaos/blob/master/Harnesses/Quicktime/Sample.qtif?raw=true
[4]: http://www.thepcmanwebsite.com/wap_images.shtml
[5]: http://samples.libav.org/image-samples/sunrast/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-24 Thread Matthias Clasen 
Thanks for the feedback.

So far, I've dropped wbmp, ras and pcx.

I've left tga because Benjamin has a branch with a rewritten loader
(hopefully more trustwrothy).
I've left qtif because I wasn't sure if this format is important on OS X..
I've left ani because it is an example of adding animation formats.

I'll look at following your recommendation for the others.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-24 Thread Petr Tomasek 
On Mon, Sep 21, 2015 at 11:28:17AM -0400, Matthias Clasen wrote:
> After several rounds of fixing overflow and allocation failure issues in
> various loaders this cycle, I'm reconsidering following the suggestion in
> https://bugzilla.gnome.org/show_bug.cgi?id=721372
> 
>   wbmp, tga, ras, qtif, pcx, ani... these are probably prime candidates for
> being removed.
> 
> Before doing so, I want to ask if anybody is willing to step up and
> maintain these loaders.  Note that even if we drop these from gdk-pixbuf
> itself, they can be maintained out-of-tree... one of the advantages of
> having loaders as modules.
> 
> Matthias
> 

Hello Matthias!

Is it possible to add such modules as "third-party" module?
If so wouldn't it just be possible to create a github repository a move
these modules there - so that users can decide if they take the risk or
not?

Thanks!

Petr

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-24 Thread Michael Natterer 
On Tue, 2015-09-22 at 01:20 +0200, Bastien Nocera wrote:
> 
> As for removing those loaders, I'd double-check whether GIMP has 
> native
> support for those (not through a gdk-pixbuf loader), so that at least
> some modicum of support is left for those, making it less likely that
> we'll crash when somebody has a duff file in their file manager.

Turning a pixbuf loader into a GIMP file import plug-in is fairly 
trivial, perhaps even into a GEGL load operation. Can you come
to #gimp for discussing this? I don't currently have time for doing
this myself, but we will definitely help whoever is interested
hacking it up.

Regards,
Mitch


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-22 Thread Matthias Clasen 
On Mon, Sep 21, 2015 at 7:20 PM, Bastien Nocera  wrote:

>
>
> I would argue that at least I have taken care of some of that work at
> the end of 2014. I didn't get to see coverity scans or cppchecks, but
> this isn't the most complicated code to fix up and review.
>
>
Yes, that is true. You have helped with maintainenance, and I should have
mentioned it. Thanks!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Bastien Nocera 
On Mon, 2015-09-21 at 18:38 -0400, Matthias Clasen wrote:
> 
> On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi 
> wrote:
> > 
> > On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor 
> > wrote:
> > > Do we trust this code or not? If not, we should either a) sandbox
> > > it or b) delete it.
> > > 
> > > Moving less-trusted loaders into a separate repo is a blame-the-
> > > user or blame-the-os-vendor move, depending on who installs them
> > > onto the system.
> > The only way to prevent the blame game you mention in a typical
> > distribution where everything is installed through packages would
> > be to stop supporting out of tree modules entirely, if I interpret
> > your concern correctly.
> > 
> > My point is that as long as that's the case, at least maintaining
> > them in a central location gives people an aggregation point for
> > fixes.
> > 
> But they are not being maintained by anybody, and the fixes have not
> been aggregating... every few years some security researchers decide
> to have a look at image loaders, and then we get a bunch of overflows
> and corruptions reported, and either me of Benjamin grudgingly fix
> them. And both of us are tired of doing that.

I would argue that at least I have taken care of some of that work at
the end of 2014. I didn't get to see coverity scans or cppchecks, but
this isn't the most complicated code to fix up and review.

If removing some of those loaders helps lighten the number of potential
bugs, sure, go for it.

As for removing those loaders, I'd double-check whether GIMP has native
support for those (not through a gdk-pixbuf loader), so that at least
some modicum of support is left for those, making it less likely that
we'll crash when somebody has a duff file in their file manager.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Matthias Clasen 
On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi  wrote:

>
> On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor  wrote:
>
>> Do we trust this code or not? If not, we should either a) sandbox it or
>> b) delete it.
>>
>> Moving less-trusted loaders into a separate repo is a blame-the-user or
>> blame-the-os-vendor move, depending on who installs them onto the system.
>>
>
> The only way to prevent the blame game you mention in a typical
> distribution where everything is installed through packages would be to
> stop supporting out of tree modules entirely, if I interpret your concern
> correctly.
>
> My point is that as long as that's the case, at least maintaining them in
> a central location gives people an aggregation point for fixes.
>

But they are not being maintained by anybody, and the fixes have not been
aggregating... every few years some security researchers decide to have a
look at image loaders, and then we get a bunch of overflows and corruptions
reported, and either me of Benjamin grudgingly fix them. And both of us are
tired of doing that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Cosimo Cecchi 
On Mon, Sep 21, 2015 at 8:28 AM, Matthias Clasen 
wrote:

> Before doing so, I want to ask if anybody is willing to step up and
> maintain these loaders.  Note that even if we drop these from gdk-pixbuf
> itself, they can be maintained out-of-tree... one of the advantages of
> having loaders as modules.
>

Not stepping up to maintain those, but I really like Emmanuele's idea of
splitting the other modules into a separate repository on git.gnome.org; I
think there is value in keeping them all in a central location.

Cosimo
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Owen Taylor 
Do we trust this code or not? If not, we should either a) sandbox it or b) 
delete it.

Moving less-trusted loaders into a separate repo is a blame-the-user or 
blame-the-os-vendor move, depending on who installs them onto the system.

- Owen

- Original Message -
> On Mon, Sep 21, 2015 at 8:28 AM, Matthias Clasen < matthias.cla...@gmail.com
> > wrote:
> 
> > Before doing so, I want to ask if anybody is willing to step up and maintain
> > these loaders. Note that even if we drop these from gdk-pixbuf itself, they
> > can be maintained out-of-tree... one of the advantages of having loaders as
>  modules.
> 
> Not stepping up to maintain those, but I really like Emmanuele's idea of
> splitting the other modules into a separate repository on git.gnome.org ; I
> think there is value in keeping them all in a central location.
> 
> Cosimo
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

2015-09-21 Thread Cosimo Cecchi 
On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor  wrote:

> Do we trust this code or not? If not, we should either a) sandbox it or b)
> delete it.
>
> Moving less-trusted loaders into a separate repo is a blame-the-user or
> blame-the-os-vendor move, depending on who installs them onto the system.
>

The only way to prevent the blame game you mention in a typical
distribution where everything is installed through packages would be to
stop supporting out of tree modules entirely, if I interpret your concern
correctly.

My point is that as long as that's the case, at least maintaining them in a
central location gives people an aggregation point for fixes.

Cosimo
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list