Richard Levitte [Thu, 27 Jan 2005 01:49:23 +0000 (01:49 +0000)]
Check for errors from EVP_VerifyInit_ex(), or EVP_VerifyUpdate might
cause a segfault... This was uncovered because EVP_VerifyInit() may fail
in FIPS mode if the wrong algorithm is chosen...
Non FIPS algorithms are not normally allowed in FIPS mode.
Any attempt to use them via high level functions will return an error.
The low level non-FIPS algorithm functions cannot return errors so they
produce assertion failures. HMAC also has to give an assertion error because
it (erroneously) can't return an error either.
There are exceptions (such as MD5 in TLS and non cryptographic use of
algorithms) and applications can override the blocking and use non FIPS
algorithms anyway.
For low level functions the override is perfomed by prefixing the algorithm
initalization function with "private_" for example private_MD5_Init().
For high level functions an override is performed by setting a flag in
the context.
PKCS7_verify() performance optimization. When the content is large and a
memory BIO (for example from SMIME_read_PKCS7 and detached data) avoid lots
of slow memory copies from the memory BIO by saving the content in a
temporary read only memory BIO.
Andy Polyakov [Mon, 27 Dec 2004 14:51:20 +0000 (14:51 +0000)]
As new major IRIX release is highly unlikely to appear [and break following],
I change from -notall to -none synonym in do_irix-shared to improve backward
compatibility with IRIX 5.x.
PR: 987
Andy Polyakov [Thu, 9 Dec 2004 22:43:29 +0000 (22:43 +0000)]
Eliminate false dependency on 386 config option is FIPS context.
At the same time limit assembler support to ELF platforms [that's
what is there, ELF modules].
Andy Polyakov [Wed, 1 Dec 2004 15:28:18 +0000 (15:28 +0000)]
I've introduced a bug to i386 RC4 assembler, which would emerge with
certain mix of calls to RC4 routine not covered by rc4test.c.
It's fixed now. In addition this patch inadvertently fixes minor
performance problem: in 0.9.7 context P4 was performing 12% slower
than the original implementation...
Richard Levitte [Tue, 30 Nov 2004 12:18:55 +0000 (12:18 +0000)]
Split X509_check_ca() into a small self and an internal function
check_ca(), to resolve constness issue. check_ca() is called from the
purpose checkers instead of X509_check_ca(), since the stuff done by
the latter (except for calling check_ca()) is also done by
X509_check_purpose().
Richard Levitte [Tue, 30 Nov 2004 12:18:53 +0000 (12:18 +0000)]
Split X509_check_ca() into a small self and an internal function
check_ca(), to resolve constness issue. check_ca() is called from the
purpose checkers instead of X509_check_ca(), since the stuff done by
the latter (except for calling check_ca()) is also done by
X509_check_purpose().
Richard Levitte [Mon, 29 Nov 2004 11:28:08 +0000 (11:28 +0000)]
Make an explicit check during certificate validation to see that the
CA setting in each certificate on the chain is correct. As a side-
effect always do the following basic checks on extensions, not just
when there's an associated purpose to the check:
- if there is an unhandled critical extension (unless the user has
chosen to ignore this fault)
- if the path length has been exceeded (if one is set at all)
- that certain extensions fit the associated purpose (if one has been
given)
Richard Levitte [Mon, 29 Nov 2004 11:18:00 +0000 (11:18 +0000)]
Make an explicit check during certificate validation to see that the
CA setting in each certificate on the chain is correct. As a side-
effect always do the following basic checks on extensions, not just
when there's an associated purpose to the check:
- if there is an unhandled critical extension (unless the user has
chosen to ignore this fault)
- if the path length has been exceeded (if one is set at all)
- that certain extensions fit the associated purpose (if one has been
given)