OpenSSL STATUS Last modified at
- ______________ $Date: 1999/01/01 15:58:14 $
+ ______________ $Date: 2001/07/17 14:39:26 $
DEVELOPMENT STATE
- o OpenSSL 0.9.2: Under development.
- o OpenSSL 0.9.1c: Released on December 23th, 1998
+ o OpenSSL 0.9.7: Under development...
+ o OpenSSL 0.9.6b: Released on July 9th, 2001
+ o OpenSSL 0.9.6a: Released on April 5th, 2001
+ o OpenSSL 0.9.6: Released on September 24th, 2000
+ o OpenSSL 0.9.5a: Released on April 1st, 2000
+ o OpenSSL 0.9.5: Released on February 28th, 2000
+ o OpenSSL 0.9.4: Released on August 09th, 1999
+ o OpenSSL 0.9.3a: Released on May 29th, 1999
+ o OpenSSL 0.9.3: Released on May 25th, 1999
+ o OpenSSL 0.9.2b: Released on March 22th, 1999
+ o OpenSSL 0.9.1c: Released on December 23th, 1998
RELEASE SHOWSTOPPERS
AVAILABLE PATCHES
+ o IA-64 (a.k.a. Intel Itanium) public-key operation performance
+ patch for Linux is available for download at
+ http://www.openssl.org/~appro/096b.linux-ia64.diff. As URL
+ suggests the patch is relative to OpenSSL 0.9.6b.
+
IN PROGRESS
- o Ben is folding in his patches
+ o Steve is currently working on (in no particular order):
+ ASN1 code redesign, butchery, replacement.
+ OCSP
+ EVP cipher enhancement.
+ Enhanced certificate chain verification.
+ Private key, certificate and CRL API and implementation.
+ Developing and bugfixing PKCS#7 (S/MIME code).
+ Various X509 issues: character sets, certificate request extensions.
+ o Geoff and Richard are currently working on:
+ ENGINE (the new code that gives hardware support among others).
+ o Richard is currently working on:
+ UI (User Interface)
+ UTIL (a new set of library functions to support some higher level
+ functionality that is currently missing).
+ Shared library support for VMS.
+ Kerberos 5 authentication
+ Constification
+ OCSP
NEEDS PATCH
+ o apps/ca.c: "Sign the certificate?" - "n" creates empty certificate file
+
+ o OpenSSL_0_9_6-stable:
+ #include <openssl/e_os.h> in exported header files is illegal since
+ e_os.h is suitable only for library-internal use.
+
+ o Whenever strncpy is used, make sure the resulting string is NULL-terminated
+ or an error is reported
+
OPEN ISSUES
- o The apps/ dir should be cleaned up.
- Ralf proposes the following cleanup:
- 1. We rename the ssleay program to openssl.
- => This way it's consistent with out project and
- with the already started openssl(1) manpage, etc.
- 2. We no longer create such a lot of <command> links for
- "openssl <command>". Instead we follow the "cvs" interface idea
- where all <command>s are called as "cvs <command>".
- => This no longer messes up the install dir with
- symlinks and provides a single-one and consistent command line
- interface. Additionally we can document it nicely with the single
- already started openssl(1) manual page.
- Status: Ralf +1
-
- o The installation under "make install" produces a very
- installation layout: $prefix/certs and $prefix/private dirs. That's
- not nice. Ralf suggests to move the two certs and private dirs either
- to $prefix/etc/, $prefix/lib/ or $prefix/share. Alternatively
- we could also not install the certs at all.
-
- Status: Ralf +1 for both not installing the certs at all and
- moving it to $prefix/etc/. +0 for $prefix/lib/
- and $prefix/share.
- Paul: why is it not nice?
- Ralf: because it messes up the install dir when
- $prefix is not a dedicated area like /usr/local/ssl.
- When we move them to a standard subdir like
- etc/ lib/ or share/ we don't mess up things
- when $prefix is /usr or /usr/local, etc.
- Additionally it makes package vendors life
- easier....
+ o crypto/ex_data.c is not really thread-safe and so must be used
+ with care (e.g., extra locking where necessary, or don't call
+ CRYPTO_get_ex_new_index once multiple threads exist).
+ The current API is not suitable for everything that it pretends
+ to offer.
+
+ o The Makefile hierarchy and build mechanism is still not a round thing:
+
+ 1. The config vs. Configure scripts
+ It's the same nasty situation as for Apache with APACI vs.
+ src/Configure. It confuses.
+ Suggestion: Merge Configure and config into a single configure
+ script with a Autoconf style interface ;-) and remove
+ Configure and config. Or even let us use GNU Autoconf
+ itself. Then we can avoid a lot of those platform checks
+ which are currently in Configure.
o Support for Shared Libraries has to be added at least
for the major Unix platforms. The details we can rip from the stuff
compiler PIC and linker DSO flags from Apache
into the OpenSSL Configure script.
+ Ulf: +1 for using GNU autoconf and libtool (but not automake,
+ which apparently is not flexible enough to generate
+ libcrypto)
+
+
o The perl/ stuff needs a major overhaul. Currently it's
totally obsolete. Either we clean it up and enhance it to be up-to-date
with the C code or we also could replace it with the really nice
to date.
Paul +1
- o Ralf has ported Stephen's pkcs12 program to OpenSSL (the
- ASN.1 stuff Eric recently changed :-( ), but needs some help from
- Stephen at two source locations. Stephen itself also has ported his
- internal pkcs12 0.53 version to OpenSSL, but thinks we still shouldn't
- incorporate it into OpenSSL because it needs more cleanups. Ralf still
- thinks pkcs12 should be incorporated better now than later because it's
- nasty to not have it in the core - one always has to install it
- manually and a lot of people use it. So, should we incorporate it?
- BTW, we have to be carefully because of the pkcs12 license: There are
- some things which don't match the OpenSSL license, so Stephen has to
- change it for us when we want to incorporate the code.
-
- Status: Ralf +1, Stephen -0
+ WISHES
+
+ o SRP in TLS.
+ [wished by:
+ Dj <derek@yo.net>, Tom Wu <tom@arcot.com>,
+ Tom Holroyd <tomh@po.crl.go.jp>]
+
+ See http://search.ietf.org/internet-drafts/draft-ietf-tls-srp-00.txt
+ as well as http://www-cs-students.stanford.edu/~tjw/srp/.
+
+ Tom Holroyd tells us there is a SRP patch for OpenSSH at
+ http://members.tripod.com/professor_tom/archives/, that could
+ be useful.
projects / openssl.git / blobdiff