Re: LibreSSL: GOWindows support
Thanks everyone for the feedback so far. I made some improvements to Windows poll emulation functions to handle errno impedance mismatches, POLLHUP and out-of-band data. Keep in mind that windows select is quite different than anything else when reviewing that code - it is not bitmap-based. I also added posix_write/posix_read shims to automatically select the right thing depending on if passed a socket or file descriptor. 40/40 unit tests are now passing. I tried the normally-disabled biotest.exe on a whim and it actually crashes on wine, because inet_pton is not implemented in the runtime :P So anyone who has real Windows please give this a spin and let me know how it goes. I'll spin up some VMs and give it a try as well. On Thu, Nov 20, 2014 at 9:27 AM, Brent Cook bust...@gmail.com wrote: On Tue, Nov 11, 2014 at 8:41 AM, Brent Cook bust...@gmail.com wrote: I gave the openbsd src patches a spin last night. I wonder if there's a way we could instead coerce mingw into pretending to be more POSIX by way of header tricks in the portable tree: Hi Dongsheng, Thanks for doing the initial test port work and posting your fork. I gave the concept of 'coerce win32 support via stupid header tricks' a spin, and the result of that is here: https://github.com/busterb/portable/commits/win32-minimal This basically intercepts all of the BSD headers unavailable in Win32, doing the bulk of the required fixups passively through preprocessor abuse. Note the fun 'posix_close', for instance. I'm almost sure this has bugs, but tossing up as perhaps an example of Cunningham's law. While this whole thing feels a little wrong, software on Windows that uses 'int' interchangeably with SOCKET already sort of dooms it by design, especially on Win64. Hopefully nobody is seriously using BIO's builtin socket functions in the first place (they were already pretty lame on POSIX systems). The minimal pile of upstream portability changes that this needed to work are below, and there are not a lot. I am not sure if 'ui_openssl.c' takes the cake as the most out-of-place thing to find in a crypto library. I also wonder what software would break if it were moved into openssl(1) directly: https://github.com/busterb/openbsd/commits/win32-minimal The result passes 39/40 unit tests so far - still gotta look at pq_test. I took the poll.c from your fork and built it into openssl(1) only. However, asprintf worked without any extra effort thanks to recent mingw having a native version available (though I should probably look at how that is actually implemented). The idea of needing 2 different asprintf shims seems rather depressing. I didn't actually incorporate the syslog compat functions, and am debating if these should really just be no-op shims for Win32 - again, if someone is using these on Windows, they are not using event log properly, and will get some pretty ugly-looking logs. I tested and built on Ubuntu 14.04 with wine and the mingw-w64 package, using this config line: CC=i686-w64-mingw32-gcc ./configure --host=i686-w64-mingw32 Comments? - Brent
Re: LibreSSL: GOWindows support
On Tue, Nov 11, 2014 at 8:41 AM, Brent Cook bust...@gmail.com wrote: I gave the openbsd src patches a spin last night. I wonder if there's a way we could instead coerce mingw into pretending to be more POSIX by way of header tricks in the portable tree: Hi Dongsheng, Thanks for doing the initial test port work and posting your fork. I gave the concept of 'coerce win32 support via stupid header tricks' a spin, and the result of that is here: https://github.com/busterb/portable/commits/win32-minimal This basically intercepts all of the BSD headers unavailable in Win32, doing the bulk of the required fixups passively through preprocessor abuse. Note the fun 'posix_close', for instance. I'm almost sure this has bugs, but tossing up as perhaps an example of Cunningham's law. While this whole thing feels a little wrong, software on Windows that uses 'int' interchangeably with SOCKET already sort of dooms it by design, especially on Win64. Hopefully nobody is seriously using BIO's builtin socket functions in the first place (they were already pretty lame on POSIX systems). The minimal pile of upstream portability changes that this needed to work are below, and there are not a lot. I am not sure if 'ui_openssl.c' takes the cake as the most out-of-place thing to find in a crypto library. I also wonder what software would break if it were moved into openssl(1) directly: https://github.com/busterb/openbsd/commits/win32-minimal The result passes 39/40 unit tests so far - still gotta look at pq_test. I took the poll.c from your fork and built it into openssl(1) only. However, asprintf worked without any extra effort thanks to recent mingw having a native version available (though I should probably look at how that is actually implemented). The idea of needing 2 different asprintf shims seems rather depressing. I didn't actually incorporate the syslog compat functions, and am debating if these should really just be no-op shims for Win32 - again, if someone is using these on Windows, they are not using event log properly, and will get some pretty ugly-looking logs. I tested and built on Ubuntu 14.04 with wine and the mingw-w64 package, using this config line: CC=i686-w64-mingw32-gcc ./configure --host=i686-w64-mingw32 Comments? - Brent
Re: LibreSSL: GOWindows support
I gave the openbsd src patches a spin last night. I wonder if there's a way we could instead coerce mingw into pretending to be more POSIX by way of header tricks in the portable tree: Create a stubs for each POSIX network header, e.g. include/sys/socket.h: #ifndef _WIN32 #include_next sys/socket.h #else #include win32netcompat.h #endif Then, include/win32netcompat.h contains: #ifndef LIBCRYPTOCOMPAT_WIN32NETCOMPAT_H #define LIBCRYPTOCOMPAT_WIN32NETCOMPAT_H #include ws2tcpip.h #define SHUT_RDWR SD_BOTH #define SHUT_RD SD_RECEIVE #define SHUT_WR SD_SEND #endif Repeat for each missing networking header. Mingw seens to already be full of little hacks like this (e.g. look at all the _POSIX sections in the headers). On Fri, Nov 7, 2014 at 8:26 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: On Fri, Nov 7, 2014 at 11:07 PM, Brent Cook bust...@gmail.com wrote: On Nov 7, 2014, at 8:21 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: I need some code changes for Windows support. e.g. --- a/src/lib/libssl/src/crypto/bio/bss_dgram.c +++ b/src/lib/libssl/src/crypto/bio/bss_dgram.c @@ -57,13 +57,17 @@ * */ +#ifdef _WIN32 +#include ws2tcpip.h +#else #include sys/socket.h -#include sys/time.h - #include netinet/in.h +#include netdb.h +#endif + +#include sys/time.h #include errno.h -#include netdb.h #include stdio.h #include string.h #include unistd.h Thanks for the first set of patches on the portable tree! I would think the #ifdef _WIN32 is probably the lesser of two evils. Hopefully this will be largely confined to bio and the openssl app? yes, I can generate openssl.exe with my local patches. I use #ifdef _WIN32 to guard headres, socket functions, signal functions, tty functions. fork is more painful, so I defined OPENSSL_NO_SPEED. maybe I'll write a Windows version speed_main. You'll also need to audit file descriptor usage carefully, so they are closed properly: Thanks.
Re: LibreSSL: GOWindows support
On Fri, Nov 7, 2014 at 11:07 PM, Brent Cook bust...@gmail.com wrote: On Nov 7, 2014, at 8:21 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: I need some code changes for Windows support. e.g. --- a/src/lib/libssl/src/crypto/bio/bss_dgram.c +++ b/src/lib/libssl/src/crypto/bio/bss_dgram.c @@ -57,13 +57,17 @@ * */ +#ifdef _WIN32 +#include ws2tcpip.h +#else #include sys/socket.h -#include sys/time.h - #include netinet/in.h +#include netdb.h +#endif + +#include sys/time.h #include errno.h -#include netdb.h #include stdio.h #include string.h #include unistd.h Thanks for the first set of patches on the portable tree! I would think the #ifdef _WIN32 is probably the lesser of two evils. Hopefully this will be largely confined to bio and the openssl app? yes, I can generate openssl.exe with my local patches. I use #ifdef _WIN32 to guard headres, socket functions, signal functions, tty functions. fork is more painful, so I defined OPENSSL_NO_SPEED. maybe I'll write a Windows version speed_main. You'll also need to audit file descriptor usage carefully, so they are closed properly: Thanks.
