148 lines
6.4 KiB
Text
148 lines
6.4 KiB
Text
|
|
OpenSSL STATUS Last modified at
|
|
______________ $Date: 1999/05/12 01:52:58 $
|
|
|
|
DEVELOPMENT STATE
|
|
|
|
o OpenSSL 0.9.3: Under development...
|
|
Proposed freeze date: Mon May 17th, 1999
|
|
Proposed release date: Mon May 24th, 1999
|
|
Release manager: Ben
|
|
o OpenSSL 0.9.2b: Released on March 22th, 1999
|
|
o OpenSSL 0.9.1c: Released on December 23th, 1998
|
|
|
|
[ Proposed new numbering scheme: <major>.<minor>[<patchlevel>]
|
|
0.9.1c is 0913
|
|
1.0 is 010000
|
|
1.0 a is 010001
|
|
1.8 z is 01081a ]
|
|
|
|
RELEASE SHOWSTOPPERS
|
|
|
|
o BSD/OS: assembler functions must not have leading underscores
|
|
o exptest and rsa_oaep_test fail with irix64-*
|
|
(Don Badrak <dbadrak@geo.census.gov>: "Re: Problems to compile openssl
|
|
on IRIX 6.2", openssl-users)
|
|
o const des_cblock problem
|
|
|
|
AVAILABLE PATCHES
|
|
|
|
o OCSP (titchenert@certco.com)
|
|
o getenv in ca.c and x509_def.c (jaltman@watsun.cc.columbia.edu)
|
|
|
|
IN PROGRESS
|
|
|
|
o Steve is currently working on (in no particular order):
|
|
Proper (or at least usable) certificate chain verification.
|
|
Documentation on X509 V3 extension code.
|
|
PKCS #8 and PKCS#5 v2.0 support.
|
|
Private key, certificate and CRL API and implementation.
|
|
Checking and bugfixing PKCS#7 (S/MIME code).
|
|
|
|
o Mark is currently working on:
|
|
Folding in any changes that are in the C2Net code base that were
|
|
not in the original SSLeay-0.9.1.b release. Plus other minor
|
|
tidying.
|
|
|
|
o Ralf is currently working on:
|
|
1. Support for SSL_set_default_verify_paths(),
|
|
SSL_load_verify_locations(), SSL_get_cert_store() and
|
|
SSL_set_cert_store() functions which work like their existing
|
|
SSL_CTX_xxx() variants but on a per connection basis. That's needed
|
|
to let us provide full-featured per-URL client verification in
|
|
mod_ssl or Apache-SSL.
|
|
=> It still dumps core, so I suspend this and investigate
|
|
again for OpenSSL 0.9.3.
|
|
2. The perl/ stuff to make it really work the first time ;-)
|
|
=> I'll investigate a few more hours for OpenSSL 0.9.2
|
|
3. The new documentation set in POD format under doc/
|
|
=> I'll investigate a few more hours for OpenSSL 0.9.2
|
|
4. More cleanups to get rid of obsolete/old/ugly files in the
|
|
source tree which are not really needed.
|
|
=> Done all which were possible with my personal knowledge
|
|
|
|
o Ben is currently working on:
|
|
1. Function Prototype Thought Police issues.
|
|
2. Integrated documentation.
|
|
3. New TLS Ciphersuites.
|
|
4. Anything else that takes his fancy.
|
|
|
|
NEEDS PATCH
|
|
|
|
o broken demos
|
|
o salzr@certco.com (Rich Salz): Bug in X509_name_print
|
|
<29E0A6D39ABED111A36000A0C99609CA2C2BA4@macertco-srv1.ma.certco.com>
|
|
o Compilation warnings: ctype-related int vs. char
|
|
o $(PERL) in */Makefile.ssl
|
|
o "Sign the certificate?" - "n" creates empty certificate file
|
|
o dubious declaration of crypt() in des.h
|
|
|
|
OPEN ISSUES
|
|
|
|
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
|
|
Ralf has done for the Apache src/Configure script. Ben wants the
|
|
solution to be really simple.
|
|
|
|
Status: Ralf will look how we can easily incorporate the
|
|
compiler PIC and linker DSO flags from Apache
|
|
into the OpenSSL Configure script.
|
|
|
|
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
|
|
Net::SSLeay package we can find under
|
|
http://www.neuronio.pt/SSLeay.pm.html. Ralf uses this package for a
|
|
longer time and it works fine and is a nice Perl module. Best would be
|
|
to convince the author to work for the OpenSSL project and create a
|
|
Net::OpenSSL or Crypt::OpenSSL package out of it and maintains it for
|
|
us.
|
|
|
|
Status: Ralf thinks we should both contact the author of Net::SSLeay
|
|
and look how much effort it is to bring Eric's perl/ stuff up
|
|
to date.
|
|
Paul +1
|
|
|
|
o The EVP and ASN1 stuff is a mess. Currently you have one EVP_CIPHER
|
|
structure for each cipher. This may make sense for things like DES but
|
|
for variable length ciphers like RC2 and RC4 it is NBG. Need a way to
|
|
use the EVP interface and set up the cipher parameters. The ASN1 stuff
|
|
is also foo wrt ciphers whose AlgorithmIdentifier has more than just
|
|
an IV in it (e.g. RC2, RC5). This also means that EVP_Seal and EVP_Open
|
|
don't work unless the key length matches the fixed value (some vendors
|
|
use a key length decided by the size of the RSA encrypted key and expect
|
|
RC2 to adapt).
|
|
|
|
o Properly initialize the PRNG in the absence of /dev/random.
|
|
|
|
o ERR_error_string(..., buf) does not know how large buf is,
|
|
there should be ERR_error_string_n(..., buf, bufsize)
|
|
or similar.
|
|
|
|
WISHES
|
|
|
|
o Damien Miller:
|
|
"How about making the each of the locations compile-time defined. I
|
|
would like to (for example) put binaries in /usr/bin, configuration
|
|
data, certs and keys in /etc/openssl/certs and /etc/openssl/keys, etc.
|
|
This would also be a great boon to binary package makers. The
|
|
SSLeay-0.9.1b RPM already includes some patches which do some of this.
|
|
I can forward them if you wish."
|
|
|
|
o Mats Nilsson <mats.nilsson@xware.se>:
|
|
"Add reference counting to all substructures of X509 etc. For instance,
|
|
X509_NAME lacks a reference counter, while EVP_PKEY has one. I'm
|
|
making COM-wrappers for selected parts of SSLeay for a project of ours,
|
|
and has found this inconsistency in copy semantics annoying."
|
|
|