aboutsummaryrefslogtreecommitdiff
path: root/PORTING.md
AgeCommit message (Collapse)AuthorFilesLines
8 daysMake BoringSSL initialization-lessDavid Benjamin1-6/+2
Now that we don't depend on external CRYPTO_library_init calls or the static initializer to initialize CPU capabilities, we can drop a ton of code. This makes CRYPTO_library_init, and all its wrappers, into no-ops and drops the (non-FIPS) static initializer. I've added an internal OPENSSL_init_cpuid function for the places where the library actually needs to initialize the CPU vector. Note this slightly changes the default, previously static-initializer-full build: previously, CRYPTO_library_init was a no-op and we relied on the static initializer. Now we uniformly use CRYPTO_once. This should be an atomic read in the steady state and essentially free. We can restore the static initializer by default if this ends up being a problem, but having only one mode is more straightforward. This also avoids problems if an application calls into BoringSSL during its own static initializer. Static initializers are not coherently ordered. Update-Note: The BORINGSSL_NO_STATIC_INITIALIZER build option and CRYPTO_library_init are now unnecessary. Once updating past this revision, those options can now be cleaned up from downstream projects. Fixed: 40644931 Change-Id: Idc2e6ea7a73d6352e0360fd886c46d88dba3568c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69508 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2023-02-08Remove d2i_FOO object reuseDavid Benjamin1-5/+4
The "object reuse" mode in d2i_FOO is extremely problematic. See bug for details. When we rewrite d2i_RSAPublicKey, etc., with CBS, we switched dropped this fragile behavior and replaced it with freeing the old value and replacing it with the new value. Extend this behavior to all functions generated by crypto/asn1 templates too. In particular, tasn_dec.c already frees the original object on error, which means callers must already be prepared for OpenSSL to free their reused object. The one caller I found that would be incompatible (via both running tests and auditing callers) was actually broken due to this error case, and has been fixed. Update-Note: This slightly changes the calling convention of the d2i_FOO functions. The change should be compatible with almost all valid calls. If something goes wrong, it should hopefully be quite obvious. If affected (or unaffected), prefer to set the output parameter to NULL and use the return value instead. Fixed: 550 Change-Id: Ie54cdf17f8f5a4d76fdbcddeaa27e6afd3fa9d8e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56647 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2018-06-29Remove reference to SSL3 in PORTING.md.David Benjamin1-1/+1
We don't support SSL3 at all now. Actually we haven't supported renego SSL3 in even longer, so this was false even before yesterday. Change-Id: Ie759477fa84099dd486c4c4604080ecf8ecdf434 Reviewed-on: https://boringssl-review.googlesource.com/29484 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-02-13Add cpu-aarch64-fuchsia.cAaron Green1-1/+1
Fuchsia/Zircon recently added support for exposing arm64 CPU features; this CL uses the new system call to set OPENSSL_armcap_P. Change-Id: I045dc0b58117afe6dae315a82bf9acfd8d99be1a Reviewed-on: https://boringssl-review.googlesource.com/25865 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-09-29Switch OPENSSL_VERSION_NUMBER to 1.1.0.David Benjamin1-17/+31
Although we are derived from 1.0.2, we mimic 1.1.0 in some ways around our FOO_up_ref functions and opaque libssl types. This causes some difficulties when porting third-party code as any OPENSSL_VERSION_NUMBER checks for 1.1.0 APIs we have will be wrong. Moreover, adding accessors without changing OPENSSL_VERSION_NUMBER can break external projects. It is common to implement a compatibility version of an accessor under #ifdef as a static function. This then conflicts with our headers if we, unlike OpenSSL 1.0.2, have this function. This change switches OPENSSL_VERSION_NUMBER to 1.1.0 and atomically adds enough accessors for software with 1.1.0 support already. The hope is this will unblock hiding SSL_CTX and SSL_SESSION, which will be especially useful with C++-ficiation. The cost is we will hit some growing pains as more 1.1.0 consumers enter the ecosystem and we converge on the right set of APIs to import from upstream. It does not remove any 1.0.2 APIs, so we will not require that all projects support 1.1.0. The exception is APIs which changed in 1.1.0 but did not change the function signature. Those are breaking changes. Specifically: - SSL_CTX_sess_set_get_cb is now const-correct. - X509_get0_signature is now const-correct. For C++ consumers only, this change temporarily includes an overload hack for SSL_CTX_sess_set_get_cb that keeps the old callback working. This is a workaround for Node not yet supporting OpenSSL 1.1.0. The version number is set at (the as yet unreleased) 1.1.0g to denote that this change includes https://github.com/openssl/openssl/pull/4384. Bug: 91 Change-Id: I5eeb27448a6db4c25c244afac37f9604d9608a76 Reviewed-on: https://boringssl-review.googlesource.com/10340 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2017-09-07Add a note to PORTING.md about free/OPENSSL_free mixups.David Benjamin1-0/+11
Change-Id: I7cf0e67148c0908e5a4c670251419a8bc15fbea9 Reviewed-on: https://boringssl-review.googlesource.com/20109 Reviewed-by: Martin Kreichgauer <martinkr@google.com>
2017-08-24Don't reauthenticate on renegotiation.David Benjamin1-0/+7
We currently forbid the server certificate from changing on renegotiation. This means re-verifying the certificate is pointless and indeed the callback being called again seems to surprise consumers more than anything else. Carry over the initial handshake's SCT lists and OCSP responses (don't enforce they don't change since the server may have, say, picked up new OCSP responses in the meantime), ignore new ones received on renegotiation, and don't bother redoing verification. For our purposes, TLS 1.2 renegotiation is an overcomplicated TLS 1.3 KeyUpdate + post-handshake auth. The server is not allowed to change identity. Bug: 126 Change-Id: I0dae85bcf243943b1a5a97fa4f30f100c9e6e41e Reviewed-on: https://boringssl-review.googlesource.com/19665 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-24Mark renego-established sessions not resumable.David Benjamin1-0/+4
We do not call the new_session callback on renego, but a consumer using SSL_get_session may still attempt to resume such a session. Leave the not_resumable flag unset. Also document this renegotiation restriction. Change-Id: I5361f522700b02edf5272ba5089c0777e5dafb09 Reviewed-on: https://boringssl-review.googlesource.com/19664 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-08-04Add a paragraph to PORTING.md about async private keys.Adam Langley1-0/+4
Change-Id: I4aae8066292bf9a5dd5d94e8568cbfbca99746dc Reviewed-on: https://boringssl-review.googlesource.com/18925 Reviewed-by: David Benjamin <davidben@google.com>
2017-07-28Add some documentation for CRYPTO_BUFFERs.Adam Langley1-0/+20
Change-Id: I2b8b6b784e72c6d38ca55158a395fc2619fd47ba Reviewed-on: https://boringssl-review.googlesource.com/18606 Reviewed-by: David Benjamin <davidben@google.com>
2017-07-25Document our strict behaviour when clients attempt renegotiation.Adam Langley1-1/+3
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>
2017-03-14Restore SSL_CTX_set_ecdh_auto compatibility hook.David Benjamin1-0/+1
This was inadvertently dropped in 59015c365b53a855513aaf5f9ff4597df9157ac0. 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>
2016-08-11Add a note in PORTING to ask us before adding ifdefs.David Benjamin1-0/+3
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>
2016-07-15Add a table for porting SSL_CTX_ctrl code.David Benjamin1-1/+59
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>
2016-02-02Document the d2i object reuse changes in PORTING.md.David Benjamin1-0/+23
Change-Id: I1875c5246c7da19af13683ca36c737c188a97d18 Reviewed-on: https://boringssl-review.googlesource.com/6984 Reviewed-by: Adam Langley <agl@google.com>
2015-10-26Update PORTING.md for the new renego API.David Benjamin1-5/+6
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>
2015-10-26Deprecate SSL_library_init.David Benjamin1-4/+4
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>
2015-09-29Document the hexadecimal casing thing in PORTING.md.David Benjamin1-0/+6
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>
2015-09-03Fix a typo in PORTING.md and mention one more renego restriction.David Benjamin1-1/+4
Change-Id: I59b30882178222000dd90b051856bb2816eeb9fd Reviewed-on: https://boringssl-review.googlesource.com/5789 Reviewed-by: Adam Langley <agl@google.com>
2015-09-02Add a PORTING document which describes some major API differences.David Benjamin1-0/+154
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>
generated by cgit v1.1 at 2024-06-29 01:14:05 +0000