PHP RFC: Migration Hash Context from Resource to Object
- Version: 1.0
- Date: 2016-12-26
- Author: Sara Golemon pollita@php.net, with initial implementation from Rouven Weßling me@rouvenwessling.de
- Status: Accepted
- First Published at: http://wiki.php.net/rfc/hash-context.as-resource
Introduction
Since PHP5, objects have been the preferred structure for wrapping internal data, however some clod created the hash extension to use resources. This RFC seeks to rectify that error by migrating the Hash extension to use an object implementation for hash contexts instead of a resource.
Proposal
Convert the opaque resource to an opaque object. This is the lightest touch change to ensure that existing code should continue to function unless it has explicit is_resource() checks. These checks can be easily replaced with is_resource|is_object checks instead.
Future Scope
- Actual oop interface in the form of a few methods: HashContext::__construct() mirroring hash_init, HashContext::update() mirroring hash_update, etc...
- String casting to invoke `->final()` - Probably a bad idea as the object becomes immutable once it is finalized.
- Comparison overloading - Handy, but should explicitly use hash_equals() algorithm to avoid timing attacks.
- Operator overloading (e.g. `$b = $a + 'foo';` ~= `$b = clone $a; $b->update('foo');` - Probably a bad idea, but included for completeness.
- Serialization/Deserialization - Potential (but unconfirmed) security issues as the internal hash state becomes visible and previously impossible replays may become available.
Backward Incompatible Changes
Any userspace code which explicitly type checks HashContext values using is_resource()/get_resource_type()
Proposed PHP Version(s)
PHP 7.next
Open Issues
Finalizing a hash context currenly invalidates the resource via `zend_list_close()` making all future operations on that value fail. This patch emulates this by clearing the internal value `context` and verifying it in all function invocations using the value. This isn't typical object behavior, but minimizes BC breakage. We could potentially invoke hash_copy() to save the context prior to finalization, finalize it, then revert to the prior state by restoring the saved context. This makes sense to me, but introduces a change to behavior which needs to be discussed.
Proposed Voting Choices
Include one or both patches at https://github.com/php/php-src/pull/2309 50%+1 required.
This primary vote is to determine, overall, if the “hash context” resource used by hash_init/hash_update/hash_final should be changed to an object.
This second vote, contingent on passing the first vote, determines which behavior the new HashContext will adopt (per the “Open Issue” above).
- “Frozen”: Only apply the original patch which will invalidate the HashContext object upon calling hash_final(). This is consistent with the current behavior of the resource, but inconsistent with most class/object definitions in PHP.
- “Reentrant”: Apply both diffs in PR#2309 which will allow contexts to continue functioning after calling hash_final() by effectively performing: $saved = hash_copy($ctx); $ret = hash_final($ctx); $ctx = $saved;
Voting opened: 2017-01-17 22:50:00 UTC
Voting closes: 2017-01-31 23:59:59 UTC
Patches and Tests
- Implementation for PHP 7.2 https://github.com/php/php-src/pull/2309
- Original PR by Rouven Weßling: https://github.com/php/php-src/pull/660