Add functions des_set_key_checked, des_set_key_unchecked.
[openssl.git] / CHANGES
diff --git a/CHANGES b/CHANGES
index 3261ecea27cd83778ca85bf3dc7c66d2ec862aef..247d65a001df52ee1554eb593e8f720f3c740084 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -4,6 +4,56 @@
 
  Changes between 0.9.4 and 0.9.5  [xx XXX 1999]
 
+  *) Add variants des_set_key_checked and des_set_key_unchecked of
+     des_set_key (aka des_key_sched).  Global variable des_check_key
+     decides which of these is called by des_set_key; this way
+     des_check_key behaves as it always did, but applications and
+     the library itself, which was buggy for des_check_key == 1,
+     have a cleaner way to pick the version they need.
+     [Bodo Moeller]
+
+  *) New function PKCS12_newpass() which changes the password of a
+     PKCS12 structure.
+     [Steve Henson]
+
+  *) Modify X509_TRUST and X509_PURPOSE so it also uses a static and
+     dynamic mix. In both cases the ids can be used as an index into the
+     table. Also modified the X509_TRUST_add() and X509_PURPOSE_add()
+     functions so they accept a list of the field values and the
+     application doesn't need to directly manipulate the X509_TRUST
+     structure.
+     [Steve Henson]
+
+  *) Modify the ASN1_STRING_TABLE stuff so it also uses bsearch and doesn't
+     need initialising.
+     [Steve Henson]
+
+  *) Modify the way the V3 extension code looks up extensions. This now
+     works in a similar way to the object code: we have some "standard"
+     extensions in a static table which is searched with OBJ_bsearch()
+     and the application can add dynamic ones if needed. The file
+     crypto/x509v3/ext_dat.h now has the info: this file needs to be
+     updated whenever a new extension is added to the core code and kept
+     in ext_nid order. There is a simple program 'tabtest.c' which checks
+     this. New extensions are not added too often so this file can readily
+     be maintained manually.
+
+     There are two big advantages in doing things this way. The extensions
+     can be looked up immediately and no longer need to be "added" using
+     X509V3_add_standard_extensions(): this function now does nothing.
+     [Side note: I get *lots* of email saying the extension code doesn't
+      work because people forget to call this function]
+     Also no dynamic allocation is done unless new extensions are added:
+     so if we don't add custom extensions there is no need to call
+     X509V3_EXT_cleanup().
+     [Steve Henson]
+
+  *) Modify enc utility's salting as follows: make salting the default. Add a
+     magic header, so unsalted files fail gracefully instead of just decrypting
+     to garbage. This is because not salting is a big security hole, so people
+     should be discouraged from doing it.
+     [Ben Laurie]
+
   *) Fixes and enhancements to the 'x509' utility. It allowed a message
      digest to be passed on the command line but it only used this
      parameter when signing a certificate. Modified so all relevant
      DSA key was used because it didn't fix the digest.
      [Steve Henson]
 
-  *) Very preliminary certificate chain verify code. Currently just tests
-     the untrusted certificates for consistency with the verify purpose
-     (which is set when the X509_STORE_CTX structure is set up) and checks
-     the pathlength. There is a NO_CHAIN_VERIFY compilation option to keep
-     the old behaviour: this is because when it is finally working it will
-     reject chains with invalid extensions whereas before it made no checks
-     at all.
+  *) Initial certificate chain verify code. Currently tests the untrusted
+     certificates for consistency with the verify purpose (which is set
+     when the X509_STORE_CTX structure is set up) and checks the pathlength.
+
+     There is a NO_CHAIN_VERIFY compilation option to keep the old behaviour:
+     this is because it will reject chains with invalid extensions whereas
+     every previous version of OpenSSL and SSLeay made no checks at all.
 
-     Preliminary untested trust code. 
+     Trust code: checks the root CA for the relevant trust settings. Trust
+     settings have an initial value consistent with the verify purpose: e.g.
+     if the verify purpose is for SSL client use it expects the CA to be
+     trusted for SSL client use. However the default value can be changed to
+     permit custom trust settings: one example of this would be to only trust
+     certificates from a specific "secure" set of CAs.
 
      Also added X509_STORE_CTX_new() and X509_STORE_CTX_free() functions
      which should be used for version portability: especially since the
      verify structure is likely to change more often now.
 
+     SSL integration. Add purpose and trust to SSL_CTX and SSL and functions
+     to set them. If not set then assume SSL clients will verify SSL servers
+     and vice versa.
+
      Two new options to the verify program: -untrusted allows a set of
      untrusted certificates to be passed in and -purpose which sets the
      intended purpose of the certificate. If a purpose is set then the