Change-Id: I2b8b6b784e72c6d38ca55158a395fc2619fd47ba
Reviewed-on: https://boringssl-review.googlesource.com/18606
Reviewed-by: David Benjamin <davidben@google.com>

The TLS standard suggests[1] that no_renegotation should be a warning alert
and that a client be able to decide whether to continue. This change
documents in PORTING.md that BoringSSL responds with a fatal alert
instead.

This is because we do not want to have any messages that are absorbed
without limit in the TLS layer because they may bypass limits
implemented at a higher level. We could limit the number of ClientHello
messages in the same way that we limit empty records, but we have had
this fatal behaviour for a long time without issue and it's simple.

(Technically this violates the RFC because the RFC says that
no_renegotation is always a warning.)

[1] https://tools.ietf.org/html/rfc5246#section-7.2.2

Change-Id: I4d4a696114f7e2b85f39e3fcb7b2c914cef661f2
Reviewed-on: https://boringssl-review.googlesource.com/18409
Reviewed-by: David Benjamin <davidben@google.com>

This was inadvertently dropped in
59015c365b. Python otherwise configures
P-256 if it assumes our OpenSSL predate's 1.0.2's multi-curve support.
This disables X25519, our preferred curve.

Change-Id: Ibf758583ea53e68c56667f16ee7096656bac719b
Reviewed-on: https://boringssl-review.googlesource.com/14208
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

People seem to like adding ifdefs for us for random initialization
functions that are cheap enough to add no-ops stubs for.

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

It was pointed out that the equivalent values may sometimes be hard to
find.

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

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

SSL_set_renegotiate_mode to avoid my original double-negative confusion.

Change-Id: I23537aeac53c4969fd81307a676f33d6768da55f
Reviewed-on: https://boringssl-review.googlesource.com/6322
Reviewed-by: Adam Langley <alangley@gmail.com>

It just calls CRYPTO_library_init and doesn't do anything else. If
anything, I'd like to make CRYPTO_library_init completely go away too.
We have CRYPTO_once now, so I think it's safe to assume that, if ssl/
ever grows initialization needs beyond that of crypto/, we can hide it
behind a CRYPTO_once and not burden callers.

Change-Id: I63dc362e0e9e98deec5516f4620d1672151a91b6
Reviewed-on: https://boringssl-review.googlesource.com/6311
Reviewed-by: Adam Langley <alangley@gmail.com>

mab@ seems to be dealing with a fair number of these, so it's probably worth
adding to the list.

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

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

There are a few things that differ in ways that are not source-compatible, so
it's probably worth documenting them.

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