Hello,
I would like to contribute a port for the Microsoft operating systems
so that LibreSSL can support these systems without the GPL'd Cygwin
DLL being present on the system. OpenSSL works on them already, but
support for that was removed due to its apparent insecurity and
kludgyness.
I have done a very ugly port that builds and works in the few
scenarios that I've tested with, but it's not complete as some
features (mostly the ones that allow disabling at compile time) need
more work to finish porting.
The major reason that I'm writing is that I can find no really decent
example or documentation as to "how" to add support for the platform
to the source tree. While LibreSSL uses the GNU build system, instead
of the custom Perl-based configuration that OpenSSL uses, it seems
that the way that portability is achieved is very different from what
I am used to; at any rate, I don't really understand it. I wouldn't
dare even show the patch I've got, as I can tell you right now it
would be refused. :-)
I've been hunting around the past few days, and found not much. I
looked at the OpenSSH portable project, but the only Windows build it
seems to support is under the Cygwin runtime, which I cannot use for
various reasons.
I realize that porting to Windows is going to involve a decent amount
of work to do it in a way that will be acceptable to this project.
I'm willing to do it such that it'll make you guys happy and I'm even
willing to fork over the copyright to the contribution if so needed.
I just need a native Windows 32-bit and 64-bit version that supports
all current Microsoft-supported systems (e.g., Vista and later).
I would have zero intention of including support for Visual C++
compilers, as they really do all stink. My contribution would only
support using the {i686,x86_64}-w64-mingw32 toolchains and would
enable building of LibreSSL on POSIX systems via cross-compilation and
on Windows systems that have a native installation of the mingw64
toolchain.
Below is additional information that I've learned thus far, in case it
affects the replies in any way... if not, just ignore it.
* A native port to Windows includes using some of the functionality
in Winsock2 which isn't (presently) available in the mingw64
toolchain, such as InetPton (no, that's not mistyped, that's what
they call that function).
* Native Windows has a signal.h, but it doesn't not comply with
anything reasonable from anything I've ever seen anywhere. On
Windows, this means that signal.h must be ignored and likely the
sections which rely on handling of signals will need to have new
functions written which use the Windows API.
* Windows does not have the typical <sys/socket.h>, <sys/ioctl.h>,
<netdb.h>, etc. headers, instead using <winsock2.h> and
<ws2tcpip.h>. These are MOSTLY compatible with the BSD sockets
API, but there are tweaks required (inet_pton -> InetPton can be
handled with a #define; Windows doesn't use SHUT_RD, SHUT_WR, or
SHUT_RDWR but rather SD_SEND, SD_RECEIVE and SD_BOTH; some APIs
have no 1:1 equivalents in the Win32 API, such as ioctl and the
like, but can be implemented with functions to enable 1:1 mapping).
* Windows doesn't have termios or anything like it.
* I haven't tested any of the sockets functionality on the build I
have, but it is very likely to not work without some extra
massaging; in Windows, the namespaces identifying file descriptors
and sockets are separate. There are methods of attempting
unification of the two, but they seem fragile.
Additionally, I would like to know if there are any preferences for
how the work is to be done and so forth. I've already reconfigured my
local emacs so that I'm able to use the style that OpenBSD already
uses in the sources, and I'll comply with existing writing style in
each file.
In essense, the current working tree I have is pretty crappy: it's
full of peppered #ifdefs and the like, just to get it to build. I
have a roadmap for completing the port, I just need to know the
OpenBSD-specific requirements for contributing the port, or be pointed
to a document which explains all of that to me.
One last item to mention: I am an American, living in the US. I would
therefore be able to provide diffs only, in order to avoid our export
controls on "cryptographic software". I would not be making any
alterations to cryptographic code, and only "exporting" unified diffs
which enable the existing system to build on Windows. If this is a
blocker to being able to contribute to the project, it'd be good to
know that now, and I'll just maintain a local fork or something. I am
not a lawyer, but after reading through what the controls are, I'm
relatively confident that diffs which do not themselves contain
cryptographic functionality are exportable without issue.
Thanks!
Michael B. Trausch
--
Michael B. Trausch Fortified Tech Systems LLC
P: (404) 692-6078 or (844) GR8-TECH (Toll Free)
