[wp-trac] [WordPress Trac] #25052: Updates and downloads should be signed

[WordPress Trac]

#25052: Updates and downloads should be signed
-----------------------------+------------------
 Reporter:  samuelsidler     |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  3.7
Component:  Upgrade/Install  |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |
-----------------------------+------------------

Comment (by bpetty):

 Replying to [comment:5 samuelsidler]:
 > Replying to [comment:4 dd32]:
 > > With that in mind, Any package signing may not bring anything extra to
 the table.
 >
 > I was under the impression that package signing would be done to account
 for installs that fall back to HTTP when SSL is broken on their servers.
 I'm not sure if that's even possible however – if SSL is broken, verifying
 a package likely wouldn't work either.

 I think this is mostly correct, unless package signing uses a different
 type of certificate/encryption that can be supported even when HTTPS
 certificate verification fails. I don't think it's worth looking into that
 incredibly small window assuming it exists though.

 I've considered bundling another 3rd party library, namely
 [http://phpseclib.sourceforge.net/ phpseclib], which provides a pure-PHP
 X.509 and PKCS!#1 implementation (while being license and PHP version
 requirements compatible), however, it really is a huge library, and I'm
 also opposed to adding yet another custom maintained 3rd party library
 that requires being stripped down, files renamed, and some minor code
 changes like most of the other bundled libs - especially on a library
 whose sole purpose is security and encryption.

 I do want to dispel a couple wrong assumptions here though.

 Even if the HTTPS efforts in #25007 are perfect and work 100% of the time,
 that does not mean that package signing is pointless, even if package
 signing is only ever done on the WP.org repositories. If we're smart about
 this, an ideal solution would use the strengths of both approaches to
 combat two different types of vulnerabilities.

 For example, if we were lazy, and only signed packages with one authority,
 WP.org, but the signed packages were easily verified against one signature
 that could be bundled with WordPress, *then* implementing that whole
 system would only protect against the exact same issues we are fighting by
 implementing HTTPS certificate verification. This also would likely have
 some implications that might make it difficult or impossible for those
 gains with premium plugins/themes.

 If we aren't lazy (and this would take significantly more work to
 implement, both on our part, and on plugin/theme authors), we implement
 package signing through the authors themselves in the same way that
 Android apps, OSX apps, and many other software distribution channels
 handle package/application signing.

 The pros:

 You need to look at package signing outside the use of that first plugin
 or theme installation. You can implicitly trust the package signature on
 first installation (assuming we never even handle certificate verification
 - if we can though, that's even better), and still gain heavy security
 benefits from it for all future updates.

 If a plugin update comes down that doesn't match the existing plugin's
 certificate, we can refuse to update. That would stop someone from
 stealing one of the Jetpack plugin committers' credentials and uploading a
 compromised update for example. Android apps do this, and we don't get
 this benefit with WP.org HTTPS alone.

 The cons:

 Performing certificate verification (validating that the certificate came
 from the correct owner) is significantly more difficult, and in some cases
 impossible to enforce as is the case with Composer right now because of
 the wide range of software sources supported. Where do you maintain an
 authoritative list of what certificate belongs to which package? How about
 for premium plugins and themes? Linux distros have a tiny web of trust,
 and can distribute the public keys with the install media directly. We
 might be able to gather some insight on a solution for this from Pyrus
 though (the new PEAR installer), which claims to support this.

 Additionally, it would be incredibly stupid to generate individual private
 keys for all authors on WP.org in order to automatically sign packages for
 them, but the alternative requires that the authors create the zip package
 on their local machines themselves, and that completely conflicts with the
 plugin/theme review system and bypasses SVN entirely for plugins (it could
 still easily work for themes though). So there's that.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25052#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software