Removal of zlib, take 2.
abartlet at samba.org
Wed Jul 16 17:59:41 MDT 2014
On Wed, 2014-07-16 at 15:58 -0700, ronnie sahlberg wrote:
> On Wed, Jul 16, 2014 at 1:17 PM, Jeremy Allison <jra at samba.org> wrote:
> > On Wed, Jul 16, 2014 at 10:09:46PM +0200, Volker Lendecke wrote:
> >> On Wed, Jul 16, 2014 at 09:10:15AM -0700, Jeremy Allison wrote:
> >> >
> >> > They WHY is completely obvious. We DO NOT MAINTAIN THESE LIBRARIES.
> >> > They are upstream, and we need to treat them that way. Pulling in
> >> > and shipping cruft we dont' update and don't maintain has to stop.
> >> That's true. But we are mixing in a dependency on those
> >> libraries into completely unrelated components. THAT has to
> >> stop first. THEN we can talk about removing the internal
> >> copy.
> > Sure - I completely agree with that. Lessening dependencies,
> > then removing libraries that are maintained upstream of us
> > is the only sane way to keep Samba maintainable and secure
> > IMHO.
> If no one is maintaining the zlib fork or keeping it in sync with
> upstream then it should go asap.
> Looks like the zlib fork was originally release almost to the day 9
> years ago and based on the
> upstream changelog it does look like there are several changes and
> fixes that look really important.
> Forking and then abandoning the fork is like juggling handgrenades.
> Sooner or later you will miss to
> backport a really important security fix and then you have to feel bad
> for letting the users down.
I've had the chance to chat with Jeremy on the phone and examine the
OpenChange situation, and so I wanted to revise my position a little.
I would be happy with this change if we either:
- make it mandatory (while I understand Volker's position, platforms
without zlib and which can't get zlib are pretty few and far between)
- make it required for the AD DC and when we publish ndr libraries
- a patch is made like install_python.fns for the build farm, to ensure
these hosts get zlib.h:
- we resolve not to deny using other helpful external libraries, even
in the file server, just because they are external. (I do not want to
see us prefer to rewrite code internally just because it is easier than
arguing for an external dependency or bundling it).
I don't specifically mind us increasing the burden for installing Samba
on 'strange' platforms, provided we do it deliberately, carefully and
with a purpose.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical