summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2011-October/008670.html
diff options
context:
space:
mode:
Diffstat (limited to 'zarb-ml/mageia-dev/2011-October/008670.html')
-rw-r--r--zarb-ml/mageia-dev/2011-October/008670.html166
1 files changed, 166 insertions, 0 deletions
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 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Mageia-dev] About syslinux &amp; libpng
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20About%20syslinux%20%26%20libpng&In-Reply-To=%3C1317944670.3954.131.camel%40akroma.ephaone.org%3E">
+ <META NAME="robots" CONTENT="index,nofollow">
+ <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <LINK REL="Previous" HREF="008652.html">
+ <LINK REL="Next" HREF="008672.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Mageia-dev] About syslinux &amp; libpng</H1>
+ <B>Michael Scherer</B>
+ <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20About%20syslinux%20%26%20libpng&In-Reply-To=%3C1317944670.3954.131.camel%40akroma.ephaone.org%3E"
+ TITLE="[Mageia-dev] About syslinux &amp; libpng">misc at zarb.org
+ </A><BR>
+ <I>Fri Oct 7 01:44:30 CEST 2011</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="008652.html">[Mageia-dev] About syslinux &amp; libpng
+</A></li>
+ <LI>Next message: <A HREF="008672.html">[Mageia-dev] About syslinux &amp; libpng
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#8670">[ date ]</a>
+ <a href="thread.html#8670">[ thread ]</a>
+ <a href="subject.html#8670">[ subject ]</a>
+ <a href="author.html#8670">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Le jeudi 06 octobre 2011 &#224; 10:54 +0200, Erwan Velu a &#233;crit :
+&gt;<i> I think part of the point I noticed didn't got understood/seen by
+</I>&gt;<i> people answering on this topic.
+</I>&gt;<i> I'll rephrase my wondering differently.
+</I>&gt;<i>
+</I>&gt;<i> Syslinux is a modern bootloader and use some libs (a zlib, a png one,
+</I>&gt;<i> a jpeg one, maybe other ...).
+</I>&gt;<i>
+</I>&gt;<i> The patch I was talking about is about to change the png lib with the
+</I>&gt;<i> main argument about the security. A possible scenario with a png
+</I>&gt;<i> attack.
+</I>&gt;<i>
+</I>&gt;<i> My point is that if we care about the security of the bootloaders
+</I>&gt;<i> regarding this kind of scenario, our work is very partial.
+</I>
+Being unfinished and partial do not mean it should not be started.
+
+&gt;<i> If we want to stay consitent, we have to remove the jpeg lib too, the
+</I>&gt;<i> compression libs also.
+</I>
+The question is not remove, but rather &quot;not bundle a library&quot; 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 &quot;we have to maintain it and that
+take ressources&quot;, 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
+( <A HREF="http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries">http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries</A> ), 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
+).
+
+&gt;<i> And this is true about all the other bootloaders. Did someone already
+</I>&gt;<i> thought about managing the security of the builtin libs inside
+</I>&gt;<i> gfxboot ?
+</I>
+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.
+
+&gt;<i> Do we care about the gunzip code of grub ?
+</I>
+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 )
+
+&gt;<i> Being that intrusive regarding the static inclusion of this libs
+</I>&gt;<i> inside the bootloaders is just a work to report upstream and not the
+</I>&gt;<i> distro side.
+</I>
+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 ).
+
+&gt;<i> Only focusing on changing the libpng or not of syslinux isn't
+</I>&gt;<i> enough....
+</I>
+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 &quot;being enough&quot;.
+
+--
+Michael Scherer
+
+</PRE>
+
+
+
+
+
+
+
+
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="008652.html">[Mageia-dev] About syslinux &amp; libpng
+</A></li>
+ <LI>Next message: <A HREF="008672.html">[Mageia-dev] About syslinux &amp; libpng
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#8670">[ date ]</a>
+ <a href="thread.html#8670">[ thread ]</a>
+ <a href="subject.html#8670">[ subject ]</a>
+ <a href="author.html#8670">[ author ]</a>
+ </LI>
+ </UL>
+
+<hr>
+<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
+mailing list</a><br>
+</body></html>