From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-October/008670.html | 166 ++++++++++++++++++++++++++++ 1 file changed, 166 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-October/008670.html (limited to 'zarb-ml/mageia-dev/2011-October/008670.html') diff --git a/zarb-ml/mageia-dev/2011-October/008670.html b/zarb-ml/mageia-dev/2011-October/008670.html new file mode 100644 index 000000000..6b9547d66 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-October/008670.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] About syslinux & libpng + + + + + + + + + +

[Mageia-dev] About syslinux & libpng

+ Michael Scherer + misc at zarb.org +
+ Fri Oct 7 01:44:30 CEST 2011 +

+
+ +
Le jeudi 06 octobre 2011 à 10:54 +0200, Erwan Velu a écrit :
+> I think part of the point I noticed didn't got understood/seen by
+> people answering on this topic.
+> I'll rephrase my wondering differently.
+> 
+> Syslinux is a modern bootloader and use some libs (a zlib, a png one,
+> a jpeg one, maybe other ...).
+> 
+> The patch I was talking about is about to change the png lib with the
+> main argument about the security. A possible scenario with a png
+> attack.
+> 
+> My point is that if we care about the security of the bootloaders
+> regarding this kind of scenario, our work is very partial.
+
+Being unfinished and partial do not mean it should not be started.
+
+> If we want to stay consitent, we have to remove the jpeg lib too, the
+> compression libs also.
+
+The question is not remove, but rather "not bundle a library" which is
+different. IE follow the policy, because it ease update and tracking of
+security issues ( and in fact issues that are not security related ).
+
+For example, using a bundled library mean fixing the same security bug
+several time, but also the same regular bug twice, be it runtime bug, or
+just compilation problem. A library who suffer from such issues is
+ffmpeg, bundled several time everywhere ( and worst, that make no effort
+to ease the work of unbundling it ). 
+
+So far, the 2 arguments ( or at least, those that I understood ) are :
+
+- there is others problem, so why should we fix this one ?
+Which is just a bad reason. 
+
+- that's intrusive, that translate to "we have to maintain it and that
+take ressources", and I would say that maintainance would maybe less a
+issue if we pushed the change to upstream ( or at least correctly
+explain our problem with bundling library, and given similar policies
+exist for Fedora and Debian
+( http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries ), that
+should not be a too orthodox point of view . But yes, maintainance is a
+issue. 
+ 
+So again and as said before, if using libpng 1.5 is such a problem, and
+by extension any other important upgrade like gnutls 3.0 for example,
+but the same could apply to python, etc ), maybe we should decide to not
+upgrade lower level components at all until others distros did the hard
+work. Fedora would surely take care of that sooner or later, and since
+they push upstream their patches, we can just wait some months.
+
+Of course, the side effect would be to have slightly older softwares
+( which would not be so bad ), and to not attract people who like
+innovation, need newer libraries or who like to fix things ( who
+unfortunately are also the kind of people we need to do the distribution
+).
+
+> And this is true about all the other bootloaders. Did someone already
+> thought about managing the security of the builtin libs inside
+> gfxboot ?
+
+Well, since you mention it, yes, we should investigate. But I guess that
+since that's not a fun task, no one will be motivated to do it. 
+
+> Do we care about the gunzip code of grub ?
+
+Grub developpers do care of what they include, and according to the
+snapshot of grub 2 sitting on my disk, they completely forked some code
+from inflate.c dating back to 1992 to add several features. At least,
+that's the part I found about gunzip code.
+
+They also rewrote a png loader ( because they do not need write
+operation, just read ) among others. 
+
+( grub legacy being dead, no one care about anything about its code )
+
+> Being that intrusive regarding the static inclusion of this libs
+> inside the bootloaders is just a work to report upstream and not the
+> distro side.
+
+That's the job of the maintainer of the package to report the issue
+upstream. But I think upstream do not usualy have the same vision as
+distribution about this ( or he would not have bundled code in the first
+place ).
+
+> Only focusing on changing the libpng or not of syslinux isn't
+> enough....
+
+That's why I think we have a (maybe unwritten, but for sure a quite old
+) policy of avoiding bundled library and use system one instead. Several
+are unnoticed ( because people do not care about this, or because that's
+too hard and not fun ), and that's quite bad, but that's IMHO not a
+reason to deliberately do it. So that's not about syslinux and libpng
+only. 
+
+
+And if you think this is not enough, you can surely help us to get to
+the goal of "being enough".
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1