On 26/05/2015 23:52, Scott Arciszewski wrote:
That's fair, and one of the reasons I wanted to make ext/libsodium part of
the core was so that segueing into a PDO-style cryptography API would be
more natural. Instead of "wrap openssl and maybe wrap libsodium if it's
already installed" it would be "wrap what the language already has".
Am I mistaken in believing this would be the way forward?
Well, it doesn't quite match how PDO works, as I understand it -
ext/pdo_pgsql isn't implemented on top of ext/pgsql, the two are
separate extensions built on top of the libPQ library which Postgres
provides. The "PHP Crypto Objects" equivalent would be "wrap openssl in
ext/pco_openssl, wrap libsodium in ext/pco_sodium".
The dependency management would be no different between ext/openssl and
ext/pco_openssl - PHP doesn't *provide* OpenSSL or mcrypt, it
*optionally* depends on them, and the same would be true of libsodium,
whatever the bindings looked like.
As such, bundling an extension which directly exposes libsodium's
functions isn't really a pre-requisite for a pluggable architecture, and
could harm the effort by being "too good" and allowing the short-term
"good enough" solution that Anthony is afraid of.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
