X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-Id: <201408100605.s7A65xQN031313@delorie.com>
Date: Sat, 09 Aug 2014 21:19:00 +0200
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To: djgpp-announce AT delorie DOT com
Subject: ANNOUNCE: DJGPP port of OpenSSL 1.0.1i uploaded.
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Reply-To: djgpp AT delorie DOT com

This is a port of OpenSSL 1.0.1i to MSDOS/DJGPP.

   The OpenSSL Project is an Open Source toolkit implementing the Secure Sockets
   Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as
   a full-strength general purpose cryptography library.  OpenSSL is based on
   the excellent SSLeay library developed from Eric A. Young and Tim J. Hudson.
   The OpenSSL toolkit is licensed under a dual-license (the OpenSSL license
   plus the SSLeay license) situation, which basically means that you are free
   to get and use it for commercial and non-commercial purposes as long as you
   fulfill the conditions of both licenses.



   DJGPP specific changes.
   =======================

   Fortunately, OpenSSL supports DJGPP out-of-the-box so there is no need to
   adjust the source code itself.  Neither less there are assumptions made about
   the file system used and its capabilities that require some changes in the
   perl configuration scripts and in the way source package is unzipped.

   - all new DJGPP specific files are store in the /djgpp directory.

   - to install, configure and compile the sources LFN support is required.

   - all links (linked files) in the archive have been removed. Depending on if
     djtar or tar is used and depending on if they are from DJGPP 2.03 or 2.04
     all these tar programs create different kind of files to represent those
     links and this breaks either the configuration step or later the building
     step.

   - the /djgpp directory contains unpack.sh.  This small shell script uses
     djtar to create a file list of the archive, identifies the links, extract
     the sources using djtar and removes all links.  Of course, if you download
     the DJGPP port all this has already been done.

   - as usual the /djgpp directory contains also the diffs file.  It shows how
     I have changed some of the perl scripts used during the configuration and
     building steps to check for the OS used and to copy the files instead of
     trying to create links even if this is possible.

   - the binaries, headers and libraries will be installed in the corresponding
     directories of the DJGPP installation tree.  All documentation will be
     installend in /dev/env/DJDIR/share/ssl/man.  This means that you will have
     to adjust your MANPATH in djgpp.env if you want that the man program finds
     these new manpages.

   - to be able to configure and compile this port, the DJGPP port of perl must
     be installed.  openssl uses a mix of perl scripts and Makefiles to configure
     and compile the sources.  I have used perl588b but the previous one may work
     as well but I have never tested this.

   - to be able to configure and compile this port, the DJGPP port of WATT32
     must be installed.  It can be downloaded as:
       ftp://ftp.delorie.com/pub/djgpp/current/v2tk/wat3222br3.zip
     or:
       ftp://ftp.delorie.com/pub/djgpp/beta/v2tk/wat3222br3.zip
     As usual the version from the /current directory is for the use with
     djdev203 and the one from the /beta directory is for the use with djdev204.
     After having installed the port make sure that the WATT_ROOT environment
     variable points to the directory where the headers and the library reside.
     This is:
       set WATT_ROOT=/dev/env/DJDIR/net/watt
     Due to the dependency of WATT-32 and the required value of the WATT_ROOT
     environment variable, the source package is not configured at all.  You
     have to install WATT-32 first and then you can configure and build openssl
     as described in the original INSTALL.DJGPP file.

   - the port has been configured and compiled to support for zlib compression.
     The zlib port used is
       ftp://ftp.delorie.com/pub/djgpp/current/v2tk/zlib128b.zip
     or:
       ftp://ftp.delorie.com/pub/djgpp/beta/v2tk/zlib128b.zip
     but any other version of the port may work as well.  As usual the version
     from the /current directory is for the use with djdev203 and the one from
     the /beta directory is for the use with djdev204.

   - the test suite passes for both djdev203 and djdev204 except for the last
     test that requires some certificate that needs to be requested. For some
     test, it is also required that the port of GNU bc is installed.

   - the binary package of openssl ist not completely SFN clean.  But this
     concerns the manpages only.  Neither the libraries nor the headers are
     affected.  I do not have the time to invent SFN clean names for hundreds
     of manpages which names may change and become useless with the next openssl
     update.  Of course, the headers and libraries are 8.3 clean and the use of
     the libraries do not require LFN support at all.

   - as any cryptographic software, openssl needs a source of unpredictable data
     to work correctly.  Many open source operating systems provide a "randomness
     device" (/dev/urandom or /dev/random) that serves this purpose. As of
     version 0.9.7f of openssl the DJGPP port checks upon /dev/urandom$ for a
     3rd party "randomness" DOS driver.  One such driver, NOISE.SYS, can be
     obtained from "http://www.rahul.net/dkaufman/index.html" as:
        <http://www.rahul.net/dkaufman/noise063a2.zip>
     Please read the instructions carefully.  This driver works on DOS and may
     be on some versions of Windows but it does not work for all versions of
     Windows.  For XP it does not work and I have found no replacement.  This
     means that for WinXP and probably for Win2K there is there is no "randomness"
     support for openssl available.

   - most but not all programs of the /examples directory can be successfully
     compiled but they may not work.  I have no intention to fix them, neither
     less they may serve as example how to use the library and how to compile
     and link your application with this library together with the WAT32 library
     and the zlib library.

   - The DJGPP 2.03 version of the port has been compiled using gcc473 and
     bnu224br2.  The DJGPP 2.04 version has been compiled using gcc490 and
     bnu224br2.  But instead of using the libc.a provided djdev204, a libc
     version compiled from the repository code has been used.  The repository
     code has been patched with the memory patch as provided by Andris Pavenis
     in:
       http://ap1.pp.fi/djgpp/djdev/djgpp/20140421/use_nmalloc.diff
     The goal is to test how well the new memory system and the current libc
     code works.  The repository code can be downloaded from Martin Strömberg's
     site as:
       http://www.ludd.luth.se/~ams/djgpp/cvs/djgpp.cvs.tar.gz

     Configuring, compiling and running the test suite takes around 02:10 h.


   For further information about OpenSSL please read the man pages,
   various README files and NEWS file.  Also visit the home page of openssl.
   Please note that I am not an user of openssl.  I have only ported it because
   I needed it to create another port.  This means that I am not able to answer
   openssl specific questions.


   This is an verbatim extract of the CHANGES file:
-------------------------------------------------------------------------------
  Changes between 1.0.1h and 1.0.1i [6 Aug 2014]

   *) Fix SRP buffer overrun vulnerability. Invalid parameters passed to the
      SRP code can be overrun an internal buffer. Add sanity check that
      g, A, B < N to SRP code.

      Thanks to Sean Devlin and Watson Ladd of Cryptography Services, NCC
      Group for discovering this issue.
      (CVE-2014-3512)
      [Steve Henson]

   *) A flaw in the OpenSSL SSL/TLS server code causes the server to negotiate
      TLS 1.0 instead of higher protocol versions when the ClientHello message
      is badly fragmented. This allows a man-in-the-middle attacker to force a
      downgrade to TLS 1.0 even if both the server and the client support a
      higher protocol version, by modifying the client's TLS records.

      Thanks to David Benjamin and Adam Langley (Google) for discovering and
      researching this issue.
      (CVE-2014-3511)
      [David Benjamin]

   *) OpenSSL DTLS clients enabling anonymous (EC)DH ciphersuites are subject
      to a denial of service attack. A malicious server can crash the client
      with a null pointer dereference (read) by specifying an anonymous (EC)DH
      ciphersuite and sending carefully crafted handshake messages.

      Thanks to Felix Gröbert (Google) for discovering and researching this
      issue.
      (CVE-2014-3510)
      [Emilia Käsper]

   *) By sending carefully crafted DTLS packets an attacker could cause openssl
      to leak memory. This can be exploited through a Denial of Service attack.
      Thanks to Adam Langley for discovering and researching this issue.
      (CVE-2014-3507)
      [Adam Langley]

   *) An attacker can force openssl to consume large amounts of memory whilst
      processing DTLS handshake messages. This can be exploited through a
      Denial of Service attack.
      Thanks to Adam Langley for discovering and researching this issue.
      (CVE-2014-3506)
      [Adam Langley]

   *) An attacker can force an error condition which causes openssl to crash
      whilst processing DTLS packets due to memory being freed twice. This
      can be exploited through a Denial of Service attack.
      Thanks to Adam Langley and Wan-Teh Chang for discovering and researching
      this issue.
      (CVE-2014-3505)
      [Adam Langley]

   *) If a multithreaded client connects to a malicious server using a resumed
      session and the server sends an ec point format extension it could write
      up to 255 bytes to freed memory.

      Thanks to Gabor Tyukasz (LogMeIn Inc) for discovering and researching this
      issue.
      (CVE-2014-3509)
      [Gabor Tyukasz]

   *) A malicious server can crash an OpenSSL client with a null pointer
      dereference (read) by specifying an SRP ciphersuite even though it was not
      properly negotiated with the client. This can be exploited through a
      Denial of Service attack.

      Thanks to Joonas Kuorilehto and Riku Hietamäki (Codenomicon) for
      discovering and researching this issue.
      (CVE-2014-5139)
      [Steve Henson]

   *) A flaw in OBJ_obj2txt may cause pretty printing functions such as
      X509_name_oneline, X509_name_print_ex et al. to leak some information
      from the stack. Applications may be affected if they echo pretty printing
      output to the attacker.

      Thanks to Ivan Fratric (Google) for discovering this issue.
      (CVE-2014-3508)
      [Emilia Käsper, and Steve Henson]

   *) Fix ec_GFp_simple_points_make_affine (thus, EC_POINTs_mul etc.)
      for corner cases. (Certain input points at infinity could lead to
      bogus results, with non-infinity inputs mapped to infinity too.)
      [Bodo Moeller]


-------------------------------------------------------------------------------


   The port has been compiled using stock djdev203 (patchlevel 2) and consists
   of two packages that can be downloaded from ftp.delorie.com and mirrors as
   (time stamp 2014-08-09):

     OpenSSL 1.0.1i binary, headers, libraries and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101ib.zip

     OpenSSL 1.0.1i source:
     ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101is.zip


   The binaries have been produced a second time using a patched version
   of the C library compiled from the repository code.  This package is
   available at ftp.delorie.com and mirrors as (time stamp 2014-08-09):

     OpenSSL 1.0.1i binary, headers, libraries and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101ib.zip


   Send openssl specific bug reports to <openssl-bugs AT openssl DOT org>.
   Send suggestions and bug reports concerning the DJGPP port to
   comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.
   If you are not sure if the failure is really a openssl failure
   or a djgpp specific failure, report it here and *not* to
   <openssl-bugs AT openssl DOT org>.

Enjoy.

     Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>