| Age | Commit message (Collapse) | Author |
|---|
|
warnings hard to fix without major surgery).
|
|
and is a pre-requisite to adding password based CMS support.
|
|
|
|
test for them!
|
|
|
|
|
|
|
|
|
|
PR: 1170
Submitted by: Yair Elharrar
Reviewed and edited by: Nils Larsch
|
|
functions and macros.
This change has associated tags: LEVITTE_before_const and
LEVITTE_after_const. Those will be removed when this change has been
properly reviewed.
|
|
I have tried to convert 'len' type variable declarations to unsigned as a
means to address these warnings when appropriate, but when in doubt I have
used casts in the comparisons instead. The better solution (that would get
us all lynched by API users) would be to go through and convert all the
function prototypes and structure definitions to use unsigned variables
except when signed is necessary. The proliferation of (signed) "int" for
strictly non-negative uses is unfortunate.
|
|
|
|
I've covered all the memset()s I felt safe modifying, but may have missed some.
|
|
|
|
des_old.h redefines crypt:
#define crypt(b,s)\
DES_crypt((b),(s))
This scheme leads to failure, if header files with the OS's true definition
of crypt() are processed _after_ des_old.h was processed. This is e.g. the
case on HP-UX with unistd.h.
As evp.h now again includes des.h (which includes des_old.h), this problem
only came up after this modification.
Solution: move header files (indirectly) including e_os.h before the header
files (indirectly) including evp.h.
Submitted by:
Reviewed by:
PR:
|
|
("D. Russell" <russelld@aol.net>)
Allow HMAC functions to use an alternative ENGINE.
|
|
|
|
to digests to retain compatibility.
|
|
|
|
functions to return constant EVP_MD and EVP_CIPHER
pointers.
Update docs.
|
|
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
|
|
Add a couple of FAQs.
|
|
|
|
|
|
|
|
|
|
|
|
structure and decides what key to generate (if any). Not currently added to
the PBE algorithm list because it is largely untested.
|
