1107. He says:
This is a followup to the NetWare patch that was applied to beta3. It
does the following:
- Fixes a problem in the CLib build with undefined symbols.
- Adds the ability to use BSD sockets as the default for the OpenSSL
socket BIO. NetWare supports 2 flavors of sockets and our Apache
developers need BSD sockets as a configurable option when building
OpenSSL. This adds that for them.
- Updates to the INSTALL.NW file to explain new options.
I have tried very hard to make sure all the changes are in NetWare
specific files or guarded carefully to make sure they only impact
NetWare builds. I have tested the Windows build to make sure it does
not break that since we have made changes to mk1mf.pl.
We are still working the gcc cross compile for NetWare issue and hope
to have a patch for that before beta 6 is released.
compiled into *our* aplpications. That's because mingw is always
consistent with itself. Having library-side code linked into .dll
makes it possible to deploy the .dll with user-code compiled with
another compiler [which is pretty much the whole point behind Applink].
This is now the case for RC5.
As a side effect, the OPTIONS in the Makefile will usually look a
little different now, but they are essentially only for information
anyway.
Idea is to provide unified "fall-down" case for all rare platforms out
there. ./config is free to enable some optimizations, such as endianness
specification, specific -mcpu flags...
apparently impossible to compose blended code with would perform
satisfactory on all x86 and x86_64 cores, an extra RC4_CHAR
code-path is introduced and P4 core is detected at run-time. This
way we keep original performance on non-P4 implementations and
turbo-charge P4 performance by factor of 2.8x (on 32-bit core).
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...
is to have a placeholder to small routines, which can be written only
in assembler. In IA-32 case this includes processor capability
identification and access to Time-Stamp Counter. As discussed earlier
OPENSSL_ia32cap is introduced to control recently added SSE2 code
pathes (see docs/crypto/OPENSSL_ia32cap.pod). For the moment the
code is operational on ELF platforms only. I haven't checked it yet,
but I have all reasons to believe that Windows build should fail to
link too. I'll be looking into it shortly...
install to a different location than it had created. (BTW, VMS will need a
matching fix in eng_list.c.) Note, these aren't ssl-specific, so I'm
putting "engines/" into the libs directory rather than at the "--prefix"
level or inside "ssl/".
especially for AIX. But most important BIGNUM assembler implementation
submitted by IBM.
Submitted by: Peter Waltenberg <pwalten@au1.ibm.com>
Reviewed by: appro
available compiler versions generated bogus machine code trying to
compile new crypto/des/cfb_enc.c. Secondly, 8th version defines
__GNUC__ macro, but fails to compile *some* inline assembler correctly.
Note that all versions of icc implement MSC-like _lrot[rl] intrinsic,
which is used now instead of offensive asm. Finally, unnecessary linker
dependencies are eliminated. Most notably dependency from libirc.a
caused trouble at application start-up, if libcrypto.so is linked with
-Bsymbolic (which it is).
For reference. Note that both cc and gcc support -Wl flag, but we can't
use -Wl,-[not]all with both drivers, because cc rearranges options
passed through -Wl. We can't use -Wl,-all,libcrypto.a,-notall with cc
either, because it refuses to start with "no input" error.
be modified to choose it instead of hpux64-parisc-gcc, which should
then be removed. hpux64-parisc-cc is removed already now as redundant
[in case you wonder, 64-bit HP-UX ABI *implies* PA-RISC2.0].
replaced #if logic around bn_sub_part_words in bn_mul.c. I rely upon
OPENSSL_BN_ASM_PART_WORDS being added by ./Configure script. Would it
still work on non-Unix platforms?
PR: 338
Here's the description, submitted by Gisle Vanem <giva@bgnett.no>:
1. sock_init() renamed to ssl_sock_init() in ./apps/s_socket.c due
to name-clash with Watt-32.
2. rand() renamed to Rand() in ./crypto/bn/divtest.c due to name-clash
with <stdlib.h>
3. Added calls to dbug_init()/sock_init() in some demo programs.
4. Changed cflags/lflags in configure. Watt-32 install root now taken
from $WATT_ROOT.
Correct misspelled VXWORKS macros.
Add VXWORKS identifying macros to e_os2.h.
Add required inclusions and mappings for VxWorks in e_os.h.
A few small modifications to make OpenSSL build and work on VxWorks.
PR: 253, except for the change that was handled in an earlier
commit, and a request for easy build of just parts of OpenSSL.
Additional changes:
- use EC_GROUP_get_degree() in apps/req.c
- add ECDSA and ECDH to apps/speed.c
- adds support for EC curves over binary fields to ECDSA
- new function EC_KEY_up_ref() in crypto/ec/ec_key.c
- reorganize crypto/ecdsa/ecdsatest.c
- add engine support for ECDH
- fix a few bugs in ECDSA engine support
Submitted by: Douglas Stebila <douglas.stebila@sun.com>
directory, making a separate directory tree with lots of symbolic links
seems to be the solution. Unfortunatelt, Configure doesn't take appropriate
steps to support this solution (as in removing a file that's going to be
rewritten). This change corrects that situation. Now I just have to
find all other places where there's lack of support for this.
SIXTY_FOUR bignum library option to use 64 bit operations
on the 32 bit linux platform.
This is very inefficient but it can be used to test some
of the 64 bit logic on a 32 bit platform.
Therefore, I've added a sanity checker.
Note that it can be combined with almost any other argument (the other
arguments will be completely ignored), with "reconf" as the blatant
exception, since it also has the behavior of ignoring all following
command line arguments. If --test-sanity and reconf are both used on
the command line, the first one wins.
* make openssl rsa work with -engine chil
* misc changes, including debug-linux-ppro Configure target
and FORMAT_NETSCAPE-aware load_{,pub}key()
This completes the application of his changes.
field here, which is left empty).
Various configurations are *only* in the 0.9.6 branch at the moment:
OpenUNIX
OpenUNIX-8-gcc-shared
OpenUNIX-8-shared
Either Configure or CHANGES must be changed to rectify the situation.
used or not, let's ask collect2 which ld it uses and choose to use the
target do-gnu_shared if GNU ld is used.
This solves the reported problems on Solaris systems where GNU cc is
used but GNU ld isn't, and probably on other systems with similar
setups.
me the same and that the correct option is -mcpu=i486. I'm assuming
-mcpu has been around for some time, and that it's therefore safe to
change all occurences of -m486 to -mcpu=i486.
His comments are:
1) Changes all references for `True64' to be `Tru64', which is the correct
spelling for the OS name.
2) Makes `alpha-cc' be the same as `alpha164-cc', and adds an `alphaold-cc'
entry that is the same as the previous `alpha-cc'. The reason is that most
people these days are using the newer compiler, so it should be the default.
3) Adds a bit of commentary to Configure, regarding the name changes of
the OS over the years, so it's not so confusing to people that haven't been
with the OS for a while.
4) Adds an `alpha-cc-rpath' target (which is *not* selected automatically
by Configure under any circumstance) that builds an RPATH into the
shared libraries. This is explained in the comment in Configure. It's
very very useful for people that want it, and people that don't want it
just shouldn't choose that target.
5) Adds the `-pthread' flag as the best way to get POSIX thread support
from the newer compiler.
6) Updates the Makefile targets, so that when the `alpha164-cc', `alpha-cc',
or `alpha-cc-rpath' target is what Configure is set to use, it uses a Makefile
target that includes the `-msym' option when building the shared library.
This is a performance enhancement.
7) Updates `config' so that if it detects you're running version 4 or 5
of the OS, it automatically selects `alpha-cc', but uses `alphaold-cc'
for versions 1-3 of the OS.
8) Updates the comment in opensslv.h, fixing both the OS name typo and
adding a reference to IRIX 6.x, since the shared library semantics are
virtually identical there.
HP-UX in common in ./config). Note that for the moment of this writing
none of 64-bit platforms pass bntest. I'm committing this anyway as it's
too frustrating to patch snapshots over and over while 0.9.6 is known to
work.
explicitely noted that 64-bit SPARCv9 ABI is not officially supported
by GCC 3.0 (support is scheduled for 3.1 release), but it appears to
work, at the very least 'make test' passes...
SSL according to RFC 2712. His comment is:
This is a patch to openssl-SNAP-20010702 to support Kerberized SSL
authentication. I'm expecting to have the full kssl-0.5 kit up on
sourceforge by the end of the week. The full kit includes patches
for mod-ssl, apache, and a few text clients. The sourceforge URL
is http://sourceforge.net/projects/kssl/ .
Thanks to a note from Simon Wilkinson I've replaced my KRB5 AP_REQ
message with a real KerberosWrapper struct. I think this is fully
RFC 2712 compliant now, including support for the optional
authenticator field. I also added openssl-style ASN.1 macros for
a few Kerberos structs; see crypto/krb5/ if you're interested.
variables and disable the Alpha assembler for now, since it has been
shown to fail.
The Alpha failure can be shown by adding the following numbers:
FFFFFFFFFFFFFF0000FF2E00000000EBFFFFFF0000D1
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF46FFE0FFFF0000
The result is:
1FFFFFFFFFFFEFF0000FF2E0000000032FFE0FEFF00D1
The result should really be:
1FFFFFFFFFFFFFF0000FF2E0000000032FFE0FEFF00D1
functions on platform were that's the best way to handle exporting
global variables in shared libraries. To enable this functionality,
one must configure with "EXPORT_VAR_AS_FN" or defined the C macro
"OPENSSL_EXPORT_VAR_AS_FUNCTION" in crypto/opensslconf.h (the latter
is normally done by Configure or something similar).
To implement a global variable, use the macro OPENSSL_IMPLEMENT_GLOBAL
in the source file (foo.c) like this:
OPENSSL_IMPLEMENT_GLOBAL(int,foo)=1;
OPENSSL_IMPLEMENT_GLOBAL(double,bar);
To declare a global variable, use the macros OPENSSL_DECLARE_GLOBAL
and OPENSSL_GLOBAL_REF in the header file (foo.h) like this:
OPENSSL_DECLARE_GLOBAL(int,foo);
#define foo OPENSSL_GLOBAL_REF(foo)
OPENSSL_DECLARE_GLOBAL(double,bar);
#define bar OPENSSL_GLOBAL_REF(bar)
The #defines are very important, and therefore so is including the
header file everywere where the defined globals are used.
The macro OPENSSL_EXPORT_VAR_AS_FUNCTION also affects the definition
of ASN.1 items, but that structure is a bt different.
The largest change is in util/mkdef.pl which has been enhanced with
better and easier to understand logic to choose which symbols should
go into the Windows .def files as well as a number of fixes and code
cleanup (among others, algorithm keywords are now sorted
lexicographically to avoid constant rewrites).
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.
you should defined _THREAD_SAFE (I found that in an include file, and
that's what everybody tells me) or _THREADSAFE (that's what the gcc
manual says in the FreeBSD-specific section), so I defined both, just
to be safe.
to have the full extension information, so residual shared libraries
can be removed so the applications and test programs do not get linked
against them by mistake...
- Make note of the expected extension for the shared libraries and
if there is a need for symbolic links from for example libcrypto.so.0
to libcrypto.so.0.9.7. There is extended info in Configure for
that.
- Make as few rebuilds of the shared libraries as possible.
- Still avoid linking the OpenSSL programs with the shared libraries.
- When installing, install the shared libraries separately from the
static ones.
The old code was painfully primitive and couldn't handle
distinct certificates using the same subject name.
The new code performs several tests on a candidate issuer
certificate based on certificate extensions.
It also adds several callbacks to X509_VERIFY_CTX so its
behaviour can be customised.
Unfortunately some hackery was needed to persuade X509_STORE
to tolerate this. This should go away when X509_STORE is
replaced, sometime...
This must have broken something though :-(
there's support for building under Linux and True64 (using examples
from the programming manuals), including versioning that is currently
the same as OpenSSL versions but should really be a different series.
With this change, it's up to the users to decide if they want shared
libraries as well as the static ones. This decision now has to be
done at configuration time (well, not really, those who know what they
do can still do it the same way as before).
The OpenSSL programs (openssl and the test programs) are currently
always linked statically, but this may change in the future in a
configurable manner. The necessary makefile variables to enable this
are in place.
Also note that I have done absolutely nothing about the Windows target
to get something similar. On the other hand, DLLs are already the
default there, but without versioning, and I've no idea what the
possibilities for such a thing are there...
it cope with OpenBSD which doesn't understand "RTLD_NOW".
* Added the dso_scheme config string entry for OpenBSD-x86 to give it
DSO support.
* 'make update' that has also absorbed some of Steve's mkstack changes
for the ASN-related macros.
Also, "make update" has added some missing functions to libeay.num,
updated the TABLE for the alpha changes, and updated thousands of
dependancies that have changed from recent commits.
