This tidies up verify parameters and adds support for integrated policy
checking.
Add support for policy related command line options. Currently only in smime
application.
WARNING: experimental code subject to change.
x86*_nw.pl will be deleted. In addition this update implements initseg
on several additional [in addition to ELF] platforms. Functions registered
with initseg are supposed to be called prior main().
converted to upper case or something like that), the application-
level bio_dump_cb() has a name clash with the new library function
BIO_dump_cb(). The easiest fix is to rename the function at the
application level.
to bother creating a BIO around it. So here's a few more functions to
make it possible to make the dump using a printing callback, and to
print to a FILE* (based on the callback variant), done in the same
style as the functions in crypto/err/err_prn.c.
performing AES encryption in hardware, as well as one accessing
hardware RNG. As you surely imagine this engine access this
extended instruction set. Well, only AES for the moment, support
for RNG is to be added later on...
PR: 889
Submitted by: Michal Ludvig <michal@logix.cz>
Obtained from: http://www.logix.cz/michal/devel/padlock/
COFF and a.out targets [similar to ELF targets]. You might notice some
rudementary support for shared mingw builds under cygwin. It works (it
produces cryptoeay32.dll and ssleay32.dll with everything exported by
name), but it's primarily for testing/debugging purposes, at least for
now...
if we explicitly intruct the linker to set entry point, then we become
obliged to initialize run-time library. Instead we can pick name run-time
will call and such name is DllMain. Note that this applies to both
"native" Win32 environment and Cygwin:-)
around them.
NOTE: because two new locks are added, this adds potential binary
incompatibility with earlier versions in the 0.9.7 series. However,
those locks will only ever be touched when FIPS_mode_set() is called
and after, thanks to a variable that's only changed from 0 to 1 once
(when FIPS_mode_set() is called). So basically, as long as FIPS mode
hasn't been engaged explicitely by the calling application, the new
locks are treated as if they didn't exist at all, thus not becoming a
problem. Applications that are built or rebuilt to use FIPS
functionality will need to be recompiled in any case, thus not being a
problem either.
