Proposal to reduce anti-bundling requirements

Reindl Harald h.reindl at thelounge.net
Thu Oct 1 21:38:31 UTC 2015



Am 01.10.2015 um 23:27 schrieb Matthew Miller:
> On Thu, Oct 01, 2015 at 10:01:29PM +0200, Dominik 'Rathann' Mierzejewski wrote:
>>> * All packages not in the critical path whose upstreams have no
>>> mechanism to build against system libraries '''may''' opt to carry
>>> bundled libraries, but if they do, they '''must''' include {{{Provides:
>>> bundled(<libname>) = <version>}}} in their RPM spec file.
>> I strongly object to this last point. If we simply allow free bundling
>> provided that it's recorded then we're opening a can of worms each
>
> Just to be clear -- this last point is basically the entire proposal.
> It's okay to object to it, of course, but I don't think you can
> meaningfully object to just this bit alone.
>
>> having a different CVE written on their backs. A recently discovered
>> bundling of lua[2] (with an actual open CVE) in luatex (and probably
>> in many more packages) is a good example of why this is a bad idea.
>
> I take that a different way. Exactly the opposite way, in fact. First,
> it shows that the the current policy isn't working — it doesn't keep
> bundling out. Second, it demonstrates a case where it'd be better if
> the bundling had been documented, because it would have shown up in a
> query when the security team was working on that vulnerability

the last part *only* works *if* it had been documented

nothing of the whole thread solves the problem of unintentionally 
bundeling becaue missing knowledge or just not care about it

in a perfect world upsteram would not write crap which needs to be 
unbundeled as well as maintainers would not bundle withoput intemtion by 
missing knowledge - nothing of that is solved or targeted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151001/0c50b5af/attachment.sig>


More information about the devel mailing list