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

[Grzegorz B. Prokopski]

W li=B6cie z sob, 31-07-2004, godz. 05:42, Steve Langasek pisze:=20
> On Wed, Jul 28, 2004 at 01:36:48PM -0400, Grzegorz B. Prokopski wrote:
> > On Wed, 2004-07-28 at 11:24, Daniel Urban wrote:
>=20
> > > > > If this would happen I am not so sure about the usefulness of t=
he
> > > > > firebird2 naming.
>=20
> > > > Maybe we can rename it to firebird later, but I am not sure what=20
> > > > reflections a rename will have right now, before sarge release.
>=20
> > > I'm for renaming firebird2 to firebird.
> > > Could we do it now? Greg? Would be a problem with it now?
>=20
> > Yes, it would be.  But really, there's no point doing that.
> > Having it as a separate package gives us more flexibility:
>=20
> > * we would be able to push old fb into Sarge (i.e. with *big* securit=
y
> > warning and access allowed only from localhost, etc.) if we didn't
> > have fb2 in time (mind you, fb2 debs are NOT in testing yet and they
> > haven't had really wide testing as they only just hit unstable).
>=20
> I'm sorry, but shipping a package with known exploitable security holes
> in sarge is not an option.

In general - yes.  But given how and what firebird is used for - I dare
to disagree.  Firebird is not ftp or http server to which whole internet
has access.  Rather the opposite.  The usual usages can be i.e. running
an application on client workstations on local, trusted network, that
connect to separate machine which runs firebird.  Or you have a web
application (think: PHP) that often runs on the same host.

But please, I would NOT want to spend resources discussing it currently.
If everything goes fine, and so far it goes really well, we should have
firebird2 in Sarge and old firebird removed from testing/Sarge.  This
will automatically resolve all discussion about security of the old
firebird packages.

> If no one is able to fix the security
> problems in the firebird server package (and I assume no one is, since
> this bug has been open so long), then the firebird server package will
> have to be removed from sarge -- along with all other binary packages
> from the same source, as well as all other binary packages depending on
> these packages.

> > This is a common practice that you add a release number to the packag=
e
> > name when you want to keep the old version around for users that migh=
t
> > need it.  Just see the output of 'apt-cache search tk8'.
>=20
> I don't know that a comparison with a scripting language is the best
> one, here.  And the value of helping users keep remotely-exploitable
> software on their systems is definitely questionable.
>=20

I think you yourself suggested that we could simply package libraries
for firebird, not the (exploitable) server.  This is yet another reason
to package firebird2 separately.  Mind you that fb2 is not yet in
testing and even though Daniel did marvelous job prepearing these
packages and fixing every single problem that was reported - we cannot
yet be sure that the packages that will hit testing around monday
will not contain yet some problems.  Given that, it was much better
to package firebird 1.0.x and firebird2 separately as this gives us
much greater flexibility.  And we definitely want to have some form
of firebird available for Sarge and surely we don't want to remove
from Sarge all packages that need firebird libraries.

> 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:
>=20
> $ 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
> $
>=20
> 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.

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.

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.

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

Cheers,

				Grzegorz B. Prokopski

--=20
Grzegorz B. Prokopski      <gadek@debian.org>
Debian GNU/Linux           http://www.debian.org
SableVM - LGPL'ed Java VM  http://www.sablevm.org
Why SableVM ?!?            http://devel.sablevm.org/wiki/Features