> OpenSSL sometimes acts stupidly like this inside a chroot. We've
> encountered a few issues in the past with openssl doing totally crazy
> stuff inside a chroot, including abort() on krb5-related things. From
> what I understood (others, please correct me if I'm wrong), such
> processing may be altered by the type of key or ciphers.
>
> In my opinion, you should attempt two things :
>
> 1) ensure that your ssl library is up to date (double checking doesn't
> cost much)
>
> 2) try it again without the chroot statement to see if when openssl finds
> what it's looking for, the leak stops.
>
> 3) maybe file a report to the openssl list about a memory leak in that
> exact situation, with the traces you sent to me. Maybe they'll want
> to have your public key as well to verify some assumptions about
> what could be done inside the lib with its properties.
I suppose you can disable KRB5 ciphers to be part of the negotiation by
adding !KRB5 to your cipher configuration. If that works, it is probably
the simplest workaround, unless you actually need KRB5.
Lukas
