30 Sep
2022
30 Sep
'22
9:46 a.m.
Hi!
A few years ago Daniel and I checked the possibility of supporting LibreSSL in addition to
OpenSSL. I might not remember all the details, but I think it failed on LibreSSL not
willing to support the memory allocation API we use in OpenSSL.
There has been a lot of discussion about the OpenSSL project lately, their focus and lack
of communication skills. AlpineLinux has tried moving away from OpenSSL but failed in the
first attempt and now discuss making another attempt. It they do and we want to run
Kamailio in Alpine - which is used in many container environments - we need to pay
attention.
https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28
Some quotes:
"Meanwhile, there are more problems: it turns out that OpenSSL 3.x will not have LTS
releases of the same length as past branches of OpenSSL. In addition, there are governance
problems, as outlined by Rich Salz in his email to the openssl-project mailing list: the
OpenSSL developers appear to want to focus on developing new features rather than cleaning
up the mess of regressions they have created with OpenSSL 3.”
"However, it is the opinion of the Alpine license review community that the Apache
2.0 license is not compatible with GPLv2. It is also the opinion of the Alpine license
review community that the OpenSSL 1.x license was alreadycompatible with both GPLv2 and
GPLv3 due to the system library exception: it is generally not possible to install an
Alpine system without having an OpenSSL implementation, so it clearly qualifies as a
system library.”
Kamailio has GPLv2 - if we parse the license the same way, we can’t support OpenSSL 3.
We have many third-party libraries we use, like Curl, that also use OpenSSL. Curl may be a
bad example, since the support of various TLS stacks is huge in Curl, but other libraries
may have to make a decision here too.
Do you have any feeling if other Open Source projects discuss this?
Should we take another look at using LibreSSL?
Personally I’m rather worried about all the discussions around the OpenSSL project. There
has been meetings at IETF with this as a topic. It is a very important building block for
a lot of what we work with.
Cheers,
/O
30 Sep
30 Sep
10:15 a.m.
Hello,
I haven't looked recently at libressl, so I cannot comment about it
right now.
But there is already tls_wolfssl module, which may still need testing to
get it in pair with tls, but it is in workable state (see presentation
at KW 2022).
Then, Kamailio is released under GPLv2 or later:
❯ head src/main.c
/*
* Copyright (C) 2001-2003 FhG Fokus
*
* This file is part of Kamailio, a free SIP server.
*
* Kamailio is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version
That means it can be considered under GPLv3 as well, should it be
decided that the Apache 2.0 license is not compatible with GPLv2.
Cheers,
Daniel
On 30.09.22 08:46, Olle E. Johansson wrote:
Hi!
A few years ago Daniel and I checked the possibility of supporting LibreSSL in addition
to OpenSSL. I might not remember all the details, but I think it failed on LibreSSL not
willing to support the memory allocation API we use in OpenSSL.
There has been a lot of discussion about the OpenSSL project lately, their focus and lack
of communication skills. AlpineLinux has tried moving away from OpenSSL but failed in the
first attempt and now discuss making another attempt. It they do and we want to run
Kamailio in Alpine - which is used in many container environments - we need to pay
attention.
https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28
Some quotes:
"Meanwhile, there are more problems: it turns out that OpenSSL 3.x will not have LTS
releases of the same length as past branches of OpenSSL. In addition, there are governance
problems, as outlined by Rich Salz in his email to the openssl-project mailing list: the
OpenSSL developers appear to want to focus on developing new features rather than cleaning
up the mess of regressions they have created with OpenSSL 3.”
"However, it is the opinion of the Alpine license review community that the Apache
2.0 license is not compatible with GPLv2. It is also the opinion of the Alpine license
review community that the OpenSSL 1.x license was alreadycompatible with both GPLv2 and
GPLv3 due to the system library exception: it is generally not possible to install an
Alpine system without having an OpenSSL implementation, so it clearly qualifies as a
system library.”
Kamailio has GPLv2 - if we parse the license the same way, we can’t support OpenSSL 3.
We have many third-party libraries we use, like Curl, that also use OpenSSL. Curl may be
a bad example, since the support of various TLS stacks is huge in Curl, but other
libraries may have to make a decision here too.
Do you have any feeling if other Open Source projects discuss this?
Should we take another look at using LibreSSL?
Personally I’m rather worried about all the discussions around the OpenSSL project. There
has been meetings at IETF with this as a topic. It is a very important building block for
a lot of what we work with.
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
Nov 7-10, 2022 (Europe Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
10:23 a.m.
Hello,
The apache 2.0 licence is indeed not compatible with GPL v2, as indicated from the apache
foundation themselves: https://www.apache.org/licenses/GPL-compatibility.html
In Kamailio we use GPL v2 or later, to be precise. GPL v3 is compatible with apache 2.0,
but for that we would need to re-licence the code.
For a detailed list of changes, one could look to this page:
https://wiki.openssl.org/index.php/OpenSSL_3.0
As Daniel already mentioned, there is now the tls_wolfssl module, which still needs some
work and some more tests, but provides a way forward.
About the third-party libraries e.g. used in libcurl or other, I'd guess we need to
see how the maintainer of this projects decide to go forward and then adapt.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
-----Original Message-----
From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> On Behalf Of Olle E. Johansson
Sent: Friday, September 30, 2022 8:47 AM
To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: [sr-dev] OpenSSL and LibreSSL - food for thought
Hi!
A few years ago Daniel and I checked the possibility of supporting LibreSSL in addition to
OpenSSL. I might not remember all the details, but I think it failed on LibreSSL not
willing to support the memory allocation API we use in OpenSSL.
There has been a lot of discussion about the OpenSSL project lately, their focus and lack
of communication skills. AlpineLinux has tried moving away from OpenSSL but failed in the
first attempt and now discuss making another attempt. It they do and we want to run
Kamailio in Alpine - which is used in many container environments - we need to pay
attention.
https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28
Some quotes:
"Meanwhile, there are more problems: it turns out that OpenSSL 3.x will not have LTS
releases of the same length as past branches of OpenSSL. In addition, there are governance
problems, as outlined by Rich Salz in his email to the openssl-project mailing list: the
OpenSSL developers appear to want to focus on developing new features rather than cleaning
up the mess of regressions they have created with OpenSSL 3.”
"However, it is the opinion of the Alpine license review community that the Apache
2.0 license is not compatible with GPLv2. It is also the opinion of the Alpine license
review community that the OpenSSL 1.x license was alreadycompatible with both GPLv2 and
GPLv3 due to the system library exception: it is generally not possible to install an
Alpine system without having an OpenSSL implementation, so it clearly qualifies as a
system library.”
Kamailio has GPLv2 - if we parse the license the same way, we can’t support OpenSSL 3.
We have many third-party libraries we use, like Curl, that also use OpenSSL. Curl may be a
bad example, since the support of various TLS stacks is huge in Curl, but other libraries
may have to make a decision here too.
Do you have any feeling if other Open Source projects discuss this?
Should we take another look at using LibreSSL?
Personally I’m rather worried about all the discussions around the OpenSSL project. There
has been meetings at IETF with this as a topic. It is a very important building block for
a lot of what we work with.
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
10:25 a.m.
So what’s the feeling about OpenSSL 3.0?
Are we going to put in the effort to go there or use the energy for LibreSSL?
/O
On 30 Sept 2022, at 09:23, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
The apache 2.0 licence is indeed not compatible with GPL v2, as indicated from the apache
foundation themselves: https://www.apache.org/licenses/GPL-compatibility.html
In Kamailio we use GPL v2 or later, to be precise. GPL v3 is compatible with apache 2.0,
but for that we would need to re-licence the code.
For a detailed list of changes, one could look to this page:
https://wiki.openssl.org/index.php/OpenSSL_3.0
As Daniel already mentioned, there is now the tls_wolfssl module, which still needs some
work and some more tests, but provides a way forward.
About the third-party libraries e.g. used in libcurl or other, I'd guess we need to
see how the maintainer of this projects decide to go forward and then adapt.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
-----Original Message-----
From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> On Behalf Of Olle E. Johansson
Sent: Friday, September 30, 2022 8:47 AM
To: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: [sr-dev] OpenSSL and LibreSSL - food for thought
Hi!
A few years ago Daniel and I checked the possibility of supporting LibreSSL in addition
to OpenSSL. I might not remember all the details, but I think it failed on LibreSSL not
willing to support the memory allocation API we use in OpenSSL.
There has been a lot of discussion about the OpenSSL project lately, their focus and lack
of communication skills. AlpineLinux has tried moving away from OpenSSL but failed in the
first attempt and now discuss making another attempt. It they do and we want to run
Kamailio in Alpine - which is used in many container environments - we need to pay
attention.
https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28
Some quotes:
"Meanwhile, there are more problems: it turns out that OpenSSL 3.x will not have LTS
releases of the same length as past branches of OpenSSL. In addition, there are governance
problems, as outlined by Rich Salz in his email to the openssl-project mailing list: the
OpenSSL developers appear to want to focus on developing new features rather than cleaning
up the mess of regressions they have created with OpenSSL 3.”
"However, it is the opinion of the Alpine license review community that the Apache
2.0 license is not compatible with GPLv2. It is also the opinion of the Alpine license
review community that the OpenSSL 1.x license was alreadycompatible with both GPLv2 and
GPLv3 due to the system library exception: it is generally not possible to install an
Alpine system without having an OpenSSL implementation, so it clearly qualifies as a
system library.”
Kamailio has GPLv2 - if we parse the license the same way, we can’t support OpenSSL 3.
We have many third-party libraries we use, like Curl, that also use OpenSSL. Curl may be
a bad example, since the support of various TLS stacks is huge in Curl, but other
libraries may have to make a decision here too.
Do you have any feeling if other Open Source projects discuss this?
Should we take another look at using LibreSSL?
Personally I’m rather worried about all the discussions around the OpenSSL project. There
has been meetings at IETF with this as a topic. It is a very important building block for
a lot of what we work with.
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
10:43 a.m.
Hello,
personally, I do not look much more into that yet. If OpenSSL will finally deprecate the
APIs we use in Kamailio, we probably will need to either adapt and re-licence, or switch
completely to an alternative library like wolfssl. This would mean losing some (rarely
used) functionality like for hardware security modules.
Regarding LibreSSL, let's see how other projects progress in this regard. If somebody
wants to invest more time in this matter, of course go ahead, just announce on the list to
let other people know.
For reference, here some thread on the (failed) Alpine migration some years ago. So, while
things were looking good on a high level for such a migration, of course such a move is
rather complicated.
https://lists.alpinelinux.org/alpine-devel/6079.html
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
-----Original Message-----
From: Olle E. Johansson <oej(a)edvina.net>
Sent: Friday, September 30, 2022 9:25 AM
To: Henning Westerholt <hw(a)gilawa.com>
Cc: Kamailio (SER) - Development Mailing List <sr-dev(a)lists.kamailio.org>
Subject: Re: [sr-dev] OpenSSL and LibreSSL - food for thought
So what’s the feeling about OpenSSL 3.0?
Are we going to put in the effort to go there or use the energy for LibreSSL?
/O
On 30 Sept 2022, at 09:23, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hello,
The apache 2.0 licence is indeed not compatible with GPL v2, as
indicated from the apache foundation themselves:
https://www.apache.org/licenses/GPL-compatibility.html
In Kamailio we use GPL v2 or later, to be precise. GPL v3 is compatible with apache 2.0,
but for that we would need to re-licence the code.
For a detailed list of changes, one could look to this page:
https://wiki.openssl.org/index.php/OpenSSL_3.0
As Daniel already mentioned, there is now the tls_wolfssl module, which still needs some
work and some more tests, but provides a way forward.
About the third-party libraries e.g. used in libcurl or other, I'd guess we need to
see how the maintainer of this projects decide to go forward and then adapt.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/ Kamailio services –
https://gilawa.com
-----Original Message-----
From: sr-dev <sr-dev-bounces(a)lists.kamailio.org> On Behalf Of Olle E.
Johansson
Sent: Friday, September 30, 2022 8:47 AM
To: Kamailio (SER) - Development Mailing List
<sr-dev(a)lists.kamailio.org>
Subject: [sr-dev] OpenSSL and LibreSSL - food for thought
Hi!
A few years ago Daniel and I checked the possibility of supporting LibreSSL in addition
to OpenSSL. I might not remember all the details, but I think it failed on LibreSSL not
willing to support the memory allocation API we use in OpenSSL.
There has been a lot of discussion about the OpenSSL project lately, their focus and lack
of communication skills. AlpineLinux has tried moving away from OpenSSL but failed in the
first attempt and now discuss making another attempt. It they do and we want to run
Kamailio in Alpine - which is used in many container environments - we need to pay
attention.
https://gitlab.alpinelinux.org/alpine/tsc/-/issues/28
Some quotes:
"Meanwhile, there are more problems: it turns out that OpenSSL 3.x will not have LTS
releases of the same length as past branches of OpenSSL. In addition, there are governance
problems, as outlined by Rich Salz in his email to the openssl-project mailing list: the
OpenSSL developers appear to want to focus on developing new features rather than cleaning
up the mess of regressions they have created with OpenSSL 3.”
"However, it is the opinion of the Alpine license review community that the Apache
2.0 license is not compatible with GPLv2. It is also the opinion of the Alpine license
review community that the OpenSSL 1.x license was alreadycompatible with both GPLv2 and
GPLv3 due to the system library exception: it is generally not possible to install an
Alpine system without having an OpenSSL implementation, so it clearly qualifies as a
system library.”
Kamailio has GPLv2 - if we parse the license the same way, we can’t support OpenSSL 3.
We have many third-party libraries we use, like Curl, that also use OpenSSL. Curl may be
a bad example, since the support of various TLS stacks is huge in Curl, but other
libraries may have to make a decision here too.
Do you have any feeling if other Open Source projects discuss this?
Should we take another look at using LibreSSL?
Personally I’m rather worried about all the discussions around the OpenSSL project. There
has been meetings at IETF with this as a topic. It is a very important building block for
a lot of what we work with.
Cheers,
/O
_______________________________________________
Kamailio (SER) - Development Mailing List sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
787
days inactive
787
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Olle E. Johansson