This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Remove lint, tags, dclean, tests.
This is prep for a new makedepend scheme.
This is temporary pending unified makefile, and might help it.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The entropy-gathering daemon is used only on a small number of machines.
Provide a configure knob so that EGD support can be disabled by default
but re-enabled on those systems that do need it.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Create Makefile's from Makefile.in
Rename Makefile.org to Makefile.in
Rename Makefiles to Makefile.in
Address review feedback from Viktor and Richard
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Provide backwards-compatiblity for functions, macros and include
files if OPENSSL_API_COMPAT is either not defined or defined less
than the version number of the release in which the feature was
deprecated.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Rename BUF_{strdup,strlcat,strlcpy,memdup,strndup,strnlen}
to OPENSSL_{strdup,strlcat,strlcpy,memdup,strndup,strnlen}
Add #define's for the old names.
Add CRYPTO_{memdup,strndup}, called by OPENSSL_{memdup,strndup} macros.
Reviewed-by: Tim Hudson <tjh@openssl.org>
The rand code can aquire locks and then attempt crypto operations. This
can end up in a deadlock if we are using an async engine, because control
returns back to the user code whilst still holding the lock. We need to
force synchronous operation for these sections of code.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This provides support for building in the EDK II reference implementation
of UEFI. Most UEFI firmware in existence uses OpenSSL for implementing
the core cryptographic functionality needed for Secure Boot.
This has always previously been handled with external patches to OpenSSL
but we are now making a concerted effort to eliminate those.
In this mode, we don't actually use the OpenSSL makefiles; we process
the MINFO file generated by 'make files' and incorporate it into the
EDK2 build system.
Since EDK II builds for various targets with varying word size and we
need to have a single prepackaged configuration, we deliberately don't
hard-code the setting of SIXTY_FOUR_BIT vs. THIRTY_TWO_BIT in
opensslconf.h. We bypass that for OPENSSL_SYS_UEFI and allow EDK II
itself to set those, depending on the architecture.
For x86_64, EDK II sets SIXTY_FOUR_BIT and thus uses 'long long' for the
64-bit type, even when building with GCC where 'long' is also 64-bit. We
do this because the Microsoft toolchain has 32-bit 'long'.
Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
We had updates of certain header files in both Makefile.org and the
Makefile in the directory the header file lived in. This is error
prone and also sometimes generates slightly different results (usually
just a comment that differs) depending on which way the update was
done.
This removes the file update targets from the top level Makefile, adds
an update: target in all Makefiles and has it depend on the depend: or
local_depend: targets, whichever is appropriate, so we don't get a
double run through the whole file tree.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
Add OPENSSL_clear_free which merges cleanse and free.
(Names was picked to be similar to BN_clear_free, etc.)
Removed OPENSSL_freeFunc macro.
Fixed the small simple ones that are left:
CRYPTO_free CRYPTO_free_locked OPENSSL_free_locked
Reviewed-by: Richard Levitte <levitte@openssl.org>
With no more symlinks, there's no need for those variables, or the links
target. This also goes for all install: and uninstall: targets that do
nothing but copy $(EXHEADER) files, since that's now taken care of by the
top Makefile.
Also, removed METHTEST from test/Makefile. It looks like an old test that's
forgotten...
Reviewed-by: Rich Salz <rsalz@openssl.org>
Rather than making include/openssl/foo.h a symlink to
crypto/foo/foo.h, this change moves the file to include/openssl/foo.h
once and for all.
Likewise, move crypto/foo/footest.c to test/footest.c, instead of
symlinking it there.
Originally-by: Geoff Thorpe <geoff@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
The justification for RAND_pseudo_bytes is somewhat dubious, and the reality
is that it is frequently being misused. RAND_bytes and RAND_pseudo_bytes in
the default implementation both end up calling ssleay_rand_bytes. Both may
return -1 in an error condition. If there is insufficient entropy then
both will return 0, but RAND_bytes will additionally add an error to the
error queue. They both return 1 on success.
Therefore the fundamental difference between the two is that one will add an
error to the error queue with insufficient entory whilst the other will not.
Frequently there are constructions of this form:
if(RAND_pseudo_bytes(...) <= 1)
goto err;
In the above form insufficient entropy is treated as an error anyway, so
RAND_bytes is probably the better form to use.
This form is also seen:
if(!RAND_pseudo_bytes(...))
goto err;
This is technically not correct at all since a -1 return value is
incorrectly handled - but this form will also treat insufficient entropy as
an error.
Within libssl it is required that you have correctly seeded your entropy
pool and so there seems little benefit in using RAND_pseudo_bytes.
Similarly in libcrypto many operations also require a correctly seeded
entropy pool and so in most interesting cases you would be better off
using RAND_bytes anyway. There is a significant risk of RAND_pseudo_bytes
being incorrectly used in scenarios where security can be compromised by
insufficient entropy.
If you are not using the default implementation, then most engines use the
same function to implement RAND_bytes and RAND_pseudo_bytes in any case.
Given its misuse, limited benefit, and potential to compromise security,
RAND_pseudo_bytes has been deprecated.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Miscellaneous unchecked malloc fixes. Also fixed some mem leaks on error
paths as I spotted them along the way.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Remove support for SHA0 and DSS0 (they were broken), and remove
the ability to attempt to build without SHA (it didn't work).
For simplicity, remove the option of not building various SHA algorithms;
you could argue that SHA_224/256/384/512 should be kept, since they're
like crypto algorithms, but I decided to go the other way.
So these options are gone:
GENUINE_DSA OPENSSL_NO_SHA0
OPENSSL_NO_SHA OPENSSL_NO_SHA1
OPENSSL_NO_SHA224 OPENSSL_NO_SHA256
OPENSSL_NO_SHA384 OPENSSL_NO_SHA512
Reviewed-by: Richard Levitte <levitte@openssl.org>
This removes all code surrounded by '#ifdef undef'
One case is left: memmove() replaced by open-coded for loop,
in crypto/stack/stack.c That needs further review.
Also removed a couple of instances of /* dead code */ if I saw them
while doing the main removal.
Reviewed-by: Matt Caswell <matt@openssl.org>
Rename OPENSSL_SYSNAME_xxx to OPENSSL_SYS_xxx
Remove MS_STATIC; it's a relic from platforms <32 bits.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Use setbuf(fp, NULL) instead of setvbuf(). This removes some
ifdef complexity because all of our platforms support setbuf.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Sometimes it fails to format them very well, and sometimes it corrupts them!
This commit moves some particularly problematic ones.
Reviewed-by: Tim Hudson <tjh@openssl.org>
The following #ifdef tests were all removed:
__MWERKS__
MAC_OS_pre_X
MAC_OS_GUSI_SOURCE
MAC_OS_pre_X
OPENSSL_SYS_MACINTOSH_CLASSIC
OPENSSL_SYS_MACOSX_RHAPSODY
Reviewed-by: Andy Polyakov <appro@openssl.org>
GetDIBits has been around since Windows2000 and
BitBitmapBits is an old Win16 compatibility function
that is much slower.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Because of a missing include <fcntl.h> we don't have O_CREATE and don't create
the file with open() using mode 0600 but fall back to using fopen() with the
default umask followed by a chmod().
Problem found by Jakub Wilk <jwilk@debian.org>.
Treat a zero length passed to ssleay_rand_add a no op: the existing logic
zeroes the md value which is very bad. OpenSSL itself never does this
internally and the actual call doesn't make sense as it would be passing
zero bytes of entropy.
Thanks to Marcus Meissner <meissner@suse.de> for reporting this bug.
(cherry picked from commit 5be1ae28ef)
Windows 8 SDKs complain that GetVersion() is deprecated.
We only use GetVersion like this:
(GetVersion() < 0x80000000)
which checks if the Windows version is NT based. Use a macro check_winnt()
which uses GetVersion() on older SDK versions and true otherwise.
Reported by: Tomas Mraz <tmraz@redhat.com>
Treat a NULL value passed to drbg_free_entropy callback as non-op. This
can happen if the call to fips_get_entropy fails.
now use an internal RAND_METHOD. All dependencies to OpenSSL standard
PRNG are now removed: it is the applications resposibility to setup
the FIPS PRNG and initalise it.
Initial OpenSSL RAND_init_fips() function that will setup the DRBG
for the "FIPS capable OpenSSL".
Submitted by: Kevin Regan <k.regan@f5.com>
Clear stat structure if -DPURIFY is set to avoid problems on some
platforms which include unitialised fields.
.DLL, in particular static build. The issue has been discussed in RT#1230
and later on openssl-dev, and mutually exclusive approaches were suggested.
This completes compromise solution suggested in RT#1230.
PR: 1230
knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.
deprecate the original (numeric-only) scheme, and replace with the
CRYPTO_THREADID object. This hides the platform-specifics and should reduce
the possibility for programming errors (where failing to explicitly check
both thread ID forms could create subtle, platform-specific bugs).
Thanks to Bodo, for invaluable review and feedback.
to 'unsigned long' (ie. odd platforms/compilers), so a pointer-typed
version was added but it required portable code to check *both* modes to
determine equality. This commit maintains the availability of both thread
ID types, but deprecates the type-specific accessor APIs that invoke the
callbacks - instead a single type-independent API is used. This simplifies
software that calls into this interface, and should also make it less
error-prone - as forgetting to call and compare *both* thread ID accessors
could have led to hard-to-debug/infrequent bugs (that might only affect
certain platforms or thread implementations). As the CHANGES note says,
there were corresponding deprecations and replacements in the
thread-related functions for BN_BLINDING and ERR too.
Note: the RAND_bytes() manual page says:
RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf.
It does not talk about using the previous contents of buf so we are working
as documented.
CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type
thread ID, since the 'unsigned long' type of the existing thread ID
does not always work well.
