All other private keys are exported in PKCS#8 format, while EC
keys use traditional format. Switch them to use PKCS#8 format as
well.
As the OpenSSL docs say:
> PEM_write_bio_PrivateKey_traditional() writes out a private key
> in the "traditional" format with a simple private key marker and
> should only be used for compatibility with legacy programs.
Same as with pkcs7, switch these tests to use an algorithm that
OpenSSL 3 supports out of the box.
Once again, we should consider changing the default or making it
required.
The default of OPENSSL_CIPHER_RC2_40 is no longer (non-legacy)
supported in OpenSSL 3, specify a newer cipher instead.
We should probably either change the default (if acceptable) or
make the parameter required.
Instead construct a proper EVP_PKEY for the public key and
perform a derive operation.
Unfortunately we can't use a common code path here, because
EVP_PKEY_set1_encoded_public_key() formerly known as
EVP_PKEY_set1_tls_encodedpoint() does not appear to work with
DH keys prior to OpenSSL 3.
Rather than querying whether the EVP_PKEY contains private key
information, determine this at time of construction and store it
in the PHP object.
OpenSSL doesn't provide an API for this purpose, and seems
somewhat reluctant to add one, see
https://github.com/openssl/openssl/issues/9467.
To avoid using deprecated low-level APIs to determine whether
something is a private key ourselves, remember it at the point
of construction.
The recent fix for bug 52093 is not compatible with LibreSSL ≥ 2.7.0,
which we recognize as mostly OpenSSL 1.1.0 compatible, but they still
do not support `ASN1_INTEGER_set_int64()`.
Closes GH-7339.
With OpenSSL 3 ciphers may be registered, but not provided. Make
sure that openssl_get_cipher_methods() only returns provided
ciphers, so that "in_array openssl_get_cipher_methods" style
checks continue working as expected.
zend_double_to_str() converts a double to string in the way that
(string) would (using %.*H using precision).
smart_str_append_double() provides some more fine control over
the precision, and whether a zero fraction should be appeneded
for whole numbers.
A caveat here is that raw calls to zend_gcvt and going through
s*printf has slightly different behavior for the degenarate
precision=0 case. zend_gcvt will add a dummy E+0 in that case,
while s*printf convert this to precision=1 and will not. I'm
going with the s*printf behavior here, which is more common,
but does result in a minor change to the precision.phpt test.
This used to be necessary in the past because the NUM_BUF_SIZE
was set to 512, which is shorter than DOUBLE_MAX_LENGTH. Now the
value is either DOUBLE_MAX_LENGTH or larger (2048).
We don't guarantee any particular order, but this reduces test
failures under --preload that are sensitive to class order.
Add some ZEND_HASH_FOREACH_*_FROM macros to allow skipping the
persistent classes while iterating in forward direction.
