Document 32-bit time_t problem on minw-w64 toolchain and how to avoid it

1 files changed, 21 insertions, 1 deletions

diff --git a/README.windows b/README.windows
index 27c2182..a88ddc9 100644
--- a/README.windows
+++ b/README.windows
@@ -12,7 +12,8 @@ cross compilers on Windows.
 To configure and build LibreSSL for a 32-bit system, use the following
 build steps:
 
- CC=i686-w64-mingw32-gcc ./configure --host=i686-w64-mingw32
+ CC=i686-w64-mingw32-gcc CPPFLAGS=-D__MINGW_USE_VC2005_COMPAT \
+ ./configure --host=i686-w64-mingw32
  make
  make check
 
@@ -22,6 +23,25 @@ For 64-bit builds, use these instead:
  make
  make check
 
+# Why the -D__MINGW_USE_VC2005_COMPAT flag on 32-bit systems?
+
+An ABI change introduced with Microsoft Visual C++ 2005 (also known as
+Visual C++ 8.0) switched time_t from 32-bit to 64-bit. It is important to
+build LibreSSL with 64-bit time_t whenever possible, because 32-bit time_t
+is unable to represent times past 2038 (this is commonly known as the
+Y2K38 problem).
+
+If LibreSSL is built with 32-bit time_t, when verifying a certificate whose
+expiry date is set past 19 January 2038, it will be unable to tell if the
+certificate has expired or not, and thus take the safe stance and reject it.
+
+In order to avoid this, you need to build LibreSSL (and everything that links
+with it) with the -D__MINGW_USE_VC2005_COMPAT flag. This tells mingw-w64 to
+use the new ABI.
+
+64-bit systems always have a 64-bit time_t and are not affected by this
+problem.
+
 # Using Libressl with Visual Studio
 
 A script for generating ready-to-use .DLL and static .LIB files is included in