Security fix diffs for 2.x

[Russ Allbery]

Ferenc Wagner <wferi at niif.hu> writes:
> "Scott Cantor" <cantor.2 at osu.edu> writes:

>> 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.

In this particular case, it isn't strictly necessary to do anything when
new calls are added but nothing is removed, but one is ideally supposed to
change the library version as follows:

  3. If the library source code has changed at all since the last
     update, then increment REVISION (`C:R:A' becomes `C:r+1:A').

  4. If any interfaces have been added, removed, or changed since the
     last update, increment CURRENT, and set REVISION to 0.

  5. If any interfaces have been added since the last public release,
     then increment AGE.

This will generate a library with a new SONAME but a different minor
revision.  However, so far as I know, nothing on Linux actually looks at
the minor revision.

In the Debian package, one should increase the dependency encoded in
shlibs so that any package built against the new ABI requires at least
that version of the library package.  This is done in the dh_makeshlibs
call.  For example:

    dh_makeshlibs -V 'libshibsp1 (>= 2.0.dfsg1-4+lenny2)'

> 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?

I think it's probably better to go ahead and export them from the library.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>