Commit 50fc6984 authored by Martyn Welch's avatar Martyn Welch

Update TLS stack concept document based on new information

A decision by Debian to treat OpenSSL as a system library has come to
light, which had not come to light at the time the original document was
written. Update the document to reflect this decision.
Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.com>
parent 4b96e1e9
Pipeline #166126 passed with stages
in 7 minutes and 30 seconds
......@@ -389,41 +389,45 @@ be considered to be distributed as part of the operating system this exception
doesn't apply especially in embedded devices where the software is distributed
preinstalled as a complete entity.
Different Linux distributions have opposing views on how to handle this, with
Debian has deciding that a linked library creates a derivative work and all
the packages it ships should be considered a combined work. Conversely the
Fedora project have deemed it to be a
Most distributions seem to either ignore this potential issue or do not
consider a policy to be needed. The Fedora project have deemed OpenSSL to be a
[system library](https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F)
as defined by the GPL and thus there is no incompatibility. Most distributions
seem to either ignore this potential issue or do not consider a policy to be
needed.
as defined by the GPL and thus there is no incompatibility. Debian
historically decided that a linked library creates a derivative work and all
the packages it ships should be considered a combined work, though the decision
has
[recently been taken](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105)
to follow Fedora's lead here.
# Recommendations
Whilst a single stack solution would present a number of benefits, this would
require a significant outlay in effort one way or another to align the
applications to the provided stack and to provide a stack that was licensed in
an appropriate manner. Such an effort would result in Apertis straying away from
well-trodden paths. Implementing security is hard, it's easy to make mistakes
that cause holes. This is especially problematic as the level of review is low,
which would be the case for a highly-customized solution over existing ones. As
a result, we feel that the potential risks of implementing a single stack solution
outweigh the benefits it would bring.
an appropriate manner. Such an effort would result in Apertis straying away
from well-trodden paths. Implementing security is hard, it's easy to make
mistakes that cause holes. This is especially problematic if the level of
review is low, which would be the case for a highly-customized solution
compared with existing ones. As a result, we feel that the potential risks of
implementing a single stack solution outweigh the benefits it would bring.
A two-stack approach requires separate solutions for GnuTLS and OpenSSL. The
breakdown of applications supporting GnuTLS and OpenSSL means that we recommend
upgrading GnuTLS to a new version for those applications that can use it
licensed as GPL-2. The one outlier is the printing support in GTK, which ends
up causing GPL-2 dependencies in GTK. We recommend dropping printing support
from GTK in order to remove this dependency as we don't feel that this
functionality is critical to Apertis' aim.
licensed as GPL-2. The one outlier is the printing support in GTK, which
potentially ends up causing GPL-2 dependencies in GTK. Whilst Debian have also
declared CUPS as a system library, we feel that the differing use cases for
Debian and Apertis make this less of a realistic position to take. We therefore
recommend dropping printing support from GTK in order to remove this dependency
as we don't feel that this functionality is critical to Apertis' aim.
A number of potential alternatives exist for OpenSSL, but some of the
solutions are impractically licensed (such as wolfSSL dual-licensed under the
GPL-2 and a commercial license) and the remainder do not improve the licensing
situation over OpenSSL (they share at least some code with OpenSSL under its
original license). As a result it is our recommendation to consider OpenSSL as
a system library and continue utilizing it.
a system library and continue utilizing it, inline with the other distributions
that have documented a specific policy covering this.
The table below summarizes which libraries each of the identified dependents
we'd expect to use under the above recommendations. We would expect proprietary
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment