As these hold on to some internal resource, there can't be two
"equal" objects with different identity. Make sure the lack of
public properties doesn't result in these being treated as always
equal.
openssl_pkey_new() fetches various options from the config file --
most of these are optional, and not specifying them is not an error
condition from the perspective of the user. Unfortunately, the
CONF_get_string() API pushes an error when accessing a key that
doesn't exist (_CONF_get_string does not, but that is presumably a
private API). This commit adds a helper php_openssl_conf_get_string()
that automatically clears the error in this case. I've found that
OpenSSL occasionally does the same thing internally:
https://github.com/openssl/openssl/blob/22040fb790c854cefb04bed98ed38ea6357daf83/apps/req.c#L515-L517
Closes GH-6699.
This deprecates passing null to non-nullable scale arguments of
internal functions, with the eventual goal of making the behavior
consistent with userland functions, where null is never accepted
for non-nullable arguments.
This change is expected to cause quite a lot of fallout. In most
cases, calling code should be adjusted to avoid passing null. In
some cases, PHP should be adjusted to make some function arguments
nullable. I have already fixed a number of functions before landing
this, but feel free to file a bug if you encounter a function that
doesn't accept null, but probably should. (The rule of thumb for
this to be applicable is that the function must have special behavior
for 0 or "", which is distinct from the natural behavior of the
parameter.)
RFC: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
Closes GH-6475.
We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
Apparently treating LibreSSL as OpenSSL 1.1 is not just something
we did in our code, it's something that upstream LibreSSL claims,
despite not actually being compatible. Duh.
Check for EVP_CIPH_OCB_MODE instead, which should reliably
determine support...
While OpenSSL 1.1 allows unconditionally setting the CCM tag length
even for decryption, some older versions apparently do not. As such,
we do need to treat CCM and OCB separately after all.
OCB mode ciphers were already exposed to openssl_encrypt/decrypt,
but misbehaved, because they were not treated as AEAD ciphers.
From that perspective, OCB should be treated the same way as GCM.
In OpenSSL 1.1 the necessary controls were unified under
EVP_CTRL_AEAD_* (and OCB is only supported since OpenSSL 1.1).
Closes GH-6337.
openssl_encrypt() currently throws a warning if the $tag out
parameter is passed for a non-authenticated cipher. This violates
the principle that a function should behave the same if a parameter
is not passed, and if the default value is passed for the parameter.
I believe this warning should simply be dropped and the $tag be
populated with null, as is already the case. Otherwise, it is not
possible to use openssl_encrypt() in generic wrapper APIs, that are
compatible with both authenticated and non-authenticated encryption.
Closes GH-6333.
X509_PURPOSE_OCSP_HELPER, X509_PURPOSE_TIMESTAMP_SIGN are available
from OpenSSL for many years:
- X509_PURPOSE_OCSP_HELPER, since 2001
- X509_PURPOSE_TIMESTAMP_SIGN, since 2006
Also drop the ifdef check for X509_PURPOSE_ANY, as it is always
available in supported OpenSSL versions.
Closes GH-6312.
Jakub Zelenka