platforms details on the command line without having to patch the Configure
script everytime: One now can use ``perl Configure <id>:<details>'', i.e.
platform ids are allowed to have details appended to them (seperated by
colons). This is treated as there would be a static pre-configured entry in
Configure's %table under key <id> with value <details> and ``perl Configure
<id>'' is called. So, when you want to perform a quick test-compile under
FreeBSD 3.1 with pgcc and without assembler stuff you can use ``perl Configure
"FreeBSD-elf:pgcc:-O6:::"'' now, which overrides the FreeBSD-elf entry
on-the-fly.
(PS: Notice that the same effect _cannot_ be achieved by using
``make CC=pgcc ..'' etc, because you cannot override all
things from there.)
questions now is the OpenSSL core team under openssl-core@openssl.org. And
add a paragraph about the dual-license situation to make sure people recognize
that _BOTH_ the OpenSSL license _AND_ the SSLeay license apply to the OpenSSL
toolkit.
consistent in the source tree and replaced `/bin/rm' by `rm'. Additonally
cleaned up the `make links' target: Remove unnecessary semicolons, subsequent
redundant removes, inline point.sh into mklink.sh to speed processing and no
longer clutter the display with confusing stuff. Instead only the actually
done links are displayed.
doc/openssl_button.{gif,html} which is similar in style to the old SSLeay
button and can be used by applications based on OpenSSL to show the
relationship to the OpenSSL project.
PS: This beast caused me three hours to create, because
of the size I had to hand-paint the 7pt fonts in Photoshop.
ssl/ssl_lib.c and ssl/ssl.h. At least the double ctx-variable
confused some compilers.
Submitted by: Lennart Bong <lob@kulthea.stacken.kth.se>
Reviewed by: Ralf S. Engelschall
between SSLeay 0.8 and 0.9 and just looks useless and confusing.
Pointed out by: Lennart Bong <lob@kulthea.stacken.kth.se>
Submitted by: Ralf S. Engelschall
private keys and/or callback functions which directly correspond to their
SSL_CTX_xxx() counterparts but work on a per-connection basis. This is needed
for applications which have to configure certificates on a per-connection
basis (e.g. Apache+mod_ssl) instead of a per-context basis (e.g.
s_server).
For the RSA certificate situation is makes no difference, but for the DSA
certificate situation this fixes the "no shared cipher" problem where the
OpenSSL cipher selection procedure failed because the temporary keys were not
overtaken from the context and the API provided no way to reconfigure them.
The new functions now let applications reconfigure the stuff and they are in
detail: SSL_need_tmp_RSA, SSL_set_tmp_rsa, SSL_set_tmp_dh,
SSL_set_tmp_rsa_callback and SSL_set_tmp_dh_callback. Additionally a new
non-public-API function ssl_cert_instantiate() is used as a helper function
and also to reduce code redundancy inside ssl_rsa.c.
Submitted by: Ralf S. Engelschall
Reviewed by: Ben Laurie
within SSL_MKEY_MASK or SSL_AUTH_MASK, they are within SSL_EXP_MASK. So, the
original variable has to be used instead of the already masked variable.
Submitted by: Richard Levitte <levitte@stacken.kth.se>
Reviewed by: Ralf S. Engelschall
from `int' to `unsigned int' because it's a length and initialized by
EVP_DigestFinal() which expects an `unsigned int *'.
Submitted by: Richard Levitte <levitte@stacken.kth.se>
Reviewed by: Ralf S. Engelschall
addition to RSA certificates) to match the behaviour of `openssl dsa -noout
-modulus' as it's already the case for `openssl rsa -noout -modulus'. For RSA
the -modulus is the real "modulus" while for DSA currently the public key is
printed (a decision which was already done by `openssl dsa -modulus' in the
past) which serves a similar purpose. Additionally the NO_RSA no longer
completely removes the whole -modulus option; it now only avoids using the RSA
stuff. Same applies to NO_DSA now, too.
[Eric A. Young, (from changes to C2Net SSLeay, integrated by Mark Cox)]
Fix so that the version number in the master secret, when passed
via RSA, checks that if TLS was proposed, but we roll back to SSLv3
(because the server will not accept higher), that the version number
is 0x03,0x01, not 0x03,0x00
[Eric A. Young, (from changes to C2Net SSLeay, integrated by Mark Cox)]
Submitted by:
Reviewed by:
PR:
of an arbitrary extension: e.g. 1.3.4.5=critical,RAW:12:34:56 Using this
technique currently unsupported extensions can be generated if you know their
DER encoding. Even if the extension is supported in future the raw extension
will still work: that is the raw version can always be used even if it is a
supported extension.
- ported BN stuff to OpenSSL's different BN library
- made the perl/ source tree CVS-aware
- renamed the package from SSLeay to OpenSSL (the files still contain
their history because I've copied them in the repository)
- removed obsolete files (the test scripts will be replaced
by better Test::Harness variants in the future)
name, issuer and authority key id. Change the i2v function parameters
and add an extra 'crl' parameter in the X509V3_CTX structure: guess
what that's for :-) Fix to ASN1 macro which messed up
IMPLICIT tag and add f_enum.c which adds a2i, i2a for ENUMERATED.
but the BN code had some problems that would cause failures when
doing certificate verification and some other functions.
Submitted by: Eric A Young from a C2Net version of SSLeay
Reviewed by: Mark J Cox
PR:
so that: openssl req -x509 -new -out cert.pem
will take extensions from openssl.cnf a sample for a CA is included.
Also change the directory order so pem is nearer the end. Otherwise 'make links'
wont work because pem.h can't be built.
DSA_free(): this was causing crashes when for example an attempt was made
to handle a (currently) unsupported DH public key. Also X509_PUBKEY_set()i
wasn't checking errors from d2i_PublicKey().
`openssl' and second, the shortcut symlinks for the `openssl <command>' are no
longer created. This way we have a single and consistent command line
interface `openssl <command>', similar to `cvs <command>'.
Notice, the openssl.cnf, openssl.c and progs.pl files were changed after a
repository copy, i.e. they still contain the complete file history.
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: ----------------------------------------------------------------------
