[wp-trac] [WordPress Trac] #39309: Secure WordPress Against Infrastructure Attacks

[WordPress Trac]

#39309: Secure WordPress Against Infrastructure Attacks
------------------------------------------+------------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  Upgrade/Install               |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+------------------------------

Comment (by georgestephanis):

 It looks like in some of your changes -- notably `wp-
 admin/includes/file.php` and `wp-admin/includes/class-wp-upgrader.php` --
 you're using spaces instead of tabs I think?  The indentation is looking a
 bit wonky as I skim the patch.

 Minor pedantism, but in the `wp-admin/includes/class-wp-upgrader.php`
 changes there's some code style whitespace issues as well.  WordPress has
 a lot of legacy code style issues, and we just fix them as lines get
 changed -- it helps preserve the blame history.  So when you're changing
 old line 277/new line 283, it should have spaces wrapped around the
 variable inside the parentheses.

 Also, re: whether or not the `sodium_compat` uses autoloader stuff --
 relevant: #36335

 If it's possible for the next version of the patch to be split into two
 files -- one adding the library, the other containing the core file
 changes -- that may be easier to skim for differing code styles for each,
 as opposed to having to find the core files in the patch amidst the new
 library files.  Were there just the aforementioned two core files changed?

 ---

 For themes and plugins, I'm assuming that we're most concerned about the
 authenticity of upgrades.  While installations can be important, it
 strikes me that upgrades -- specifically automatic ones -- are more apt to
 be the risk area as the user isn't explicitly choosing it.

 As such, distributing public keys would likely be simplest if it were part
 of the theme or plugin file header.  At that point it would be a case of
 adding a UI into the themes/plugins repository to enable the author to get
 the hash of the generated zip/tarball/whatever from the .org side, verify
 it independently, and then paste the signature in to the wp.org ui.

 (granted, this would also mean that anything with local filesystem write
 access could change the public key, but if they have local filesystem
 write access it's game over anyways, so *shrug*)

 This can get tricky in several relatively common edge cases, but most
 notably --

 '''Changing a release after shipping it.'''  A lot of authors do this,
 even if it's bad practice.  Maybe it's tweaking a changelog, maybe it's
 just fixing some code that is generating fatal errors.  If the files in
 the package change, so would the signature.  I'm not sure what the ideal
 circumstance here would be -- perhaps to have WP.org append a .1 to the
 end of the svn-specified version number, and serve it as a new version,
 with the old version still archived (or at least the svn path and revision
 saved so it could be rebuilt)?

 ---

 Anyway, just my musings on this so far.  I'm glad we're all already in
 agreement that the `sodium_compat` library would require third-party
 verification before it is considered for inclusion into WordPress Core.  I
 have no idea if this is already in discussion up the chain or not, but has
 there been any discussion / recommendation about individuals or
 organizations with sufficient relevant expertise to actually do the
 auditing in question?

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