[sr-dev] binary packages and OpenSSL

[Daniel-Constantin Mierla]

Hello Daniel,

On 5/13/13 4:27 PM, Daniel Pocock wrote:
>
> Just some further thoughts on the problems facing binary packages with
> TLS support
>
> I don't know the TLS code in any detail at all, but to what extent could
> it be split into a standalone binary module?

tls code in in tls module and it built at tls.so, loaded via config with 
loadmodule. There is no libssl function used in core -- other modules 
link to it (like websocket), but not in the core.

Does this help in any way? I understood (during past discussions) that 
it is anyhow affecting the distribution due to viral mode of gpl.

TLS module is packaged separately.

 From your next option, we already have: "TLS-related files in a 
subdirectory for building a module". And yes, installing kamailio with 
tls from packages (we distribute though our repo) means:

apt-get install kamailio kamailio-tls-modules

Cheers,
Daniel


>
> Here is the possible solution:
> - single source package (kamailio.tar.gz) or maybe even separate source
> - TLS-related files in a subdirectory for building a module
> - TLS-related files re-licensed under BSD terms
> - compiling and running core doesn't require the TLS source or binary
>
> When uploading to Debian, Fedora, etc, there would be two artifacts:
> kamailio-core.deb (GPL license)
> kamailio-tls.deb (optional, BSD licensed, depends: openssl)
>
> It then becomes possible for users who want TLS support to just do
>
> # apt-get install kamailio kamailio-tls
>
> or something like that.
>
> The challenges:
> - ensuring that the low-level TLS support (any code that uses OpenSSL
> API) can be separated into a module
> - ensuring that any previous contributors on the affected code are happy
> to have it re-licensed
>
> Of course, solving the first challenge (separating the low level code)
> probably brings the project closer to having adaptable support for
> GnuTLS in future.
>
> I realise that TLS is intricately tied up in the SIP protocol (e.g.
> inserting proper transport parameters in Via headers, sips URI, ...),
> but the licensing problem really only kicks in where the OpenSSL API is
> used.  As long as there is an abstraction layer and the high-level code
> doesn't use OpenSSL API directly, this may not be difficult to solve.
>
> Regards,
>
> Daniel
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
   * http://asipto.com/u/katu *