Bug 846781

Summary:	syslinux-4.02-7.el6.i686 contains embedded copies of libpng, libgcc, and zlib libraries
Product:	Red Hat Enterprise Linux 6	Reporter:	Jan Lieskovsky <jlieskov>
Component:	syslinux	Assignee:	Peter Jones <pjones>
Status:	CLOSED WONTFIX	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684253
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	846778
Clones:	846782 (view as bug list)		Environment:
Last Closed:	2013-04-01 19:55:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	846778, 846783
Bug Blocks:	846782

Description Jan Lieskovsky 2012-08-08 16:43:55 UTC

+++ This bug was initially created as a clone of Bug #846778 +++

Description of problem:
syslinux-4.02-7.el6.i686 as shipped with Red Hat Enterprise Linux 6 contains own / embedded copies of libpng, libgcc and zlib libraries. All of these libraries have their system equivalents. It is not a good practice to embed hard coded library version copy into additional source, since once security issue is found (like for example CVE-2010-0205, CVE-2010-1205 for libpng were to mention some), the package embedding vulnerable library copy would need to be updated too.

Version-Release number of selected component (if applicable):
syslinux-4.02-7.el6.i686

How reproducible:
Always

Steps to Reproduce:
1. Look into BUILD/syslinux-3.11/com32/lib/libpng or check:

# rpm -q --requires syslinux

output. 
  
Actual results:
libpng.so isn't listed in rpm output

Expected results:
libpng.so should be listed in requirements (IOW syslinux should use system version of the libpng, libgcc, and zlib libraries instead of the embedded copies)

Comment 3 David Cantrell 2013-04-01 19:55:13 UTC

This is deliberate.  Here's why:

1) these are actually versions of the libraries hacked up to run in a
   COM32 (i.e. BIOS) environment, so that's a pretty steep order.

2) nobody's going to try to root a system by replacing the png parser in
   the boot loader and then replacing the boot background image in /boot
   and using that to exploit the boot loader.  Because that's insane.
   Likewise for e.g. changing the kernel image to break the boot
   loader's zlib, or its soft float support from libgcc.