vendor/openssl/3.0.17vendor/openssl-3.0

7 files changed, 43 insertions, 20 deletions

diff --git a/doc/man7/OSSL_PROVIDER-FIPS.pod b/doc/man7/OSSL_PROVIDER-FIPS.pod
index 66165bdb0cc3..eb34a34a152c 100644
--- a/doc/man7/OSSL_PROVIDER-FIPS.pod
+++ b/doc/man7/OSSL_PROVIDER-FIPS.pod
@@ -421,6 +421,19 @@ validated versions alongside F<libcrypto> and F<libssl> compiled from any
 release within the same major release series.  This flexibility enables
 you to address bug fixes and CVEs that fall outside the FIPS boundary.
 
+You can load the FIPS provider into multiple library contexts as any other
+provider. However the following restriction applies. The FIPS provider cannot
+be used by multiple copies of OpenSSL libcrypto in a single process.
+
+As the provider saves core callbacks to the libcrypto obtained in the
+OSSL_provider_init() call to global data it will fail if subsequent
+invocations of its OSSL_provider_init() function yield different addresses
+of these callbacks than in the initial call. This happens when different
+copies of libcrypto are present in the memory of the process and both try
+to load the same FIPS provider. A workaround is to have a different copy
+of the FIPS provider loaded for each of the libcrypto instances in the
+process.
+
 =head1 SEE ALSO
 
 L<openssl-fipsinstall(1)>,
@@ -439,7 +452,7 @@ This functionality was added in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man7/migration_guide.pod b/doc/man7/migration_guide.pod
index e5ab29b95370..b223f856d17d 100644
--- a/doc/man7/migration_guide.pod
+++ b/doc/man7/migration_guide.pod
@@ -596,13 +596,13 @@ The code needs to be amended to look like this:
 Support for TLSv1.3 has been added.
 
 This has a number of implications for SSL/TLS applications. See the
-L<TLS1.3 page|https://wiki.openssl.org/index.php/TLS1.3> for further details.
+L<TLS1.3 page|https://github.com/openssl/openssl/wiki/TLS1.3> for further details.
 
 =back
 
 More details about the breaking changes between OpenSSL versions 1.0.2 and 1.1.0
 can be found on the
-L<OpenSSL 1.1.0 Changes page|https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes>.
+L<OpenSSL 1.1.0 Changes page|https://github.com/openssl/openssl/wiki/OpenSSL_1.1.0_Changes>.
 
 =head3 Upgrading from the OpenSSL 2.0 FIPS Object Module
 
@@ -2484,7 +2484,7 @@ The migration guide was created for OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2021-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2021-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man7/provider-cipher.pod b/doc/man7/provider-cipher.pod
index eaad3cf2ff02..c5d40a223acf 100644
--- a/doc/man7/provider-cipher.pod
+++ b/doc/man7/provider-cipher.pod
@@ -103,8 +103,8 @@ A cipher algorithm implementation may not implement all of these functions.
 In order to be a consistent set of functions there must at least be a complete
 set of "encrypt" functions, or a complete set of "decrypt" functions, or a
 single "cipher" function.
-In all cases both the OSSL_FUNC_cipher_newctx and OSSL_FUNC_cipher_freectx functions must be
-present.
+In all cases the OSSL_FUNC_cipher_get_params and both OSSL_FUNC_cipher_newctx
+and OSSL_FUNC_cipher_freectx functions must be present.
 All other functions are optional.
 
 =head2 Context Management Functions
@@ -241,7 +241,7 @@ The provider CIPHER interface was introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man7/provider-decoder.pod b/doc/man7/provider-decoder.pod
index e968e661f7cf..d19deec4af5b 100644
--- a/doc/man7/provider-decoder.pod
+++ b/doc/man7/provider-decoder.pod
@@ -110,7 +110,9 @@ it decodes. For example, an implementation that decodes an RSA key
 should be named "RSA". Likewise, an implementation that decodes DER data
 from PEM input should be named "DER".
 
-Properties can be used to further specify details about an implementation:
+Properties, as defined in the L<OSSL_ALGORITHM(3)> array element of each
+decoder implementation, can be used to further specify details about an
+implementation:
 
 =over 4
 
@@ -302,7 +304,7 @@ The DECODER interface was introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man7/provider-encoder.pod b/doc/man7/provider-encoder.pod
index f3e9ce5b1632..dadd33f9b0f6 100644
--- a/doc/man7/provider-encoder.pod
+++ b/doc/man7/provider-encoder.pod
@@ -127,7 +127,9 @@ The name of an implementation should match the type of object it handles.
 For example, an implementation that encodes an RSA key should be named "RSA".
 Likewise, an implementation that further encodes DER should be named "DER".
 
-Properties can be used to further specify details about an implementation:
+Properties, as defined in the L<OSSL_ALGORITHM(3)> array element of each
+decoder implementation, can be used to further specify details about an
+implementation:
 
 =over 4
 
@@ -321,7 +323,7 @@ The ENCODER interface was introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man7/provider-keymgmt.pod b/doc/man7/provider-keymgmt.pod
index 498ad9c4e107..8596b696c69f 100644
--- a/doc/man7/provider-keymgmt.pod
+++ b/doc/man7/provider-keymgmt.pod
@@ -29,7 +29,7 @@ provider-keymgmt - The KEYMGMT library E<lt>-E<gt> provider functions
  void OSSL_FUNC_keymgmt_gen_cleanup(void *genctx);
 
  /* Key loading by object reference, also a constructor */
- void *OSSL_FUNC_keymgmt_load(const void *reference, size_t *reference_sz);
+ void *OSSL_FUNC_keymgmt_load(const void *reference, size_t reference_sz);
 
  /* Key object information */
  int OSSL_FUNC_keymgmt_get_params(void *keydata, OSSL_PARAM params[]);
@@ -442,7 +442,7 @@ The KEYMGMT interface was introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man7/provider-signature.pod b/doc/man7/provider-signature.pod
index 1a9859eac367..05040ee39914 100644
--- a/doc/man7/provider-signature.pod
+++ b/doc/man7/provider-signature.pod
@@ -284,7 +284,7 @@ should be written to I<*siglen>. If I<sig> is NULL then the maximum length of
 the signature should be written to I<*siglen>.
 
 OSSL_FUNC_signature_digest_sign() implements a "one shot" digest sign operation
-previously started through OSSL_FUNC_signature_digeset_sign_init(). A previously
+previously started through OSSL_FUNC_signature_digest_sign_init(). A previously
 initialised signature context is passed in the I<ctx> parameter. The data to be
 signed is in I<tbs> which should be I<tbslen> bytes long. Unless I<sig> is NULL,
 the signature should be written to the location pointed to by the I<sig>
@@ -294,7 +294,7 @@ length of the signature should be written to I<*siglen>.
 
 =head2 Digest Verify Functions
 
-OSSL_FUNC_signature_digeset_verify_init() initialises a context for verifying given a
+OSSL_FUNC_signature_digest_verify_init() initialises a context for verifying given a
 provider side verification context in the I<ctx> parameter, and a pointer to a
 provider key object in the I<provkey> parameter.
 The I<params>, if not NULL, should be set on the context in a manner similar to
@@ -318,7 +318,7 @@ verification context is passed in the I<ctx> parameter. The signature to be
 verified is in I<sig> which is I<siglen> bytes long.
 
 OSSL_FUNC_signature_digest_verify() implements a "one shot" digest verify operation
-previously started through OSSL_FUNC_signature_digeset_verify_init(). A previously
+previously started through OSSL_FUNC_signature_digest_verify_init(). A previously
 initialised verification context is passed in the I<ctx> parameter. The data to be
 verified is in I<tbs> which should be I<tbslen> bytes long. The signature to be
 verified is in I<sig> which is I<siglen> bytes long.
@@ -360,8 +360,13 @@ The length of the "digest-size" parameter should not exceed that of a B<size_t>.
 
 =item "algorithm-id" (B<OSSL_SIGNATURE_PARAM_ALGORITHM_ID>) <octet string>
 
-Gets the DER encoded AlgorithmIdentifier that corresponds to the combination of
-signature algorithm and digest algorithm for the signature operation.
+Gets the DER-encoded AlgorithmIdentifier for the signature operation.
+This typically corresponds to the combination of a digest algorithm
+with a purely asymmetric signature algorithm, such as SHA256WithECDSA.
+
+The L<ASN1_item_sign_ctx(3)> relies on this operation and is used by
+many other functions signing ASN.1 structures such as X.509 certificates,
+certificate requests, and CRLs, as well as OCSP, CMP, and CMS messages.
 
 =item "kat" (B<OSSL_SIGNATURE_PARAM_KAT>) <unsigned integer>
 
@@ -421,7 +426,8 @@ All other functions should return 1 for success or 0 on error.
 
 =head1 SEE ALSO
 
-L<provider(7)>
+L<provider(7)>,
+L<ASN1_item_sign_ctx(3)>
 
 =head1 HISTORY
 
@@ -429,7 +435,7 @@ The provider SIGNATURE interface was introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy