Bug 821776
Summary: | libvirt: Gnulib bundled but no bundled(gnulib) provides | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mikolaj Izdebski <mizdebsk> |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 17 | CC: | 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
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 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. I'm unclear what the 'version' should be. Obviously the libvirt patch above doesn't include a version, and gnulib isn't versioned afaik. 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. 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 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 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. 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 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). 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 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. |