Security fix diffs for 2.x

[Ferenc Wagner]

"Scott Cantor" <cantor.2 at osu.edu> writes:

> Ferenc Wagner wrote on 2009-11-24:
>
>> But now I wonder why the implementations in SAMLConfig.cpp and
>> SPConfig.cpp wouldn't clash...  Shouldn't one be renamed at least?  I
>> fear these won't be usable together, but can't check it right now.
>
> They'd be in different C++ namespaces, or could be static members of
> different classes, or both.
>
>> On the practical side, it seems harder to find a good place for the
>> function definitions in the SP, because shibsp/internal.h is not
>> included by mod_apache, isapi, nsapi, and fastcgi, so they can't find
>> the declaration by default.  I've made up a new header for this purpose
>> alone, hope it makes sense, please check the attached patch.
>
> If you're ending up with a new static symbol anyway, you could just add it
> to a public header if you wanted to.
>
> Given the additional exported symbol that doesn't break the ABI (on Unix
> anyway), I think you need to adjust the soname to reflect that it's not a
> revision of the old API but an additional API superset that also supports
> the original. I think that involves changing the third number? I'd have to
> go back and check.

Hi Russ,

I wonder how you feel about the above points, especially from the
security policy point of view.  How should we best approach the security
team?  The additional exported symbol can be avoided by putting static
functions in internal.h, as shown in my first patch (and living with the
warnings).  Which is better?
-- 
Cheers,
Feri.