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