On Sun, Jan 10, 2016 at 4:59 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 10/01/2016 21:41, Scott Arciszewski wrote: >> >> Hi Rowan, >> >>> >I think what people are suggesting is not that libsodium shouldn't be >>> >supported under-the-hood, just that the fact you're using it shouldn't >>> > be >>> >exposed to userland. >> >> These are separate concerns. Let's call them Sodium and SimpleSodium. >> >> With Sodium, power users gain the ability to write software that >> directly uses low-level primitives in PHP without requiring their >> users to install dependencies (i.e. from PECL). [ >> >> SimpleSodium is a driver for the simple cryptography wrapper. > > > As noted on the other thread, I think what people are looking for is > actually somewhere between the two - something for power users to use > *without tying their code to libsodium*. Code written using mcrypt_* > functions is now facing an annoying upgrade path; code written with sodium_* > functions now may face the same some years in the future, who knows? > > PHP should not be maintaining its own low-level implementations of crypto, > but it should seem to the user as though it does - they should be asking PHP > for a particular cipher / mode / etc, not asking libsodium for one via a > thin PHP wrapper. > > >> You can have SimpleSodium without Sodium, but if we don't get Sodium into >> core >> I will, personally, not be putting forth one more ounce of time or >> effort into helping the PHP core so who knows maybe not? > > > Obviously, this is entirely your prerogative, but it seems quite a > black-and-white stance - maybe leave a bit of leeway for understanding other > people's concerns before threatening to abandon work which would be very > much appreciated. > > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Hi Rowan, > As noted on the other thread, I think what people are looking for is > actually somewhere between the two - something for power users to use > *without tying their code to libsodium*. Code written using mcrypt_* > functions is now facing an annoying upgrade path; code written with sodium_* > functions now may face the same some years in the future, who knows? And I'm of the opinion that most users need a library that does everything for them, and power users need a toolkit, and we shouldn't try to solve both use cases with the same library. Some people might be allergic to having two separate tools for two separate jobs, but I am not one of them. Power-users will need low-level cipher implementations, most developers will only write insecure code if we let them. If libsodium gets obsoleted (unlikely), it will be because of the availability of practical quantum computers, which also obsoletes openssl and all existing public-key cryptography. Mcrypt is unique in that it was completely abandoned (and poorly designed, to boot) after adoption. I don't think this is a meaningful discussion to have right now, given how widespread it is. https://download.libsodium.org/doc/bindings_for_other_languages/index.html > PHP should not be maintaining its own low-level implementations of crypto, > but it should seem to the user as though it does - they should be asking PHP > for a particular cipher / mode / etc, not asking libsodium for one via a > thin PHP wrapper. There is little in common between openssl and libsodium. Go look at the cipher options in libsodium; it forces you to use conservative, secure ciphers. OpenSSL lets you encrypt in DES-ECB without complaint. > Obviously, this is entirely your prerogative, but it seems quite a > black-and-white stance - maybe leave a bit of leeway for understanding other > people's concerns before threatening to abandon work which would be very > much appreciated. I'm just letting it be known now where I stand with this now rather than later, so if this libsodium initiative doesn't pass and I suddenly drop off internals and delete the relevant Github repositories for the other projects I proposed, there will be no question as to why. I believe in being explicit and forthcoming. 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
