diff options
author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
---|---|---|
committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/2011-October/008670.html | |
parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip |
Diffstat (limited to 'zarb-ml/mageia-dev/2011-October/008670.html')
-rw-r--r-- | zarb-ml/mageia-dev/2011-October/008670.html | 166 |
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 & 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 & 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 & 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 & libpng +</A></li> + <LI>Next message: <A HREF="008672.html">[Mageia-dev] About syslinux & 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 à 10:54 +0200, Erwan Velu a écrit : +><i> I think part of the point I noticed didn't got understood/seen by +</I>><i> people answering on this topic. +</I>><i> I'll rephrase my wondering differently. +</I>><i> +</I>><i> Syslinux is a modern bootloader and use some libs (a zlib, a png one, +</I>><i> a jpeg one, maybe other ...). +</I>><i> +</I>><i> The patch I was talking about is about to change the png lib with the +</I>><i> main argument about the security. A possible scenario with a png +</I>><i> attack. +</I>><i> +</I>><i> My point is that if we care about the security of the bootloaders +</I>><i> regarding this kind of scenario, our work is very partial. +</I> +Being unfinished and partial do not mean it should not be started. + +><i> If we want to stay consitent, we have to remove the jpeg lib too, the +</I>><i> compression libs also. +</I> +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 +( <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 +). + +><i> And this is true about all the other bootloaders. Did someone already +</I>><i> thought about managing the security of the builtin libs inside +</I>><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. + +><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 ) + +><i> Being that intrusive regarding the static inclusion of this libs +</I>><i> inside the bootloaders is just a work to report upstream and not the +</I>><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 ). + +><i> Only focusing on changing the libpng or not of syslinux isn't +</I>><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 "being enough". + +-- +Michael Scherer + +</PRE> + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="008652.html">[Mageia-dev] About syslinux & libpng +</A></li> + <LI>Next message: <A HREF="008672.html">[Mageia-dev] About syslinux & 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> |