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

[WordPress Trac]

#39309: Secure WordPress Against Infrastructure Attacks
------------------------------------------+-----------------------------
 Reporter:  paragoninitiativeenterprises  |       Owner:  pento
     Type:  task (blessed)                |      Status:  reopened
 Priority:  normal                        |   Milestone:  Future Release
Component:  Upgrade/Install               |     Version:  4.8
 Severity:  critical                      |  Resolution:
 Keywords:  has-patch                     |     Focuses:
------------------------------------------+-----------------------------

Comment (by pento):

 @paragoninitiativeenterprises: Thank you for expanding on your position in
 your blog post. There are a few things to clarify here.

 The current signature implementation ''does not'' protect against a pwned
 server. As the initial focus was concerned with checking compatibility,
 the update process in Core only generates a warning when there's a
 signature mismatch, it doesn't block the update. Additionally, the
 WordPress.org implementation needs significant work to ensure private keys
 are appropriately secured, and signing can only be done by authorised
 release managers.

 The current key expires in ~18 months, so if we were to move towards
 strictly enforcing signatures, there's a significant amount of work to do
 before then, and we'd want to be rolling it out well in advance of the
 expiry. @dd32 outlined 5 questions that need answering in [#comment:89 his
 earlier comment], it seems like only number 3 can be delayed for now, as
 it mostly applies to signing plugin/theme updates. We still need solutions
 for all of the others, hence asking about Gossamer or alternative options.

 These are the primary reasons removing the signing code ''for now'',
 pending a more complete solution.

 And to reply to a couple of points on your blog post:

 > WordPress's core developers think that server-to-server TLS (which
 protects data in transport) is adequate to address the problem of secure
 code delivery.

 This isn't true, no core developer has claimed that TLS is adequate for
 addressing secure code delivery, simply that it's better than the existing
 checks. I appreciate that what's been proposed isn't ideal, but
 misrepresenting the situation isn't helpful.

 I'd love to see package signing implemented properly, but what we have
 right now is not it. Actually getting to proper package signing will
 require quite some effort, so in the mean time, removing the test
 signature checking we're currently doing helps ensure we're not trying to
 implement it in the future across several different branches, and
 potentially with expired keys in the mix.

 > Rolling back the signature verification on WordPress core updates is
 reckless and negligent, and should be strongly discouraged.

 Could you clarify in what way rolling back the currently non-functional
 and incomplete signature verification is reckless or negligent? It seems
 like the opposite is true: leaving testing code running in production
 after we've gotten results is lazy at best, and at worst could lead to
 significant maintenance issues that affect the critical auto update code
 paths.

 The test produced good results: we're able to sign packages in a way that
 all WordPress installs can verify, this is a good direction for us to
 continue to head. Generating and verify the signature is a very small part
 of this project, however, what we need now are the tools and procedures in
 place to ensure we can do this long term.

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