Hi
On 2026-10-27 10:25, Sjoerd Langkemper wrote:
I have created an RFC to add the function openssl_get_channel_binding:
https://wiki.php.net/rfc/openssl_get_channel_binding
PR: https://github.com/php/php-src/pull/24035
The function exposes data related the an established TLS connection,
making it possible for applications to build on top of the security
provided by TLS. It is needed for SASL mechanisms such as
SCRAM-SHA-256-PLUS.
Thank you for the RFC. I have given it a read. First things first: Don't
forget to adjust the RFC Status to “Under Discussion” and to link the
discussion thread (https://news-web.php.net/php.internals/132941).
Content-wise:
1. “The function returns null when the requested type is not applicable
to the connection.”
An operation that is not applicable sounds like an Exception to me. Is
there currently any other situation where `null` is returned?
Edit: I'm noting that this is already listed under “Rejected Features”.
I'm not sure I agree with the reasoning, though: Exceptions are the
standard way of indicating unsupported operations / error situations and
the Exception hierarchy is specifically designed to be caught.
2. “$stream is a stream, but it has no active OpenSSL TLS transport”
That sounds like a programmer error, thus `Openssl\OpensslError` (or
potentially ValueError).
3. “An OpenSSL call fails while computing the value”
Is this one reachable in practice or is this more of a generic “catch
all” error that cannot really happen?
4. “Because the second parameter is an enum, the function itself no
longer has an unknown-type error. […]”
This paragraph should probably not be mentioned in the RFC since it
effectively describes a prior version of the PR / describes how enums
work.
5. “The backing values preserve interoperability: $type->value is the
IANA name, so it can be forwarded to SASL or other protocol code
unchanged.”
This indeed seems to be a rare case of a backed enum being the right
choice.
6. “Userland code that declares a function with the same name without a
function_exists() guard would fail with “Cannot redeclare function
openssl_get_channel_binding()”
As I had noted in https://news-web.php.net/php.internals/132938, a
`function_exists()` check is no guarantee that the code keeps working,
because the previous userland implementation might do something else.
That should be rephrased - but of course `openssl_*()` is reserved by
ext/openssl and defining new symbols is explicitly acceptable as per
policy.
7. RFC Impact to “To Existing Extensions”
Are there perhaps any extensions that might want to make use of the new
functionality internally? For example pdo_pgsql, I'm noting that the RFC
mentions tests against PostgreSQL?
Best regards
Tim Düsterhus