[stunnel-users] stunnel-4.15 doesn't work on Mac OS X 10.4.6

[SUENAGA Hiroki]

Dear all,

I found a problem that the stunnel-4.15 doesn't work on
the Mac OS X 10.4.6. I think this is a BUG.

My environment is:

  - OS: Mac OS X 10.4.6/Intel
  - Compiler: gcc 4.0.1 (from XCode 2.2)
  - OpenSSL: 0.9.7i (Mac OS X original version)
  - Usage: connect to the submission port.

The detail of BUG is the following:

In protocol.c::smtp_client() line 138, fdputline() called with
argument line = "EHLO localhost." This is a string literal.

  130 static void smtp_client(CLI *c) {
  ...
  138     fdputline(c, c->remote_fd.fd, "EHLO localhost");
  ...

In network.c::fdputline() line 565, the literal is passed to
1st argument of safeconcat().

  556 void fdputline(CLI *c, int fd, char *line) {
  ....
  565     safeconcat(line, crlf);
  ...

In common.h line 311, safeconcat() is #define'ed as:

  311 #define safeconcat(dst, src) \
  312     (dst[STRLEN-1]='\0', strncat((dst), (src), \
           STRLEN-strlen(dst)-1))

This means the macro safeconcat() write to string literal.
This is the BUG. In Mac OS X envoronment, string literal is
NOT writable. So protection fault occurs at this code.
On the other environment, this breaks somewhere in the heap
or in the stack. This may also cause a crash.

In stunnel-4.14, fdprintf() is used instead of fdputline().
fdprint() have own writable buffers on stack, and the string
literal is copied to the stack. This works fine.

The work around is using own writable buffers in fdputline()
like fdprint() in stunnel-4.14. But it seems to be a performance
tuning why fdputline() is used. So I don't know what is the
correct way to fix this BUG.... 

I hope this BUG is fixed in the future release.
If this was already reported,  please ignore this mail.
Thank you.

Rgards,

----------
Internet Initiative Japan Inc.
Research & Development Section,
Product Development Division,
SEIL Business Unit

SUENAGA Hiroki <hsuenaga at iij.ad.jp>