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:

not covered by the strength bit mask.
Submitted by:
Reviewed by:
PR: 130

Submitted by: Nils Larsch

(but noone uses it anyway)

fix t1_enc.c: use OPENSSL_NO_RC4, not NO_RC4

Submitted by: Jan Tschirschwitz <Jan.Tschirschwitz@cluster-labs.de>

(noted by Jonathan Louie <jlouie@recourse.com>).

PR 123

PR 71

This completes PR 123

handled properly.
Part of PR 75

Part of PR 75

Part of PR 75

Part of PR 75

This concludes the changes from PR 123

This is due to weird Borland compilers.
Part of PR 123

Part of PR 123

Part of PR 123

PR: 119

PR: 117

structure field names.
PR: 112

PR: 106

PR: 105

was that they weren't really needed any more for EVP itself.  However,
it seems like soma applications (I know about OpenSSH, but there may
be more) used evp.h as the 'load all' header file, which makes sense
since we try our best to promote the use of EVP instead of the lower
level crypto algorithms.  Therefore, I put the inclusions back so
the application authors don't get too shocked by all the errors they
would otherwise get.

Thanks to Theo de Raadt for making us aware of this.

Submitted by: Nils Larsch

pointers passed to them whenever necessary. Otherwise it is possible the
caller may have overwritten (or deallocated) the original string data
when a later ENGINE operation tries to use the stored values.

Submitted by: Götz Babin-Ebell <babinebell@trustcenter.de>
Reviewed by: Geoff Thorpe
PR: 98

Submitted by: Bernhard Simon <bs@bsws.zid.tuwien.ac.at>
Reviewed by:
PR:

Make sure to use the predefined PERL.
Submitted by: Bernhard Simon <bs@bsws.zid.tuwien.ac.at>
Reviewed by:
PR:

Submitted by: Pieter Bowman <bowman@math.utah.edu>

Submitted by: Bernhard Simon <bs@bsws.zid.tuwien.ac.at>
Reviewed by:
PR:

so it can't be bad)

so it can't be bad)

PR: 102