[wp-trac] [WordPress Trac] #49200: Allow Developers to Cryptographically Sign Their Own Plugins/Themes with the Gossamer Public Key Infrastructure (PKI)

[WordPress Trac]

#49200: Allow Developers to Cryptographically Sign Their Own Plugins/Themes with
the Gossamer Public Key Infrastructure (PKI)
------------------------------------------+------------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:  (none)
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  Upgrade/Install               |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:                                |     Focuses:
------------------------------------------+------------------------------

Comment (by ayeshrajans):

 Thank you for posting the ticket @paragoninitiativeenterprises . I'm not a
 decision maker here, but I would like to put my thoughts up as someone who
 is active/invested in Drupal and Phar-io package updates and signing.

 Without going in detail for possible padding attacks or possibility to
 select to bad ciphers, I find the update signing in Composer and Phar-IO
 to be least invasive yet functional. They rely on openssl and gpg, which
 had several security vulnerabilities, but are trusted available to be used
 by pretty much every LAMP stack.

 I appreciate the amazing and often unfathomable effort you have put in
 developing these libraries such as Sodium compat, Chronicle, and now
 Gossamer. I'm sure those who use it will certainly appreciate it too. If
 this were to go in WordPress core, I would like to point out the amount of
 trust WordPress community has to put on your work. I remember the last
 time this topic came up, the conversation was stalled at a point about
 lack of an audit in `paragonie/sodium_compat` package. A fully implemented
 Gossamer + Chronicle instances would assume many packages from the same
 vendor:

  - paragonie/certainty
  - paragonie/easydb
  - paragonie/sodium_compat
  - paragonie/slim-sapient
  - paragonie/blakechain
  - paragonie/sapient

 Further, because Chronicle package builds on top of Slim, we will be
 trusting `slim/slim` and related packages too.

 I doubt there are other active members in WordPress community that are
 familiar with these libraries (other than you of course). In addition to
 trusting all your packages, this will add maintenance overhead for package
 updates, security releases, and general bug fixes. If it takes 2 versions
 to add a package, it would take at least 5 to remove it. Libraries that
 once had maintainers are not practically maintained by WordPress
 community, such as kses and a considerable amount of packages in `wp-
 includes`.

 WordPress already carries several libraries in both PHP and JS
 departments, and keeping up with their updates is not easy, nor happens in
 a regular or pragmatic fashion. Because of the lack of an audit, and the
 novel approach instead of using established PKI, all these 35.5% of web
 sites would be indirectly trusting your organization to keep the word and
 take ''your'' PKI approach instead.

 I think the question ultimately comes down to the politics and trust
 considerations whether WordPress community is ready to trust all the
 packages above to function correctly, will be maintained, secure, and
 whether the PKI approach can stand against the masses. OpenSSL package
 probably had been reviewed many times by bounty hunters and security
 professionals, and yet Heartbleed took a long time to be discovered. What
 sort of trust do we (as WordPress community) has for Gossamer to be
 included by default in world's most wide-spread web platform?


 Although WordPress comes as a single easy to use package, most modern
 deployments in fact use packages projects and packages such as
 [https://wpackagist.org/ wpackagist],
 [https://github.com/johnpbloch/wordpress johnpbloch/wordpress] and
 [https://github.com/roots/bedrock roots/bedrock]. I also maintain
 [https://github.com/phpwatch/WordPress-Security-Advisories WordPress-
 Security-Advisories]. None of these packages come bundled, and they have
 to earn the trust of the community. As someone who wishes WordPress (and
 many PHP packages for that matter) to adopt automatic updates that trust
 for developers are established without secure channels or middleman, I
 really wish your efforts will fruitful. May I ask what prevents you from
 providing this solution as a plugin? I'm sure WordPress provides necessary
 hooks to validate updates before they are written to disk. If the
 necessary hooks do not exist, it would be relatively easy and bite-size
 patches to WordPress core to be accepted.

 If the community accepts this plugin as a de-facto update guard plugin,
 I'm sure the decision makers will be inclined to ship the solution along
 with WordPress core.

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