On Wed, Oct 22, 2014 at 3:07 PM, Michael B. Trausch < m...@fortifiedtechsystems.com> wrote:
> 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. :-) > Well, if the platform is mostly POSIX, it is relatively easier. For reference, here is a work-in-progress HP-UX port: https://github.com/kinichiro/portable/commit/ee8dadee8f52e56eb528d3fc372cea7024ae96f6 > 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 certainly could share how to build it under mingw, though take count that as an endorsement :) > 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. > These are only in the openssl(1) application, right? I wonder if we just started by focusing on the libraries if any Windows user would really care about openssl(1) initially. It certainly doesn't scratch any itch I have either. > * 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. > There's also the the yucky subject of sockets in 64-bit Windows not being an 'int', but a pointer instead: typedef UINT_PTR SOCKET; and a pox on whoever invented 'closesocket()' > 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. > I say we take it one patch at a time, and maybe start looking at patches not in bio or the openssl utility. > 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) > >
