#218 Should we require the kernel to note bundled libs?
Closed: Fixed None Opened 11 years ago by toshio.

We've already decided that the kernel can bundle pretty much anything it wants because it doesn't have access to those libraries in userspace. However, in looking at adding the bundled(zlib) virtual provide that we say we require of it, I discovered that it has a lot of bundled code in linux-3.6/lib.

All of the code I looked at is heavily modified from the original (the kernel is concerned with speed and memory footprint and can make assumptions that the original source of the code might not be able to).

Do we want to require bundled(Foo) for some of these things? The rationale for the virtual provides is that when a security issue or other major problem arises in the upstream source for the code, we can easily search for consumers of that code with a simple repoquery. With things as heavily modified, with large swathes of code from the various upstreams removed, as they are, I'm not sure how helpful this is for the kernel's case.

I can see two options:

  1. Keep the virtual provide for "bundled(zlib)" and add more for others where it would be useful for the kernel maintainers to know about security issues in the upstreams for the bundled code. xz and lzo might fit this. I saw pieces adapted from gzip and gnupg as well, but the amount of stuff removed makes me feel that many of the security issues against those programs will likely not apply to the code in the kernel.

  2. Drop the virtual provide altogether for the kernel. I'll modify the bundled library guideline to note that the kernel has a blanket exception for libraries and doesn't need to have virtual provides because the sources it imports have been gutted and changed to the point that the code is evolving independently.

CC'ing jwb so he can tell us whether it's at all helpful for the kernel maintainers to be notified when security issues in any of these upstreams are reported.


Thanks for CC'ing.

At the moment, I'm not sure it's worthwhile but I'll discuss it with the kernel team in depth and get back to you.

After discussion this morning, the kernel team doesn't see much value in adding the virtual provides here. More often than not, the bundled source is heavily modified and stripped down to the bare minimum and really doesn't reflect the upstream of the projects in question at all. Additionally, the kernel is rather well taken care of on the security front as it is one of the more heavily scrutinized and tracked projects out there for obvious reasons. We'd prefer option 2 be taken for the kernel package, please.

It's worth noting that we do ship some userspace components as subpackages from kernel.spec (perf and kernel-tools). I don't believe anything is currently bundled in those, but in the event something is we can add the virtual provides to the subpackages.

Replying to [comment:3 toshio]:

Here's a draft that implements option 2:

https://fedoraproject.org/wiki/User:Toshio/No_Bundled_Libs_(kernel)

And the diff so you can easily see what's changed:

https://fedoraproject.org/w/index.php?title=User%3AToshio%2FNo_Bundled_Libs_%28kernel%29&diff=305698&oldid=305691

That looks great Toshio. Thanks.

Added the wording:

"The kernel maintainers are free to add virtual provides if they think it would be helpful to track security issues in the code in question but this is left to their judgement."

And asked the kernel team to consider floating the idea of a Documentation/forks file upstream.

With that change and note, this was approved:

(+1: 8, 0:0, -1:0)

Text for release announcement:

The FPC considered whether it made sense to require the kernel to use Virtual Provides to list the libraries that it bundled. It was decided that the changes which normally occur to a codebase when it is bundled into the kernel and that code's subsequent evolution makes it unhelpful in general for the kernel to be notified when something happens to the package on which that code was based. As such, the Virtual provides are no longer required for the kernel.

Login to comment on this ticket.

Metadata