[Proposal] Ring-based Packaging Policies

[Ralf Corsepius]

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*.
Correct.

> 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 
coding quality.

Ralf