Re: The "zlib bug"

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> > In the transport draft, Section 4.2, do we need a comment
> > about the zlib bug? (If I remember the discussion correctly,
> > zlib as implemented in existing SSH servers isn't really
> > zlib as defined in RFC1950 and RFC1951)
>
> What zlib bug are you referring to here?

Alok,

Unfortunately, I'm not terribly familiar with the
issues, I just remembering it being talked about.

The issue was raised by Wei Dai back in January
when we were aiming for last call then.

> I raised an issue several months ago that I don't think ever got resolved.
> The issue is how to define "partial flush" of the zlib compressed data
> stream. I think the current definition is ambiguous, but I'm not sure how
> to fix it. The problem is that there is a bug in the current zlib library
> which requires more bits (consisting of empty blocks) to be outputed in a
> flush than is necessary. If we were to define "partial flush" in the most
> natural way (i.e. not taking into account this bug), someone may create an
> secsh implementation that's not compatible with any secsh implementation
> based on the current zlib.
>
> I've reported this bug to the zlib maintainers, and they've promised to
> fix it in a future release. Do we want to maintain backwards compatibility
> and define "partial flush" in a way that satisfies the current buggy zlib?

He proposed some text for the drafts:

> Here are my suggested definitions. First the non-compatible version, which
> you may consider for "zlib-2". (An implementation that supports "zlib-2"
> can also easily support "zlib" so it may be a good idea to have both.)
> This definition has the advantage of being simpler and saving a few bytes
> per packet:
>
> A partial flush means that the current compressed block is ended and all
> data will be output. If the current block does not end on a byte boundary,
> an empty block is added to fill up the last byte.

He also proposed text for a compatible version, and later
revised it to:

> A partial flush means that the current compressed block is ended and all
> data will be output. If the current block is not a stored block, one or
> more empty blocks are added after the current block to ensure that there
> are at least 8 bits counting from the start of the end-of-block code of
> the current block to the end of the packet payload.

Bill Sommerfield weighed in with:

> Ok.
>
> [WG chair hat on]
>
> I'd like to treat this as two separate issues:
>
> 1) we don't accurately describe what's on the wire (due to the zlib
> bug).
>
> This is serious and (IMHO) warrants a fix to the current drafts.
> (noting the zlib bug).
>
> 2) we could do better on the compression.
>
> One of my alter egos is a performance tweaker, so fixing this (by
> creating an alternate zlib-2 compression method) has a definite
> appeal.
>
> At this stage in the game (for Proposed Standard), it's OK to toss in
> new features without implementation experience, but I don't think we
> want to delay the drafts until we get consensus on zlib-2; it might
> also be wise to wait until someone plugs the new zlib release into a
> secsh implementation before defining "zlib-2".
>
> So, what we can do is create a separate zlib-2 draft, and when that
> gets suitably mature fold that into the transport draft..
>
> Comments?

Hopefully, that reviews all the issues sufficiently.

I think the whole thread is probably available in the archives.

Joseph Galbraith
galb-list%vandyke.com@localhost