in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers. So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes. Argh.
the secret key before we've encrypted it and using the right NID for RC2-64.
Add various arguments to the experimental programs 'dec' and 'enc' to make
testing less painful.
This stuff has now been tested against Netscape Messenger and it can encrypt
and decrypt S/MIME messages with RC2 (128, 64 and 40 bit) DES and triple DES.
Its still experimental though...
(meaning pointer to char) to des_cblock * (meaning pointer to
array with 8 char elements), which allows the compiler to
do more typechecking. (The changed argument types were of type
des_cblock * back in SSLeay, and a lot of ugly casts were
used then to turn them into pointers to elements; but it can be
done without those casts.)
Introduce new type const_des_cblock -- before, the pointers rather
than the elements pointed to were declared const, and for
some reason gcc did not complain about this (but some other
compilers did).
While modifying the sources, I found some inconsistencies on the use of
s->cert vs. s->session->sess_cert; I don't know if those could
really have caused problems, but possibly this is a proper bug-fix
and not just a clean-up.
Fixed -strparse option: it didn't work if used more than once (this was due
to the d2i_ASN1_TYPE call parsing a freed buffer). On Win32 the file wincrypt.h
#define's X509_NAME and PKCS7_SIGNER_INFO causing clashes so these are #undef'ed
Win32 version of rename() ). There isn't a precise rename() equivalent under
Win95: the standard rename() complains if the destination already exists so
replaced with a combination of unlink() and MoveFile().
been changed so that it almost could be used under Windows.
No one asked to keep it (and no one volunteered to bring it into useable
state), so away with it.
Submitted by:
Reviewed by:
PR:
PS: Feel free to move the IMPLEMENT_STACK_OF(X509_INFO) from
crypto/asn1/x_info.c to any other place where you think it fits better.
X509_INFO is a structure slightly spreaded over ASN.1, X509 and PEM code,
so I found no definitive location for IMPLEMENT_STACK_OF(X509_INFO). In
crypto/asn1/x_info.c it's at least now bundled with X509_INFO_new() and
friends.
