The rand subcommand outputs entropy to stdout.

Change-Id: I95c2769a1784a8dd4c21efc15009080006d51349
Reviewed-on: https://boringssl-review.googlesource.com/4325
Reviewed-by: Adam Langley <agl@google.com>

find -name CMakeLists.txt -type f | xargs sed -e 's/\t/  /g' -i

Change-Id: I01636b1849c00ba918f48828252492d99b0403ac

Android might want to replace the system *sum (i.e. md5sum, sha256sum
etc) binaries with a symlink to the BoringSSL tool binary.

This change also allows the tool to figure out what to do based on
argv[0] if it matches one of the known commands.

Change-Id: Ia4fc3cff45ce2ae623dae6786eea5d7ad127d44b
Reviewed-on: https://boringssl-review.googlesource.com/2940
Reviewed-by: Adam Langley <agl@google.com>

Change-Id: Ia8588aeaad8b44a6a306d7d5bfecc895adde1910

This lets us run bssl speed at least. bssl client is currently compiled
out until we clean up our socket story on Windows and get it working.

Change-Id: Ib1dc0d0e0a6eed7544207e7bbe138503731fda67
Reviewed-on: https://boringssl-review.googlesource.com/2103
Reviewed-by: Adam Langley <agl@google.com>

This is cleaner than the OpenSSL code was, at least, but it's hardly
beautiful due to the "standard" that it's trying to implement. (See
[1].)

The references from the PKCS#8 code to various ciphers have digests have
been made into function pointer references rather than NIDs so that the
linker will be able to drop RC2 code for binaries that don't call PKCS#8
or #12 functions.

A bug that crashed OpenSSL/BoringSSL when parsing a malformed PKCS#8
structure has been fixed too.

See https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html

Change-Id: Iaa1039e04ed7877b90792835e8ce3ebc3b29f89e
Reviewed-on: https://boringssl-review.googlesource.com/1592
Reviewed-by: Adam Langley <agl@google.com>

Apart from the obvious little issues, this also works around a
(seeming) libtool/linker:

a.c defines a symbol:

int kFoo;

b.c uses it:

extern int kFoo;

int f() {
  return kFoo;
}

compile them:

$ gcc -c a.c
$ gcc -c b.c

and create a dummy main in order to run it, main.c:

int f();

int main() {
  return f();
}

this works as expected:

$ gcc main.c a.o b.o

but, if we make an archive:

$ ar q lib.a a.o b.o

and use that:

$ gcc main.c lib.a
Undefined symbols for architecture x86_64
  "_kFoo", referenced from:
    _f in lib.a(b.o)

(It doesn't matter what order the .o files are put into the .a)

Linux and Windows don't seem to have this problem.

nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1].
Basically the linker will merge multiple common symbol definitions together.

If ones makes a.c read:

int kFoo = 0;

Then one gets a type "D" symbol - a "data section symbol" and everything works
just fine.

This might actually be a libtool bug instead of an ld bug: Looking at `xxd
lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive
doesn't contain an entry for kFoo unless initialised.

Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427

Initial fork from f2d678e6e8 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)