changes.ssleay

mediastreamer2是开源的网络传输媒体流的库

- ssl/ssltest.c - one process talking SSL to its self for testing.
- Storage of Session-id's can be controled via a session_cache_mode
  flag.  There is also now an automatic default flushing of 
  old session-id's.
- The X509_cert_verify() function now has another parameter, this
  should not effect most people but it now means that the reason for
  the failure to verify is now available via SSL_get_verify_result(ssl).
  You don't have to use a global variable.
- SSL_get_app_data() and SSL_set_app_data() can be used to keep some
  application data against the SSL structure.  It is upto the application
  to free the data.  I don't use it, but it is available.
- SSL_CTX_set_cert_verify_callback() can be used to specify a
  verify callback function that completly replaces my certificate
  verification code.  Xcert should be able to use this :-).
  The callback is of the form int app_verify_callback(arg,ssl,cert).
  This needs to be documented more.
- I have started playing with shared library builds, have a look in
  the shlib directory.  It is very simple.  If you need a numbered
  list of functions, have a look at misc/crypto.num and misc/ssl.num.
- There is some stuff to do locking to make the library thread safe.
  I have only started this stuff and have not finished.  If anyone is
  keen to do so, please send me the patches when finished.

So I have finally made most of the additions to the SSL interface that
I thought were needed.

There will probably be a pause before I make any non-bug/documentation
related changes to SSLeay since I'm feeling like a bit of a break.

eric - 12 Jul 1996
I saw recently a comment by some-one that we now seem to be entering
the age of perpetual Beta software.
Pioneered by packages like linux but refined to an art form by
netscape.

I too wish to join this trend with the anouncement of SSLeay 0.6.0 :-).

There are quite a large number of sections that are 'works in
progress' in this package.  I will also list the major changes and
what files you should read.

BIO - this is the new IO structure being used everywhere in SSLeay.  I
started out developing this because of microsoft, I wanted a mechanism
to callback to the application for all IO, so Windows 3.1 DLL
perversion could be hidden from me and the 15 different ways to write
to a file under NT would also not be dictated by me at library build
time.  What the 'package' is is an API for a data structure containing
functions.  IO interfaces can be written to conform to the
specification.  This in not intended to hide the underlying data type
from the application, but to hide it from SSLeay :-).
I have only really finished testing the FILE * and socket/fd modules.
There are also 'filter' BIO's.  Currently I have only implemented
message digests, and it is in use in the dgst application.  This
functionality will allow base64/encrypto/buffering modules to be
'push' into a BIO without it affecting the semantics.  I'm also
working on an SSL BIO which will hide the SSL_accept()/SLL_connet()
from an event loop which uses the interface.
It is also possible to 'attach' callbacks to a BIO so they get called
before and after each operation, alowing extensive debug output
to be generated (try running dgst with -d).

Unfortunaly in the conversion from 0.5.x to 0.6.0, quite a few
functions that used to take FILE *, now take BIO *.
The wrappers are easy to write

function_fp(fp,x)
FILE *fp;
    {
    BIO *b;
    int ret;

    if ((b=BIO_new(BIO_s_file())) == NULL) error.....
    BIO_set_fp(b,fp,BIO_NOCLOSE);
    ret=function_bio(b,x);
    BIO_free(b);
    return(ret);
    }
Remember, there are no functions that take FILE * in SSLeay when
compiled for Windows 3.1 DLL's.

--
I have added a general EVP_PKEY type that can hold a public/private
key.  This is now what is used by the EVP_ functions and is passed
around internally.  I still have not done the PKCS#8 stuff, but
X509_PKEY is defined and waiting :-)

--
For a full function name listings, have a look at ms/crypt32.def and
ms/ssl32.def.  These are auto-generated but are complete.
Things like ASN1_INTEGER_get() have been added and are in here if you
look.  I have renamed a few things, again, have a look through the
function list and you will probably find what you are after.  I intend
to at least put a one line descrition for each one.....

--
Microsoft - thats what this release is about, read the MICROSOFT file.

--
Multi-threading support.  I have started hunting through the code and
flaging where things need to be done.  In a state of work but high on
the list.

--
For random numbers, edit e_os.h and set DEVRANDOM (it's near the top)
be be you random data device, otherwise 'RFILE' in e_os.h
will be used, in your home directory.  It will be updated
periodically.  The environment variable RANDFILE will override this
choice and read/write to that file instead.  DEVRANDOM is used in
conjunction to the RFILE/RANDFILE.  If you wish to 'seed' the random
number generator, pick on one of these files.

--

The list of things to read and do

dgst -d
s_client -state (this uses a callback placed in the SSL state loop and
        will be used else-where to help debug/monitor what
        is happening.)

doc/why.doc
doc/bio.doc <- hmmm, needs lots of work.
doc/bss_file.doc <- one that is working :-)
doc/session.doc <- it has changed
doc/speed.doc
 also play with ssleay version -a.  I have now added a SSLeay()
 function that returns a version number, eg 0600 for this release
 which is primarily to be used to check DLL version against the
 application.
util/*  Quite a few will not interest people, but some may, like
 mk1mf.pl, mkdef.pl,
util/do_ms.sh

try
cc -Iinclude -Icrypto -c crypto/crypto.c
cc -Iinclude -Issl -c ssl/ssl.c
You have just built the SSLeay libraries as 2 object files :-)

Have a general rummage around in the bin stall directory and look at
what is in there, like CA.sh and c_rehash

There are lots more things but it is 12:30am on a Friday night and I'm
heading home :-).

eric 22-Jun-1996
This version has quite a few major bug fixes and improvements.  It DOES NOT
do SSLv3 yet.

The main things changed
- A Few days ago I added the s_mult application to ssleay which is
  a demo of an SSL server running in an event loop type thing.
  It supports non-blocking IO, I have finally gotten it right, SSL_accept()
  can operate in non-blocking IO mode, look at the code to see how :-).
  Have a read of doc/s_mult as well.  This program leaks memory and
  file descriptors everywhere but I have not cleaned it up yet.
  This is a demo of how to do non-blocking IO.
- The SSL session management has been 'worked over' and there is now
  quite an expansive set of functions to manipulate them.  Have a read of
  doc/session.doc for some-things I quickly whipped up about how it now works.
  This assume you know the SSLv2 protocol :-)
- I can now read/write the netscape certificate format, use the
  -inform/-outform  'net' options to the x509 command.  I have not put support
  for this type in the other demo programs, but it would be easy to add.
- asn1parse and 'enc' have been modified so that when reading base64
  encoded files (pem format), they do not require '-----BEGIN' header lines.
  The 'enc' program had a buffering bug fixed, it can be used as a general
  base64 -> binary -> base64 filter by doing 'enc -a -e' and 'enc -a -d'
  respecivly.  Leaving out the '-a' flag in this case makes the 'enc' command
  into a form of 'cat'.
- The 'x509' and 'req' programs have been fixed and modified a little so
  that they generate self-signed certificates correctly.  The test
  script actually generates a 'CA' certificate and then 'signs' a
  'user' certificate.  Have a look at this shell script (test/sstest)
  to see how things work, it tests most possible combinations of what can
  be done.
- The 'SSL_set_pref_cipher()' function has been 'fixed' and the prefered name
  of SSL_set_cipher_list() is now the correct API (stops confusion :-).
  If this function is used in the client, only the specified ciphers can
  be used, with preference given to the order the ciphers were listed.
  For the server, if this is used, only the specified ciphers will be used
  to accept connections.  If this 'option' is not used, a default set of
  ciphers will be used.  The SSL_CTX_set_cipher_list(SSL_CTX *ctx) sets this
  list for all ciphers started against the SSL_CTX.  So the order is
  SSL cipher_list, if not present, SSL_CTX cipher list, if not
  present, then the library default.
  What this means is that normally ciphers like
  NULL-MD5 will never be used.  The only way this cipher can be used
  for both ends to specify to use it.
  To enable or disable ciphers in the library at build time, modify the
  first field for the cipher in the ssl_ciphers array in ssl/ssl_lib.c.
  This file also contains the 'pref_cipher' list which is the default
  cipher preference order.
- I'm not currently sure if the 'rsa -inform net' and the 'rsa -outform net'
  options work.  They should, and they enable loading and writing the
  netscape rsa private key format.  I will be re-working this section of
  SSLeay for the next version.  What is currently in place is a quick and
  dirty hack.
- I've re-written parts of the bignum library.  This gives speedups
  for all platforms.  I now provide assembler for use under Windows NT.
  I have not tested the Windows 3.1 assembler but it is quite simple code.
  This gives RSAprivate_key operation encryption times of 0.047s (512bit key)
  and 0.230s (1024bit key) on a pentium 100 which I consider reasonable.
  Basically the times available under linux/solaris x86 can be achieve under
  Windows NT.  I still don't know how these times compare to RSA's BSAFE
  library but I have been emailing with people and with their help, I should
  be able to get my library's quite a bit faster still (more algorithm changes).
  The object file crypto/bn/asm/x86-32.obj should be used when linking
  under NT.
- 'make makefile.one' in the top directory will generate a single makefile
  called 'makefile.one'  This makefile contains no perl references and
  will build the SSLeay library into the 'tmp' and 'out' directories.
  util/mk1mf.pl >makefile.one is how this makefile is
  generated.  The mk1mf.pl command take several option to generate the
  makefile for use with cc, gcc, Visual C++ and Borland C++.  This is
  still under development.  I have only build .lib's for NT and MSDOS
  I will be working on this more.  I still need to play with the
  correct compiler setups for these compilers and add some more stuff but
  basically if you just want to compile the library
  on a 'non-unix' platform, this is a very very good file to start with :-).
  Have a look in the 'microsoft' directory for my current makefiles.
  I have not yet modified things to link with sockets under Windows NT.
  You guys should be able to do this since this is actually outside of the
  SSLeay scope :-).  I will be doing it for myself soon.
  util/mk1mf.pl takes quite a few options including no-rc, rsaref  and no-sock
  to build without RC2/RC4, to require RSAref for linking, and to
  build with no socket code.

- Oh yes, the cipher that was reported to be compatible with RSA's RC2 cipher
  that was posted to sci.crypt has been added to the library and SSL.
  I take the view that if RC2 is going to be included in a standard,
  I'll include the cipher to make my package complete.
  There are NO_RC2, NO_RC4 and NO_IDEA macros to remove these ciphers
  at compile time.  I have not tested this recently but it should all work
  and if you are in the USA and don't want RSA threatening to sue you,
  you could probably remove the RC4/RC2 code inside these sections.
  I may in the future include a perl script that does this code
  removal automatically for those in the USA :-).
- I have removed all references to sed in the makefiles.  So basically,
  the development environment requires perl and sh.  The build environment
  does not (use the makefile.one makefile).
  The Configure script still requires perl, this will probably stay that way
  since I have perl for Windows NT :-).

eric (03-May-1996)

PS Have a look in the VERSION file for more details on the changes and
   bug fixes.
I have fixed a few bugs, added alpha and x86 assembler and generally cleaned
things up.  This version will be quite stable, mostly because I'm on
holidays until 10-March-1996.  For any problems in the interum, send email
to Tim Hudson <[e-mail]>.

SSLeay 0.5.0

12-12-95
This is going out before it should really be released.

I leave for 11 weeks holidays on the 22-12-95 and so I either sit on
this for 11 weeks or get things out.  It is still going to change a
lot in the next week so if you do grab this version, please test and
give me feed back ASAP, inculuding questions on how to do things with
the library.  This will prompt me to write documentation so I don't
have to answer the same question again :-).

This 'pre' release version is for people who are interested in the
library.  The applications will have to be changed to use
the new version of the SSL interface.  I intend to finish more
documentation before I leave but until then, look at the programs in
the apps directory.  As far as code goes, it is much much nicer than
the old version.

The current library works, has no memory leaks (as far as I can tell)
and is far more bug free that 0.4.5d.  There are no global variable of
consequence (I believe) and I will produce some documentation that
tell where to look for those people that do want to do multi-threaded
stuff.

There should be more documentation.  Have a look in the
doc directory.  I'll be adding more before I leave, it is a start
by mostly documents the crypto library.  Tim Hudson will update
the web page ASAP.  The spelling and grammar are crap but
it is better than nothing :-)

Reasons to start playing with version 0.5.0
- All the programs in the apps directory build into one ssleay binary.
- There is a new version of the 'req' program that generates certificate
  requests, there is even documentation for this one :-)
- There is a demo certification authorithy program.  Currently it will
  look at the simple database and update it.  It will generate CRL from
  the data base.  You need to edit the database by hand to revoke a
  certificate, it is my aim to use perl5/Tk but I don't have time to do
  this right now.  It will generate the certificates but the management
  scripts still need to be written.  This is not a hard task.
- Things have been cleaned up alot.
- Have a look at the enc and dgst programs in the apps directory.
- It supports v3 of x509 certiticates.


Major things missing.
- I have been working on (and thinging about) the distributed x509
  hierachy problem.  I have not had time to put my solution in place.
  It will have to wait until I come back.
- I have not put in CRL checking in the certificate verification but
  it would not be hard to do.  I was waiting until I could generate my
  own CRL (which has only been in the last week) and I don't have time
  to put it in correctly.
- Montgomery multiplication need to be implemented.  I know the
  algorithm, just ran out of time.
- PKCS#7.  I can load and write the DER version.  I need to re-work
  things to support BER (if that means nothing, read the ASN1 spec :-).
- Testing of the higher level digital envelope routines.  I have not
  played with the *_seal() and *_open() type functions.  They are
  written but need testing.  The *_sign() and *_verify() functions are
  rock solid. 
- PEM.  Doing this and PKCS#7 have been dependant on the distributed
  x509 heirachy problem.  I started implementing my ideas, got
  distracted writing a CA program and then ran out of time.  I provide
  the functionality of RSAref at least.
- Re work the asm. code for the x86.  I've changed by low level bignum
  interface again, so I really need to tweak the x86 stuff.  gcc is
  good enough for the other boxes.