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. 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. 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. 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. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
