I think this change is needed if you want EVP_CipherInit() to have a
similar semantic as in OpenSSL 0.9.6.
Index: evp/evp_enc.c
===================================================================
RCS file: /cvs/openssl/crypto/evp/evp_enc.c,v
retrieving revision 1.28
diff -u -r1.28 evp_enc.c
--- evp/evp_enc.c 17 Oct 2001 00:36:34 -0000 1.28
+++ evp/evp_enc.c 13 Feb 2002 10:28:05 -0000
@@ -77,7 +77,8 @@
int EVP_CipherInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher,
const unsigned char *key, const unsigned char *iv, int enc)
{
- EVP_CIPHER_CTX_init(ctx);
+ if (cipher)
+ EVP_CIPHER_CTX_init(ctx);
return EVP_CipherInit_ex(ctx,cipher,NULL,key,iv,enc);
}
Otherwise you will break code like:
EVP_CIPHER_CTX c;
EVP_CIPHER_CTX_init(&c);
EVP_CipherInit(&c, cipher, NULL, iv, enc);
/* adjust keylength */
EVP_CIPHER_CTX_set_key_length(&c, keylen)
EVP_CipherInit(&c, NULL, key, NULL, -1);
Generally I think the way 0.9.7 introduces subtle changes into the
existing API is dangerous. Considering how many people deploy and
depend on your library, you should rather opt for adding a completely
new API than fixing bugs of the existing API by introducing subtle
semantic changes.
There could be more problems with other XXX_Init() or similar
functions, so all semantic changes to functions from the 0.9.6 API
should be reconsidered. All such changes could be a threat to existing
applications and break them in subtle ways -- and this must be
avoided.
Even if you consider your API unstable and subject to change -- your
users don't. You cannot undo the success of your library :)
As to EVP_CipherInit(): I think EVP_CipherInit should not cause
EVP_CipherInit_ex() to look for an engine, as this deviates from the
0.9.6 behaviour. Perhaps is better to pass 'engine==NO_ENGINE',
instead of 'engine==NULL' to EVP_CipherInit_ex().
-m
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
