Proposal to reduce anti-bundling requirements

Tom Hughes tom at
Fri Oct 2 14:36:27 UTC 2015

On 02/10/15 15:22, Matthew Miller wrote:
> On Fri, Oct 02, 2015 at 02:19:19PM +0200, Ralf Corsepius wrote:
>>> only for projects where upstream is fully active and cares about the
>>> security vulnerabilities in the bundled copies of software well.
>> Correct. That's one of the criteria, FPC is trying to consider when
>> granting bundling exceptions. Openly said, these are the easy cases,
>> we often grant bundling exceptions.
>> The problematic ones are those cases, when it's obvious upstream
>> lacks experience and/or technical skills to understand "unbundling"
>> /"bundling" and resources to take care about "upstreams of their
>> bundled sources. These often are smaller projects - in many cases -
>> one-man shows.
> Ralf, right now the documented list of reasons FPC might allow
> exceptions don't give this impression. The closest I see is "Active
> upstream Security Team", but that has a number of qualifications linked
> by capital-letters and bold, like "the upstream project is actively
> working on unbundling" and also notes "this rationale may not be
> sufficient in and of itself" and that this exception is likely to be
> temporary.

Well I have personal experience of FPC refusing a bundling exception 
even when the upstream of the bundled source is essentially dead and 
hence not in any position to respond to anything so I don't really buy 
it either.

I'm actually very much in favour of not allowing bundling in general and 
mostly wish we would keep the current policy.

That said I do realise it is becoming more and more of a problem and 
what I was originally seeing mostly in javascript code while dealing 
with node modules is not spreading more into C++ code and the like.

Currently the situation is such, and the (perceived) difficulty of 
getting exceptions such that I avoid even reviewing things where it 
looks likely to be an issue never mind actually packaging them myself.

Recently I even saw a case of a header only C++ library bundling another 
C++ head library which raises slightly metaphysical questions since 
dependants of a header only library need to be rebuilt when it changes 
anyway if they are to pickup security fixes. Strictly speaking that's 
even true of a more traditional library if the security fix happens to 
be in a header, but I wonder how well we pick up such things and 
propagate them?


Tom Hughes (tom at

More information about the devel mailing list