On Mon, Jan 30, 2017 at 4:37 PM, Jakub Zelenka <bu...@php.net> wrote:
> 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 > > I will update the RFC as suggested. Thank you! Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>
