[wp-trac] [WordPress Trac] #45806: Add sodium_compat -- a libsodium-compatible cryptography API for PHP <7.2

Fri Jan 4 20:54:00 UTC 2019

#45806: Add sodium_compat -- a libsodium-compatible cryptography API for PHP <7.2
------------------------------------------+------------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:  (none)
     Type:  defect (bug)                  |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  General                       |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+------------------------------

Comment (by paragoninitiativeenterprises):

 Hi @ayeshrajans,

 > I think the first question if whether we should use libsodium before
 jumping into a the next step of providing compatibility for those who
 don't have libsodium (i.e including sodium_compat).

 That is a reasonable conversation to have, although I suspect the answer
 will be informed by the PHP community's adoption of libsodium as the
 preferred cryptography library in PHP 7.2+. It's already provided in
 Joomla and Magento.

 > In addition, sodium_compat has _not_ received a proper security review.
 While I'm aware of you requesting support support from WordPress
 Association, I still think it's premature to include a library of this
 stage in WordPress.

 This concern has been addressed here:
 https://core.trac.wordpress.org/ticket/39309#comment:41

 To summarize:

 * It's true that we have not forked over the ''probably hundreds of
 thousands of dollars'' necessary for a thorough third-party audit of this
 library against side-channels on ''every'' relevant version of PHP. Such
 an audit would depend largely on the behavior of the PHP interpreter at
 various stages in its evolution, so this is unavoidable.
 * It would be disingenuous to say that it has not received any security
 review, however. The security teams of Joomla and Magento both reviewed it
 and decided that it was suitable enough to provide encryption in their
 platforms. Neither Michael Babker nor Piotr Kaminsky are known to jump the
 shark on radical changes that they have to live with for years.

 I'd like to add two further points:

 * Who, exactly, is qualified to perform the necessary security review? And
 of those rare few that have the background necessary to provide a careful
 review, would any of them even be available for months to do so? (As the
 vendor for sodium_compat, we're immediately disqualified from this
 position, since first-party audits are meaningless when establishing
 trust.)
 * Which other libraries and components used by WordPress are held to the
 same standard being proposed here? You mentioned PHPMailer, but I don't
 recall any version of it being subjected to a third-party code audit
 before being accepted into the WordPress core.

 If the opinion of the WordPress.org team is "sodium_compat ''must'' be
 audited before it can be included", then they should have no trouble
 getting their member companies (Automattic, et al.) to pay a third-party
 to conduct such an audit to serve the community's best interest.

 Otherwise, this is a needless and excessive burden that doesn't serve the
 community's best interests. It would be reduced to a mere double standard
 that promotes bad habits.

 > With the sodium_compat library in core, we are shipping one more
 dependency to _everyone_, without a use for it right away, and with only
 plans to do in the future.

 The inclusion of sodium_compat provides at least an immediate benefit and
 a long-term benefit (and probably many more that are difficult to predict
 right now).

 **Immediately**: Plugin developers can migrate away from libmcrypt to
 libsodium ''today'', even if their plugins are deployed on PHP 5.2 right
 now, with minimal risk of migration friction caused by system
 incompatibility. Which, by the way,
 [https://wpdirectory.net/search/01D0DA4YB3Y6NCSMQ6SKYHR987 is a lot of
 plugins (over 11,000) today].

 **Long-term**: The barrier-to-entry for implementing code-signing in the
 automatic update process becomes much lower. The focus for that discussion
 can be entirely on key management and failure conditions, moving forward.

 Eventually an [https://github.com/paragonie-scott/public-projects/issues/5
 authority-free PKI] can be formalized and considered for implementation so
 that plugin developers can sign their own plugins with their own,
 privately-held Ed25519 keys.

 > Looking at the real humans involved in this library, it only had 9 non-
 Paragon contributors. All commits from these contributors are trivial
 changes such as typo fixes and small bug fixes.

 This is true, but I'm unsure of what can be done to improve this metric,
 or what the target number even is.

 > I see the Paragon IE is a commercial organization providing support
 commercial support for this library. While I'm not sure how many people
 are involved under paragonie-security Github handle, I can't help but
 notice the how much this library is attached to ParagonIE. In my opinion,
 this is not a good flag, because in case ParagonIE loses interest in
 maintaining sodium_compat, there are not enough people who are involved to
 fork and maintain this project. While WordPress includes libraries written
 by a single author, that is because historical reasons and in how small a
 certain library.

 Here's the worst case scenario:

 Let's say my coworkers and myself all get hit by a bus the day after
 WordPress releases libsodium support.

 The library is published under the extremely permissive ISC license, and
 can be forked by anyone for any reason, without any significant licensing
 or copyright burdens. The PHP community could then decide to step in for
 Paragon and decide on an "official" fork, should one be deemed necessary.

 Assuming an official fork is created, WordPress can decide whether or not
 to adopt the "official" fork or stick with the existing compat library
 until everyone is on PHP 7.2, then delete it forever.

 If, as you said, there is no one able or willing to create an official
 fork for the PHP community, then as soon as PHP 7.2 is the minimum
 supported version of WordPress, none of this will matter.

 But barring any catastrophic events that kills off everyone in our
 company, I can promise you the probability of us "losing interest in
 maintaining sodium_compat" is **0%**.

 The reason for this is simple: We're a for-profit, privately owned company
 and one of our revenue sources is enterprise support contracts. One of our
 open source libraries that we're paid to maintain (CipherSweet) has a hard
 dependency on sodium_compat. It would make no business sense for us to
 drop sodium_compat support even if we weren't already opposed to its
 abandonment.

 And if the people reading this comment can't trust our word, you ''can''
 trust our incentives, right?

 -----

 I hope this adequately addresses your concerns about sodium_compat
 support. If WordPress moves to PHP 5.3+ and Composer support sooner, an
 alternative patch (one line added to `composer.json` instead of 1 MB of
 PHP scripts) is certainly worth considering instead.

 However, it should be abundantly clear that the benefits of sodium_compat
 far outweigh the known risks, and should still significantly outweigh the
 perceived risks.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45806#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform