Viktor Dukhovni:
> On Thu, May 17, 2012 at 11:05:30AM -0400, Wietse Venema wrote:
>
> > > > Use $data_directory instead.
> > >
> > > That's likely not the direct cause of the problem, rather the
> > > existing cache likely contains entries from different OpenSSL
> > > version, and OpenSSL segfaults when one imports a cached session
> > > from an older (different) OpenSSL library.
> > >
> > > The cache lookup keys are by transport+destination, so sending mail
> > > to an address in the cache, causes an incompatible session to be
> > > loaded even if it is from a different library version. So we should
> > > probably add the library version to the lookup key.
> >
> > Something along this line should do the job:
> >
> > #define GEN_CACHE_ID(buf, id, len, service) \
> > do { \
> > buf = vstring_alloc(2 * (len) + 1 + strlen(service) + 3); \
> > hex_encode(buf, (char *) (id), (len)); \
> > vstring_sprintf_append(buf, "&s=%s", (service)); \
> > + vstring_sprintf_append(buf, "&l=%ld", (long)
> > OPENSSL_VERSION_NUMBER); \
> > } while (0)
>
> I think this is the server's cache key, the OP had issues with the
> SMTP client, so we probably need to "salt" that lookup also. It
Of course. This was just to give the idea how the session key
structure would change. I have added an equivalent GEN_CACHE_ID
definition to the TLS client code.
Too bad this can't be fixed in tlsmgr along with time-stamp expiration.
tlsmgr is a presistent process so it won't be aware that the on-disk
library image has changed.
The problem needs to be solved in the TLS client and server
applications.
Wietse
