[Proposal] Ring-based Packaging Policies
rc040203 at freenet.de
Fri Feb 13 15:43:53 UTC 2015
On 02/13/2015 04:13 PM, Stephen Gallagher wrote:
> On Fri, 2015-02-13 at 13:54 +0100, Ralf Corsepius wrote:
>> On 02/13/2015 10:56 AM, Petr Spacek wrote:
>> Meanwhile, we've had much more critical vulnerablities in widely used
>> libs (Remember heartbleed), which all have been quite easy to fix
>> packaging-wise. IMO, to a great portion, thanks to having mostly banned
>> static linkage and bundling.
> I'd like to point out something that I think you missed in my initial
> email. I'm not saying that anything should be allowed to bundle software
> transparently. The primary problem we faced back in '99 was that *we
> didn't know what was bundling libz*.
> With an enforced virtual Provides:
> bundled(foo) we can at least get an accurate listing of the set of
> packages that would need to be updated in the event of a vulnerability.
That's wishful thinking.
- The list of packages bundling something else is incomplete.
We know many, we likely know most, but we surely do _not_ know all.
Some sneaked-in through during reviews, some made into Fedora through
upstream updates, ....
[I just tripped over a bundled libGLEW when going after a
boost-breakdown earlier this week.
I do not want to know about the situation in java, nodejs etc.]
- Some upstreams are bundling slightly modified ("forked") versions of
other libs for different reasons (Dead/nonresponsive upstreams,
diverging attitudes on APIs, political/personal reasons, etc.), some are
bundling for "convenience". This means, in longer terms these forks will
diverge and bit-rot. IMO, these package are security risks, and should
be banned from Fedora because upstream's lack of insight.
[I know they are not in Fedora, but Handbrake and VLC's bundling of
ffmpeg would make a nice example for such questionable approach.
I am also not sure, what I shall think of those upstreams who are
bundling a modified version of libmcrypt, as we've discussed in
yesterdays FPC meeting.]
> Also, as mentioned in another thread, I'm certainly open to the idea of
> making some specific exceptions to the rule (such as "you may not bundle
> packages like libz that have a long history of vulnerability"). In other
> words, I think it might be reasonable to have bundling in the outer
> rings be a blacklist rather than a whitelist, so long as we can always
> find out with a simple repoquery what contains a package.
To me, this idea is not helpful.
All it does is to send upstreams a message which encourages to disregard
the issues of bundling, to work "dirty" and not to care about their
More information about the devel