Bug 821776

Summary: libvirt: Gnulib bundled but no bundled(gnulib) provides
Product: [Fedora] Fedora Reporter: Mikolaj Izdebski <mizdebsk>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 17CC: berrange, clalancette, crobinso, dougsland, itamar, jforbes, jyang, laine, libvirt-maint, rjones, veillard, virt-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-30 22:05:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mikolaj Izdebski 2012-05-15 13:55:44 UTC
A bundled copy of Gnulib - The GNU Portability Library [1] was found in
libvirt. No Bundled Libraries section [2] of Packaging guidelines
gives more information on bundled libraries and how they should be handled.

Affected libvirt version: libvirt-0.9.11.3-1.fc18

As a kind of copylib, Gnulib has been granted an exception. However, to comply
with Packaging guidelines, packages bundling Gnulib must note that the library
has been granted an exception in the spec file comment with a link to the FPC
ticket where the exception was granted and add a virtual provide to the spec
file to note that Gnulib is bundled. Refer to [2] for more details.

No comment about bundling Gnulib and no virtual provide were found in the
libvirt.spec file. To comply with the packaging guideliness please
add an appropriate comment to the spec file as well as a virtual provide.

Source tarball where bundled Gnulib was found:
    libvirt-0.9.11.3.tar.gz

At least the following files look like Gnulib files:
    ./libvirt-0.9.11.3/gnulib/m4/00gnulib.m4
    ./libvirt-0.9.11.3/gnulib/tests/gnulib.mk
    ./libvirt-0.9.11.3/gnulib/tests/Makefile.in
    ./libvirt-0.9.11.3/gnulib/m4/gnulib-comp.m4
    ./libvirt-0.9.11.3/gnulib/lib/gnulib.mk
    ./libvirt-0.9.11.3/gnulib/lib/Makefile.in

There are most likely more Gnulib files bundled in the SRPM. I didn't bother
to list them all as it shouldn't be necessary.


[1] http://www.gnu.org/software/gnulib/
[2] http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Comment 1 Daniel Berrangé 2012-05-15 14:03:45 UTC
As per the very URL you quote, any package containing gnulib automatically has an exception without needing an explicit grant.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions

Comment 2 Mikolaj Izdebski 2012-05-15 14:23:30 UTC
True, but it doesn't exempt packagers from adding "Provides: bundled(gnulib) = version", does it?

If for example a critical bug is found in Gnulib, one could easily check where it's bundled and what version:
  repoquery --whatprovides bundled\(gnulib\)
and fix the bug in all packages. Otherwise 

Gnulib is used in many core packages and identifying them is important to fix bugs quickly to prevent zero-day exploits after bugs in Gnulib are disclosed.

Comment 4 Richard W.M. Jones 2012-05-15 16:01:18 UTC
I'm unclear what the 'version' should be.  Obviously the
libvirt patch above doesn't include a version, and
gnulib isn't versioned afaik.

Comment 5 Daniel Berrangé 2012-05-15 16:06:15 UTC
I omitted version because there are no version numbers associated with gnulib & simply checking a version number is a really bad way of assessing whether code is vulnerable to a security issue.

Comment 6 Mikolaj Izdebski 2012-05-15 16:11:18 UTC
Some other packages use checkout date as version, eg:
  $ repoquery --repoid rawhide --provides gdb | grep gnulib
  bundled(gnulib) = 20120120
  $ repoquery --repoid rawhide --provides liblouis | grep gnulib
  bundled(gnulib) = 20091111
  bundled(gnulib) = 20091111
  $ repoquery --repoid rawhide --provides insight | grep gnulib
  bundled(gnulib) = 20120403

Comment 7 Daniel Berrangé 2012-05-15 16:14:16 UTC
At least in the GDB case that date is meaningless since it is the checkout date of the GDB tar.gz which is little relation to the version of gnulib. In addition just the date does not uniquely identify the gnulib changeset. I think using a date here does more harm than good

Comment 8 Richard W.M. Jones 2012-05-15 16:22:04 UTC
I have to agree with Dan here.  I'd go further and say that
since we have a tool that identifies copied code, we shouldn't
need to mark bundled libraries at all: we could automatically
detect non-whitelisted ones (which presumably you're doing
already), and automatically determine cases of insecure code.

Comment 9 Fedora Update System 2012-06-19 15:44:43 UTC
libvirt-0.9.11.4-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/libvirt-0.9.11.4-2.fc17

Comment 10 Fedora Update System 2012-06-20 19:23:59 UTC
Package libvirt-0.9.11.4-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-0.9.11.4-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9708/libvirt-0.9.11.4-2.fc17
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2012-06-28 14:05:45 UTC
libvirt-0.9.11.4-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/libvirt-0.9.11.4-3.fc17

Comment 12 Fedora Update System 2012-06-30 22:05:05 UTC
libvirt-0.9.11.4-3.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.