X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Message-Id: <201410181932.s9IJWg1x017446@delorie.com> Date: Sat, 18 Oct 2014 16:33:23 +0200 From: Juan Manuel Guerrero To: djgpp-announce AT delorie DOT com Subject: ANNOUNCE: DJGPP port of OpenSSL 1.0.1j 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.1j 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. Neitherless 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: 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 port has been configured and compiled on WinXP SP3. There is no guarantee that this may be possible with any other DOS-like OS. Due to the massive use of long file names it will not be possible to configure and compile without LFN support. - The DJGPP 2.03 version of the port has been compiled using gcc473 and bnu224br2. The DJGPP 2.04 version of the port 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 01:30 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.1i and 1.0.1j [15 Oct 2014] *) SRTP Memory Leak. A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected. The fix was developed by the OpenSSL team. (CVE-2014-3513) [OpenSSL team] *) Session Ticket Memory Leak. When an OpenSSL SSL/TLS/DTLS server receives a session ticket the integrity of that ticket is first verified. In the event of a session ticket integrity check failing, OpenSSL will fail to free memory causing a memory leak. By sending a large number of invalid session tickets an attacker could exploit this issue in a Denial Of Service attack. (CVE-2014-3567) [Steve Henson] *) Build option no-ssl3 is incomplete. When OpenSSL is configured with "no-ssl3" as a build option, servers could accept and complete a SSL 3.0 handshake, and clients could be configured to send them. (CVE-2014-3568) [Akamai and the OpenSSL team] *) Add support for TLS_FALLBACK_SCSV. Client applications doing fallback retries should call SSL_set_mode(s, SSL_MODE_SEND_FALLBACK_SCSV). (CVE-2014-3566) [Adam Langley, Bodo Moeller] *) Add additional DigestInfo checks. Reencode DigestInto in DER and check against the original when verifying RSA signature: this will reject any improperly encoded DigestInfo structures. Note: this is a precautionary measure and no attacks are currently known. [Steve Henson] ------------------------------------------------------------------------------- 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-10-17): OpenSSL 1.0.1j binary, headers, libraries and man format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101jb.zip OpenSSL 1.0.1j source: ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101js.zip The binaries and library have been produced a second time using a libc.a version compiled from current repository code and patched with the new malloc code. This package is available at ftp.delorie.com and mirrors as (times tamp 2014-10-17): OpenSSL 1.0.1j binary, headers, libraries and man format documentation: ftp://ftp.delorie.com/pub/djgpp/current/v2tk/ssl101jb.zip Send openssl specific bug reports to . Send suggestions and bug reports concerning the DJGPP port to comp.os.msdos.djgpp or . If you are not sure if the failure is really a openssl failure or a djgpp specific failure, report it here and *not* to . Enjoy. Guerrero, Juan Manuel