| Age | Commit message (Collapse) | Author |
|---|
|
Make sure crypto.h is included first in any affected files.
|
|
|
|
|
|
|
|
Use BUF_strlcat() instead of strcat().
Use BIO_snprintf() instead of sprintf().
In some cases, keep better track of buffer lengths.
This is part of a large change submitted by Markus Friedl <markus@openbsd.org>
|
|
with the definition.
|
|
libdes (which is still used out there) or other des implementations,
the OpenSSL DES functions are renamed to begin with DES_ instead of
des_. Compatibility routines are provided and declared by including
openssl/des_old.h. Those declarations are the same as were in des.h
when the OpenSSL project started, which is exactly how libdes looked
at that time, and hopefully still looks today.
The compatibility functions will be removed in some future release, at
the latest in version 1.0.
|
|
DES's keyschedules.
I know these two should be separate, and I'll back out the DES changes if they
are deemed to be an error.
Note that there is a memory leak lurking in SSL somewhere in this version.
|
|
des_encrypt() and des_encrypt() defined on some systems (Solaris and
Unixware and maybe others), we rename des_encrypt() to des_encrypt1().
This should have very little impact on external software unless
someone has written a mode of DES, since that's all des_encrypt() is
meant for.
|
|
|
|
(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).
|
|
|
|
Submitted by: Richard Levitte <richard@levitte.org>
|
|
Submitted by:
Reviewed by:
PR:
|
|
Submitted by:
Reviewed by:
PR:
|
|
|
|
|
|
|
|
|
|
|
|
1. The already released version was 0.9.1c and not 0.9.1b
2. The next release should be 0.9.2 and not 0.9.1d, because
first the changes are already too large, second we should avoid any more
0.9.1x confusions and third, the Apache version semantics of
VERSION.REVISION.PATCHLEVEL for the version string is reasonable (and here
.2 is already just a patchlevel and not major change).
tVS: ----------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
