[sr-dev] libressl support

Daniel-Constantin Mierla miconda at gmail.com
Tue May 2 15:34:22 CEST 2017


Hello,


On 01.05.17 07:28, Timo Teras wrote:
> Hi,
>
> I'm trying to fix tls.so to work with libressl. And there was already
> one commit handling some of the api differences.
>
> The next problem is that libressl ships the memory allocator changing
> function, but it's a stub that just returns "not supported".
>
> It seems that kamailio module does not load unless it can make libssl
> use shm_alloc. I'm wondering if this is a hard requirement? Does the
> tls module share libtls allocated things amongs forks?
yes, it keeps some data that needs to be shared between its processes.

>  Or this purely
> to track memory in kamailio framework?
>
> If it's hard dependency is there any way to workaround this libressl
> design decision?
>
> I think one option to try is to just implement the CRYPTO_* allocation
> function in kamailio main executable - they should then take preference
> over the libcrypto ones. Thoughts?
Last year at Fosdem (in 2016), I went to the libressl presentation and
tried to sort out what can it be done in this aspect. They said that I
must use some ticketing mechanism for sharing TLS contexts between
processes, but I never had the time to look properly and see what that
involves.

A bit later openssl project got a substantial financial backup, with
more company pushing money as well as human resources through the
foundation and the newer versions are already cleaner and safer, so it
went out of my high priority list.

However, if you'd find a solution, we are open to merge anything that
look good. Eventually the module can be forked in case there are a lot
of changes and the version with openssl can stay independent.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com




More information about the sr-dev mailing list