[CentOS-devel] iptables-devel in centos 4.4

Thu Aug 24 21:02:11 UTC 2006
R P Herrold <herrold at owlriver.com>

On Wed, 23 Aug 2006, Karanbir Singh wrote:
> Matthew Miller wrote:
>> it's "updated to new snapshot, altering about 100,000 lines 
>> of code". Which is it in this case?
>>
>> If it's nearer the former, Milan's request that the newer 
>> compiler be used because it fixes a known and serious 
>> problem seems quite reasonable.
> here is the changelog:

Let's see what the changes were .... I think it is undecidable 
as to the matter of 'reasonableness', in doing a postmortem

> * Tue May 23 2006 Jakub Jelinek  <jakub at redhat.com> 3.4.6-3
> - -fvar-tracking fixes needed for SystemTap (BZ#2438)

 	- not clear which BZ is referred to, but it is not the 
Red Hat one; not in the Cygwin one 
(http://www.cygwin.com/bugzilla/), not in the Gnu one 
(http://gcc.gnu.org/bugzilla/)

> - add workaround for buggy programs that link in their own unwinder
>  and reexport it (#192814)

 	- probably the Red Hat bugzilla, but bug 192814 is 
blocked from review by 'mere mortals' in the general public -- 
This implies a security related matter, which are 
definitionally important changes

> - make all globals in libgcc_eh.a hidden, so that newly (incorrectly)
>  linked programs can't reexport the unwinder

 	- no bugzilla reference as to why and what 
'incorrectly' linked programs are exporting the unwinder, nor 
why that is dangerous (rather than just wrong -- if only 
wrong, the problem is in the sources of the misbehaving 
program, and would seem to be more properly fixed there, 
unless there ARE security overtones). Is the kernel one of the 
offenders? -- One cannot say.

> - support -fno-frame-base-loclist option to prevent use of
>  DWARF2 location lists in DW_AT_frame_base value (#191041)

 	- probably the Red Hat bugzilla, but bug 191041 is 
also blocked from review by 'mere mortals' in the general public

One has to suspect that there may be dangerous behaviours 
being addressed, from the obscure Changelog backreferences.

> Matt, the point is - those changes might have implications 
> down the road - I dont have the gcc knowledge to work out 
> exactly what those issues might be - and some of them do 
> seem to have a direct impact on kernel space stuff ?

and as we see in this case, and after inspection from the 
Changelog, and the outlinks it references, that NONE of the 
underlying reasoning nor cause for the changes for that GCC 
variant may be inspected, without further study than what we 
have or can easily access.

It would take further study to reach decideability as to 
'reasonable', comparing between patched source trees of the 
GCC versions in question to even see what has changed.  As I 
recall, gcc builds part of its macro expansion set on the fly 
during the compile, and so one has to snapshot it from time to 
time as well, to see what is changing.

Matt later said:

> So, the RHSA-2006:0617-15-based kernel from yesterday is 
> built with the new gcc, and the whole conversation is pretty 
> frickin' moot.

I want also to point out that just because a person produces a 
binary variant with a header containing the string 'X', 
nothing guarantees that the compiler version you THINK 
produced that X is truly one that a later appearing X variant 
in fact produced -- one can trivially spoof such values; 
buildsystems slipstream changes all the time

... we _hope_ is is the same, we hope it is moot, but nothing 
at all says that the binary update from June was build with 
the similarly version numbered sources released in August. 
It need not even be intentional that identical number versions 
may hold varying content.  Personal buildtrees outside of a 
central buildsystem are the rule, not the exception.


>From CentOS' point of view, the most responsible way to 
proceed, is to have a reproducable course documented, and to 
follow it.  _If_ one had a formal confirmaton on a particular 
kernel's buildsystem environment (which will not be 
forthcoming), or access to the specific GCC sources known to 
have been used for the specific binary kernel variant being 
compared to, other options might exist.  The PNAELV did not 
choose to timely make available the asserted gcc variant in 
question.

A better approach, the CentOS approach: build using a 
toolchain, based on the freely reproducable sources actually 
released, and not expose that million user base to unknown 
risks with 'likely' used variants without formal provenance.

A downstream user/admin wishing to do so, and to be daring, 
may do so, as they see fit, but in turn only harm themself, if 
the decision turns out to be ill advised.

- Russ Herrold