[Pkg-monitoring-maintainers] ganglia update for Squeeze (CVE-2012-3448)

Daniel Pocock daniel at pocock.com.au
Sun Jan 20 09:40:13 UTC 2013



On 20/01/13 10:14, Yves-Alexis Perez wrote:
> On dim., 2013-01-20 at 00:44 +0100, Daniel Pocock wrote:
>> Thanks for confirming that
>>
>> It is possible that I bootstrapped 3.1.7 on an earlier Debian version
>> than 3.1.8.  E.g. Maybe 3.1.7 was bootstrapped on lenny and 3.1.8 on
>> squeeze.  This would mean different versions of autoconf were present,
>> and each of them dumps different stuff in the source tree.
> 
> Looks possible.
>>
>> However, just excluding that change (e.g. by hacking the one line
>> change
>> into the 3.1.7 tree rather than using the whole 3.1.8 tree) doesn't
>> guarantee identical autotools behavior unless the build is done on a
>> platform equivalent to where the original 3.1.7-1 package was built.
> 
> I'd be really concerned if it'd be the case. But if you fear something

That is the case, for any autotools project: autotools is a whole world
of it's own.  For example, a newer version may build the code with
different compiler or linker flags, and this may or may not cause the
build to fail or produce a different result on some or all platforms.

In practice, people do stuff like this every day, but usually when
compiling for a single platform where they can see the results
themselves.  I just don't know if there is some more pedantic approach
to managing this type of risk for updates to stable and would appreciate
feedback on that, however...

> like that, it'd be best if you could test the package indeed fixes the
> bug.
>>
>> If we need to be that pedantic about it to put something into squeeze
>> (which may well be a good idea), then maybe we need to make the change
>> without building and releasing any of the actual binaries, just
>> release
>> the ganglia-web.deb package (which contains no binary code, just PHP).
>> Is there a workflow to do that?
> 
> No. We want minimal changes against the version in Squeeze, remember?

Minimal change would mean exactly what I described: not producing any
new binary packages for ganglia-monitor.deb, gmetad.deb, etc.  We would
only release the ganglia-web.deb binary package.

If we release all the binary packages, that means they are all
recompiled, even though none of the code in them is changing.  It is
only the PHP code that changes, and that is not compiled anyway.


> In any case, provided it actually fixes the bug, I'm ok with Salvatore
> package including only the oneliner patch.
> 
> Regards,
> 
> 
> 
> _______________________________________________
> Pkg-monitoring-maintainers mailing list
> Pkg-monitoring-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-monitoring-maintainers



More information about the Pkg-monitoring-maintainers mailing list