On Mon, Jan 30, 2017 at 7:40 PM, Scott Arciszewski <sc...@paragonie.com> wrote:
> > On Sun, Jan 29, 2017 at 2:04 PM, Jakub Zelenka <bu...@php.net> wrote: > >> Hi, >> >> On Wed, Jan 11, 2017 at 6:22 PM, Scott Arciszewski <sc...@paragonie.com> >> wrote: >> >>> Hi all, >>> >>> I'm resurrecting my RFC to add libsodium as a core extension to PHP 7.2. >>> >>> >> I'm still not sure why it needs to be in the core. As I said before, >> there are lots of healthy extension that are not in the core and it >> certainly doesn't make them less used (e.g. redis, xdebug or mongo driver). >> At the end it's all about packaging... >> >> I think libsodium has lots of really good features and it's a very nice >> lib. However what makes me a bit uneasy about libsodium is that it's >> basically a one dev library which is even clearly visible in here: >> >> https://github.com/jedisct1/libsodium/graphs/contributors >> >> It is certainly a bit more risky to support such lib if it all depends on >> on one person rather than a team of developers. I'm not saying that it's >> the same but mcrypt used to be also just one developer lib... >> >> Cheers >> >> Jakub >> > > I erroneously replied off-list, and rather than forward messages that > were sent directly to me (on the offchance that they were not intended to > be public), I'll just reiterate what I said privately. From my original > email: > > I thought that it might have been meant to be sent publicly before so will reply publicly again :) > > Was mcrypt in core? > > > Yes and it was a mistake IMO (however it might have been a good idea at the time it was added as I have no idea how it was with out of core extensions at that time...) > > Is openssl still in core? > > > Yes but in this case we need to consider also the TLS part that is linked and required by other core (stream) parts so there is actually important point to have it in the core. > > If the answer to both these questions is "Yes", then it follows that > libsodium should be in the core. Especially if everyone agrees that it > should be included by default. > > > No it does not follow. Both extensions were added long time ago probably for various reasons valid at that time but currently there is no need to add new extension unless there is a some technical reason why it should be in the core (e.g. dependency of other extension or some direct hooking to the core parts). > > > However what makes me a bit uneasy about libsodium is that it's > basically a one dev library which is even clearly visible in here: > > > > You're looking at it all wrong. Look here instead: > https://github.com/jedisct1/libsodium/blob/master/AUTHORS > > > > The person who checked the code into Github may have been Frank Denis > for a lot of cases, but the code itself was written by cryptographers. > > > > Calling it "basically a one dev library" sounds simultaneously > dismissive and misinformed. (Also: There have been 58 contributors besides > Frank, which doesn't lead to your point at all.) > > > I'm aware that the algorithms are taken from the public domain implementations done by cryptographers and there are some other contributions. What I mean by one dev lib is that there is just one developer that maintains it which means for example regularly commit to the extension, handles security issues and doing releases of the lib (I should have maybe said one maintainer lib). Basically what I want to say is what happens if Frank is not able to continue development of the library for some reason. That raises chance that the library might become not maintained which is more probable than with a team of developers maintaining the lib. > > Do you know any cryptography experts? Go ask them, "What would you > rather see devs use? OpenSSL or libsodium?" and report back what they say. > To be clear: I'm fairly confident that a large majority will not choose > OpenSSL. > There is nothing that should prevent anyone to use LIbsodium if it's not in the core. You can see examples of the other popular extensions that are not in the core and are used heavily. > Furthermore, I'd like to raise an additional point. > > PHP Archive signing currently has the following options: > > - A hash function (forgery = trivial) > - OpenSSL signing (which I believe means RSA-PKCSv1.5 with SHA1; Daniel > Bleichenbacher had something to say about that in 2006, but e=65537 breaks > the public exploit) > > Putting libsodium in core allows us to add Ed25519 signatures to Phars, > which means that we can provide a reasonable level (128 bits is what I call > reasonable) of assurance that the PHP archive is authentic (assuming you > have a trustworthy public key). > > So finally some technical reason why it would be useful to have it in the core. :) It would be really good to add this and possible some other use cases (if you can come up with) to the RFC for example as a future scope. > Without putting libsodium in core, can we do that? If not, that's a solid > motivation to vote YES on this RFC. > > Conversely, let's discuss a hypothetical: If this motion is abandoned, can > you (or, rather, everyone on this mailing list working together) guarantee > that 100% of operating systems will bundle libsodium and the PHP extension > in PECL with PHP 7.2 out-of-the-box, by default? That includes Windows, > FreeBSD, OpenBSD, Debian, Ubuntu, RedHat, CentOS, and even obscure > Unix-like academic projects. 100% coverage. Not 99%. Not 50%. Exactly 100%. > > Ok I see another point which is improving adoption of libsodium in the distros. Basically sending a signal that we want to have it packaged which is another thing that could be added to the RFC to make a bit more clear. I'm not 100% sure if it's something that PHP should do but it's a good point anyway. > If we can't guarantee 100% adoption without putting libsodium in the core, > given the current political climate[1] and the history of unlawful > cryptography export restriction enforcement[2], I'd fear that OSes > (especially Enterprise Linux distributions that hold government contracts) > could be pressured against offering secure cryptography (i.e. libsodium) in > future versions of PHP. If we make it a core extension, it's included > unless you go out of the way to compile PHP without it. This means better > security by default. > > Let's be clear: Libsodium one of the highest regarded libraries that > exposes very well-studied cryptography primitives (RFC 7748, RFC 8032, RFC > 7693, etc.) with a misuse-resistant interface. It's also extremely > permissively licensed (ISC). > > If Frank Denis were to get hit by a bus tomorrow, anyone could pick it up > and continue his work. I wouldn't advise blindly trusting anyone who forks > it, but the cryptography community would likely certainly come together and > suggest which fork is most trustworthy. If nothing else, you could count on > the cryptographers whose work is bundled in libsodium to recommend a fork. > The bus factor, while a legitimate concern, isn't going to be a source of > liability for libsodium nor for PHP. > > [1]: https://web.archive.org/web/20170127070926/https:// > www.cnet.com/news/trump-apple-boycott-terrorist-iphone-san-bernardino-fbi/ > [2]: https://en.wikipedia.org/wiki/Bernstein_v._United_States > > Thanks for bringing up some good points! Cheers Jakub
