I only recently checked the OpenSSL site and found out that they've changed their license from 4 clause BSD to an Apache style license. Many sites mention a license conflict between BSD 4 clause licenses and GNU GPL licenses. Several programs I use try to avoid the issue by adding a waiver to their license to allow linking with OpenSSL. Some examples are Dillo and D+. The issue can also be avoided in many cases by using software with a license other than the GNU GPL. So, the new switch to an Apache style license solves the license conflict issue in many cases (although it may cause new license conflict issues).

There's a useful reference on license information at the curl site:

There was an interesting thread about the GPL/BSD 4 clause license conflict on the lynx development list. Various SSL library options such as OpenSSL, gnutls and nss were discussed. It was mentioned that parts of the gnutls library (the compatibility layer) was licensed under GPLv3 which is incompatible with GPLv2 only ( https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ). The thread concluded with a recommendation to use the nss library to avoid license conflicts. It also mentioned that contacting everyone who worked on the project to re-license lynx would be too difficult. I guess there was some accommodation made after the thread because the latest version of lynx includes a COPYHEADER file that includes permission to use libraries such as OpenSSL and gnutls.

With the license change to OpenSSL, I hoped that the various license issues one might run across when building and distributing software that need SSL support had been solved. I've been using OpenSSL for a long time and it's always been highly portable and worked on a variety of platforms. However, when I downloaded the latest version of OpenSSL, I found that was no longer the case. With the various OpenSSL security issues in the news, work has been done to update the library and make it more secure. It appears, in this particular case, the security enhancements have come at the cost of portability. I used to be able to build OpenSSL using the ActiveState version of Perl. Now, OpenSSL is designed to only allow use of ActiveState or Windows native Perl builds using the Visual C++ compiler. If I continue to use the mingw compiler, I need a msys or cygwin based version of Perl. I'd previously built OpenSSL for DOS with no issues. Looking through some of the code, I'm afraid to even give it a try with the latest version of OpenSSL. OpenSSL is also much more dependent on Perl than it used to be. If I'm building a C library, it would be nice if it was only dependent on C code to build instead of requiring an interpreted language that's rather complicated to build.

I found it was time to either redesign my build of Perl (since a native Perl could no longer be used with MinGW to build OpenSSL) or to look for a new SSL library alternative. I'll share some of the results in my search for SSL library alternatives.

The major SSL options are OpenSSL, gnutls (with GNU GPL license) and nss (from Mozilla with Mozilla Public License). There are OpenSSL compatibility layers for gnutls (GPLv3 license) and nss ( Nss_compat_ossl originally from Fedora and no longer supported ). From some of the articles I read online, OpenSSL and nss were mentioned as more secure than gnutls. I also read that gnutls was a popular option on certain Linux systems such as Debian.

However, these aren't the only SSL libraries. There are several other options for embedded systems and other specialty uses. It's actually hard to track the options since the names of some of them keep changing. Typically, a program needs to offer support specifically for one or more of these library options because there usually isn't a compatibility layer to use that SSL library in place of a more common SSL library. Curl is a great example of a program that supports multiple SSL library options. D+ included support for cyassl. However, cyassl is now known as wolfssl. axtls looked like an interesting possibility because of its BSD license. It supposedly builds on Windows, but I didn't have any luck with it. Of all the various lightweight and/or embedded options, the only one I was able to get to build out of the box on Windows was mbedtls (formerly polarssl). mbedtls is available under a GPL license. Rather than try to track all the options and library name changes, I'll refer to the Wikipedia list:

After the recent security issues with OpenSSL, there were also forks of OpenSSL. These include LibreSSL (a fork by the OpenBSD developers) and BoringSSL (by Google). I tried building BoringSSL, but it required an interpreter (similar to OpenSSL), so why not stick with OpenSSL instead of switching to BoringSSL. I also tried building some of the various SSL options with cmake and had no luck at all.

I'd tried building LibreSSL in the past with no luck either. The fork was originally just designed for BSD systems and support for other platforms was added later. There are even some posts on the Internet about how early versions of LibreSSL include issues that made it insecure on Linux and other non-BSD systems. Once support was added for other platforms, I ran into an issue with what platforms were supported. The developers only supported the MinGW64 project on Windows. I use a version of MinGW based on an earlier version of the original MinGW which has a more lenient license. I've been adapting the mingwrt and w32api libraries, but they're based on the original public domain licensed versions of the libraries. So, when I previously tried to build LibreSSL, it wasn't compatible with my MinGW compiler. However, after the various changes to OpenSSL, I decided to give LibreSSL another try. Was pleasantly surprised this time when it only required minor patching with my particular version of MinGW in order to get it to build. It also uses the standard GNU autotools style configure/make/make install rather than requiring Perl just to configure and build it. If anyone's interested in the patches, feel free to contact me about getting a copy.

At this point, I'm considering switching to the LibreSSL fork. Several Linux distributions that use musl as their main C library are using LibreSSL as their SSL library of choice. They included patches to get various libraries and programs to build with LibreSSL instead of OpenSSL. There are also some patches at the LibreSSL site.

However, there are still some issues with switching. Many of the programs that included a waiver for OpenSSL, do not provide a similar waiver for LibreSSL. I certainly be interested in hearing how others are handling this particular issue. It would be nice if LibreSSL users could contact some of these projects and ask about a waiver for LibreSSL as well as OpenSSL. Some of the projects that come to mind are D+, Dillo, lynx, opusfile. Curl, libarchive and libssh2 can also use LibreSSL instead of OpenSSL, but there aren't any issues with license conflicts unless one adds a GNU GPL licensed library or a similar incompatible license to the mix.

I'd be interested to hear what others use as their SSL library of choice when building cross-platform applications and why they chose that particular library. You can find further discussion of this topic on the CPPDesign mailing list ( http://www.distasis.com/connect.htm ).
This post includes a list of resources for building applications and libraries for Windows using MinGW or similar projects.

Just wanted to note some of the native Windows porting projects I've worked on before I list some of the other projects out there. I've compiled the X server code and built a X server on Windows (similar to the Xming X server but with all my own patches). I'm looking into porting msh to Windows and other platforms (including patches for better handling of internationalization/UTF-8 character codes). I'm working on porting various core utilities based on Minix, BSD and custom implementations. I have patches and build scripts for several Open Source libraries and programs. See http://www.distasis.com/cpp/lmbld.htm for further details and a link to some of the scripts and patches. I work with regex and fnmatch libraries based on MIT licensed code from musl. musl uses regex code from the BSD licensed tre library. I also work with a BSD gettext implementation based on code put together for PostgreSQL. The libiconv and iconv implementations I use are written from scratch using custom UTF-8/internationalization code. I also have my own custom implementations of libmman, libdl and pthreads as well as other libraries I use to help with porting applications.

Places to download builds of various Open Source software and libraries for Windows and MinGW:

Many of the GNU libraries and programs patched and recompiled for MinGW.

Devpaks repository Libraries for the Dev-C++ compiler which uses MinGW. Could also be used without Dev-C++. Files should be standard tar.bz2 files renamed with .devpak extension.

OpenSuse Windows Packages has windows packages cross-compiled using MinGW on OpenSuse and the OpenSuse Build System (OBS).

ezwinports has ports of Unix and GNU software to MS-Windows.

MinGW packages repository

TakeoffGW - Cygwin style package manager and native Windows packages built with the OpenSUSE Build Service.

Patches and build scripts to build Open Source software for Windows:


MSYS and Cygwin alternatives:

Alternative to MinGW and Cygwin and build scripts for various Open Source tools:

GNU on Windows - lightweight alternative to Cygwin. Native Win32 programs.

Busybox port for Windows:
Lightweight versions of core utilities.

Busybox-w32 fork:

UnxUtils - Native Win32 ports of core utilities.

Unix Tools for Windows - Native Windows implementations emulating core utilities written in C++.

Native Win32 port of an older version of bash.

GNU Bash for Windows

WinZsh - Z shell for Windows

Xming X Server - Windows native X server

Open Source libraries patched for Windows:

Relocatable libintl for MinGW.

POSIX dynamic runtime library loading (libdl) compatibility routines.

POSIX mmap functionality.

Various POSIX functions implemented for Windows.

Winpty - provides and interface similar to a Unix pty-master for communicating with Windows console programs.

Pthreads and C/C++ 11 threads compatibility patches and implementations:

pthreads-win32 - Red Hat's POSIX thread library for Win32.

Simplified Pthread Emulation with Macros - Minimal pthread emulation.

TinyCThread - C11 threads implementation

c11threads - GNU compatibility headers for C11 thread support

July 2017

234 5678


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 20th, 2017 12:51 pm
Powered by Dreamwidth Studios