On Sun, Jun 5, 2016 at 4:31 AM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> On 6/5/2016 10:23 AM, Scott Arciszewski wrote:
>> I'm trying to keep concerns separate. I do want to make the pluggable
>> crypto API happen, but I barely have time for this libsodium RFC and I
>> don't want to conflate the two. (Even worse: I wouldn't want the mere
>> thought of an abstract high-level API to block libsodium from getting
>> accepted.)
>>
>> Instead of /completely redesigning/ the libsodium API, what are some
>> changes that need to be made to alleviate the majority of concerns
>> ("it's not the pluggable crypto API" notwithstanding)?
>>
>> Two things to keep in mind:
>>
>> 1. If it breaks existing code that uses libsodium-php in a nontrivial
>> way, I'm going to resist the change unless it can be proven necessary
>> for the sake of everyone's sanity.
>> 2. If it greatly deviates from the experience of using libsodium in
>> other programming languages (e.g. renaming crypto_box), you no longer
>> have libsodium and thus I will resist it.
>>
>> Getting rid of redundant features (by improving existing ones, not
>> just cutting them!) is fine. Dropping scrypt, etc. is fine.
>>
>
> Keeping sodium as an extension solves all your problems. You can keep
> evolving it in any way you like without having to argue with others. No
> breaking changes, nothing. It can even be used after another API is
> introduced in core.All my problems? How do I get non-root users to install it? > We can achieve this by introducing a different API in core that uses > sodium in the background. This also allows us to exchange it without any > interruptions in userland in the future. That's the pluggable crypto API RFC, which I probably won't be able to propose until 7.2. Feel free to pick it up if you'd rather advocate for that. > If existing functions like bin2hex or hex2bin are really not good enough > than let us patch them. No need to introduce another function that does > exactly the same. Whether the two are consistent in time or not does not > change anything for userland. The resulting string is always the same. I > think that the patch for aforementioned functions would even be possible > without an RFC. Okay, that's fine by me. > The usage of names like secret box and box is simply not known to the > average user and that makes them really bad. People will have to search > the manual and dig deep until they find out that it is just about > asymmetric and symmetric encryption. We already have enough stuff that > makes no sense to the general public but to some. Put yourself in the shoes of, say, a Python developer who uses libsodium all the time who comes to PHP. If they don't find crypto_box and crypto_secretbox, they're going to get confused. > -- > Richard "Fleshgrinder" Fussenegger > Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
