Bug#251458: [Pkg-firebird-general] Re: Bug#251458: firebird: remote vulnerability

[Steve Langasek]

--MET8MpPxp2u2c48q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 31, 2004 at 12:43:16PM -0400, Grzegorz B. Prokopski wrote:

> > I see from the latest firebird2 upload that the library packages now
> > provide: libfirebird and libfirebird2.  But the following is not
> > appropriate in *any* library package:

> > $ dpkg -c libfirebird2-classic_1.5.0-1_i386.deb |grep /usr/lib/libgds
> > lrwxrwxrwx root/root         0 2004-07-19 05:27:21 ./usr/lib/libgds.so =
-> libfbembed.so.1.5.0
> > $

> > I have checked php4-interbase, and confirmed that the soname this file
> > looks for is "libgds.so".  This means that there is no support
> > whatsoever for rebuilding software against a new version of libgds,
> > without breaking other programs that use the old version.  This is a
> > truly horrid setup, and I would strongly recommend that you rebuild all
> > of the firebird client packages prior to sarge's release so that they
> > will have a proper dependency on libfirebird2 and you can drop the
> > libgds.so symlink.
>=20
> I let the more knowledgable people speak here, but AFAIR:
> 1. the library has rather stable API (for ex. applications that linked
> against libgds.so coming from fb1 should work w/ libgds.so from fb2)
> 2. pretty much all existing applications expect libgds.so to exist
> (even if I strongly agree this looks terribly) and they link against it.
>=20
> Apparently upstream has done the first steps to remove this situation
> by providing properly versioned library version and keeping the symlink
> as backward compatibility option only.  But this will take a while
> before developers will actualy start using the versioned lib name.
> I really don't think we should make using firebird in Sarge such painful
> experience for our users.  Currently 99% of the software they might ever
> want to compile against firebird libraries will look for the .so file
> only.

If they are *compiling* software, then they install the dev package.
*All* applications that are being compiled look for only the .so file;
but a properly implemented shared library will provide a versioned
SONAME for use at runtime.

If they have pre-compiled applications that reference libgds.so, then of
course the symlink must be there.  Personally, I think it would be
better to include this symlink in a -compat package, however.

> > (BTW, where does the "2" in "libfirebird2" come from?  This is not the
> > soversion of either of the libraries contained in this package.)

> The goal of firebird 1.0.x was to get something usable from the original
> interbase 6 beta code, while the "new" firebird was supposed to have
> significant changes like usage of C++ and development of truly new
> features.  Therefore the new firebird was started to be reffered to as
> firebird2.  The 1.5 version is IIRC something in between.  Still
> compatible with firebird 1.0.x series, but already containing all
> the newest developments.  The 1.5 version might be viewed as something
> like deep-pre-2.0.

The names of library packages should be related to the soversion of the
libraries they contain, not to some upstream notion of the software's
version number.  What will you name these library packages when
libfbclient.so.2 is released?

--=20
Steve Langasek
postmodern programmer

--MET8MpPxp2u2c48q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDCxxKN6ufymYLloRAmNuAJ4ozyvcRXO7FCOHlYkzXOSC64jc5ACdEidL
70cqp6TBUD/0Wn+PYFgunMc=
=OiMs
-----END PGP SIGNATURE-----

--MET8MpPxp2u2c48q--