forked from openssl/openssl
-
Notifications
You must be signed in to change notification settings - Fork 1
[pull] master from openssl:master #664
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The server_running variable is declared as volatile and some comments in the code are mentioning about implementing CTRL+C handler in the future. In the client handling loop, the client_skt is closed at the end of the loop if server_running is true. If (future) CTRL+C handler changes server_running to false at this time. The next accept will not happen and the exit clean up code will close client_skt for the second time. This patch fixes this potential double close by setting client_skt back to -1 after closing it. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27405)
Add examples and documentation for using ML-DSA, ML-KEM, and SLH-DSA algorithms with pkeyutl. This includes information about the context-string option for ML-DSA and examples of encapsulation/decapsulation with ML-KEM. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27424)
and `ossl_quic_stream_has_send_buffer()` explicitly. This small tweak allows to find those functions more easily. Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #27438)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27706)
The SSL_set_SSL_CTX() function is used to switch SSL contexts for the given SSL object. If contexts differ, this includes updating a cert structure with custom extensions from the new context. This however overwrites connection custom extensions previously set on top of inherited from the old context. The fix is to preserve connection custom extensions using a newly introduced flag SSL_EXT_FLAG_CONN in custom_ext_copy_conn(). Similar to custom_ext_copy(), it is a no-op if there are no custom extensions to copy. The only such consumer is ossl_quic_tls_configure() used to set the "quic_transport_parameters" extension. Before this change, context switch resulted in transport parameters not being sent due to the missing extension. Initially reported at nginx/nginx#711 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27706)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27707)
Despite some recent changes to our s390 builds, we're still seeing errors due to some stringop-overflow warnings: https://github.com/openssl/openssl/actions/runs/15748518222/job/44389197443 It appears to be caused because the static analysis that gcc preforms in gcc 12 (the version of the compiler on our s390 runner), fails to infer the proper sizes of the buffer on which we do the reverse memcpy in swap_copy(), resulting in warnings, which on --strict-warnings builds, breaks us. Fix it by using inlen rather than outlen to limit the copy length, adjusting it if need be to match the size of the output buffer in le_copy(). This allows the compiler to properly infer the array length constraints and suppress the warnings. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27864)
Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #27828)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27829)
As opposed to CRYPTO_THREAD_[get|set]_local counterparts These api use an ennumerated set of fixed key ids, that allow for thread-local storage indexed by key AND libctx value. They also store this data against a single OS level thread-local key, reducing the amount of (limited) thread-local key storage space we use Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
RCU stores a per-thread local structure per context-thread, making it necessecary to move them to the new api to avoid exhausting our OS level thread-local storage resources when creating lots of contexts Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Rand instances create a thread-local storage key per context, so we need to move them to the new api to avoid exhausting our thread-local storage space at the Os level Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Thread event handlers in the fips provider create a thread-local storage key per context, meaning we can exhaust our thread-local space quickly by creating lots of contexts. Avoid that by moving to the new thread-local storage api. Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Move the err lib to use the new thread-local storage api. This isn't strictly needed, as each thread uses the same key for each context, but it does reduce our Os level key count. Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Make the async-job api use our new thread-local storage api. Not strictly needed, but reduces our OS level key usage Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Since we have a pre-defined list of keys, save some computation time by just looking up by index rather than via a sparse array Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
We don't need to allocate entries for the ctx table. we can just make it a sparse array of void* values, and set the thread-local data directly. This saves on allocation and cleanup costs Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Allow for use of default context in the thread-local api by using get_concrete This creates a problem however in that get_concrete access a thread-local api, creating a recursive call that exhausts stack space So create a special context token that identifys the no context use case when we want to store thread-local data without an explicit context index Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
With the conversion to a fixed array, we can no longer just clean the top level sparse array, as we don't enjoy the NULL check within the sa_doall loop. Add a NULL check in the fips cleanup routine to make up for this Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
This thread-local key isn't per thread*context, and is potentially in a hot path for users of openssl that switch their default contexts regularly, so lets leave it as an OS level key, rather than a library managed key. Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
We currently have a single function that does thread_local key allocation/cleanup/fetching for our OSSL_init_thread_start/stop apis, and its pretty confusing. Wrap it up in some helper functions to make it more clear at the call sites what we're trying to do. Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
The naming of the thread-local management functions in initthread.c is a bit...much. init_manage_thread_local/init_fetch_clear_thread_local, etc are better written as just manage_thread_local/clear_thread_local/etc. Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #27794)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )