www/lighttpd: lighttpd won't start anymore after SSL Update in 8.1-PRERELEASE (2010-05-27 09:34:56: (network.c.529) SSL: error:00000000:lib(0):func(0):reason(0))

[Jeremy Chadwick]

On Thu, May 27, 2010 at 11:38:08AM +0300, Kostik Belousov wrote:
> On Thu, May 27, 2010 at 01:29:19AM -0700, Jeremy Chadwick wrote:
> > On Thu, May 27, 2010 at 09:39:10AM +0200, O. Hartmann wrote:
> > > Since I performed a make buildworld and installed everything and
> > > after an update of the ports tree (with which lighttpd was updated
> > > from lighttpd-1.4.26 to lighttpd-1.4.26_1 I receive this error when
> > > trying to start lighttpd:
> > > 
> > > 2010-05-27 09:34:56: (network.c.529) SSL:
> > > error:00000000:lib(0):func(0):reason(0)
> > > 
> > > Are there any suggestions/known issues/workaround or is this a
> > > serious error and should be ready for a PR?
> > 
> > I think you're correlating two things in correctly.  The OpenSSL update
> > was completely separate and unrelated to the update to
> > ports/www/lighttpd.  The version bump in ports/www/lighttpd was done for
> > an unrelated reason (to add support for TCP_NODELAY):
> > 
> > http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/lighttpd/Makefile
> > http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/lighttpd/Makefile.diff?r1=1.77;r2=1.78;f=h
> > 
> > Simply put: due to the OpenSSL upgrade, people should rebuild all ports
> > that are dependent upon OpenSSL.  If your problem persists after that,
> Do you have any factual support for your statement ?
> If it is, this is a show-stopper for the release. I believe
> OpenSSL upgrade kept ABI.

The OP's report isn't sufficient?

My thoughts, in no particular order:

The error looks to be formatted by ERR_error_string(), but who knows if
it's being populated correctly or if there isn't a bug within OpenSSL
0.9.8n itself.  One would have to review the code in network.c (and very
likely the rest of the software) to determine if SSL_get_error() is
being used correctly and the string buffer is being populated with the
correct SSL struct.

I do admit it's a little strange to see "error:00000000", but if an
underlying API function changes operationally (such as previously
returning void but now returns an int), and the software previously
built against those include headers + shared library, anything is
possible.  This is completely different than a function name going away
or disappearing from an object/library (which would be caught either
during link-time or run-time).  One would have to examine, in real-time,
the stack arguments during the call.

RELENG_8 moved from 0.9.8k to 0.9.8n.  Meaning, "l" and "m" were both
skipped, so we have to keep that in mind when reviewing the official
ChangeLog:

http://www.openssl.org/source/exp/CHANGES

I do see some changes between 0.9.8k and 0.9.8n which could warrant a
version bump.  That's my opinion anyway, but I don't know how the
FreeBSD base system maintainers for OpenSSL test things prior to
committing.  I'm betting they don't test every single FreeBSD port.

Furthermore, this wouldn't be the first time something like this has
happened with OpenSSL.

Finally, 0.9.8n came out on March 24th.  Five days later, 1.0.0 came out
and is now the official stable release:

http://www.openssl.org/source/

The ChangeLog entries between 0.9.8n and 1.0.0 are massive; a bug could
have been fixed there, which maybe only happens with lighttpd.  Who
knows.

I think the best choice of action would be for the OP to rebuild the
port and see if the problem persists.  Otherwise, spending tons of time
trying to track down the source of the problem (requiring the OP to
rebuild all of his system libraries with debugging, lighttpd with
debugging, and gain familiarity with gdb) is pointless.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |