[wp-meta] [Making WordPress.org] #5352: Plugin Security - Add email confirmation prior to releases being processed

[Making WordPress.org]

#5352: Plugin Security - Add email confirmation prior to releases being processed
------------------------------+---------------------
 Reporter:  dd32              |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+---------------------

Comment (by chriscct7):

 > Ideally, the committer who committed the release would not be able to be
 the sole person who approves the release as well, which would effectively
 make this always a 2+ person scenario. Maybe an exception would be the
 same person can sign it off, as long as it's not forcefully enabled for
 the plugin due to level of usage.

 I really disagree with the premise of this idea currently, as I think it
 results in a system that actually has a far more likely tendency to hurt
 WordPress users than the problem it's attempting to solve.

 There's 2 distinct cases:
 - Adding more security for releases, because Autoupdates means anyone with
 access pushes to lots of sites
 - Trying to prevent rogue employees/committers from issuing releases.

 I think these cases are discrete from each other.

 I think a really critical, and perhaps incorrect assumption that can be
 made, is that larger plugins == more employees === more committers. I
 haven't looked at any data yet, but I suspect from personal knowledge that
 this is not true for most plugins in the top 40 (the ones with the
 millions and hundreds of thousands described as this feature being
 beneficial in protecting and therefore opt-out).

 For example, I know a lot of companies who operate the larger plugins only
 have a handful, generally 1 - 3 committers with access to commit, because
 currently there is no 2FA support on commits (and less people having
 commit access therefore is a good thing). Generally most companies that
 run the larger plugins give the committer status to owners + lead/senior
 developers.

 The result of this is that the above proposal has a tendency in a lot more
 common scenarios (common than a rogue employee) of causing more harm than
 will likely be solved.

 For example,
 - A plugin with 2 committers for example, would not be able to issue
 releases if one of the committers is currently on vacation or is sick or
 just generally away.
 - A particularly concrete example of why this idea can harm users is to
 consider the autoupdates feature itself. Let's say as a hypothetical
 example, a plugin pushes an update at 4pm in the company's operating time.
 5 hours later, hundreds of users start reporting PHP fatal errors, and an
 update needs to go out immediately. T his is a huge problem, particularly
 because of automatic updates in 5.5, because the users now automatically
 would be updating over the rolling period into the fatal error. The
 earlier the fix release can get out the earlier the less number of people
 with broken sites. Currently a committer can push out a fix, and that
 would save many/most of the sites. If however, this idea of 2 people
 signoff is implemented, the committer now needs to track down another
 person, in the middle of the company's operating nighttime, and
 potentially wake them up to get a release out the door.

 I think 2 person signoff for rogue employees should be an opt-in
 experience for all plugins, as plugins (regardless of size) with large
 numbers of committers might find it useful.

 I think that instead the email sent on committing a tag should be a time
 limited hash that allows the committer to confirm a release. I know many
 larger plugins have wanted 2FA on SVN for a while to try to add security
 for the case of a committer (whose status was knowingly granted and not
 actively revoked) having their SVN credentials accidentally leaked (for
 example like in the example Dion gave above with the WordCamp speaker).
 Adding email confirmation, while not my first choice over say TOTP based
 2FA, adds meaningful security to plugins, and I think provides a real
 value in that it avoids the 2 above examples, and in doing so doesn't have
 the potentiality to harm end-users, while adding an extra layer of
 confirmation. One note on TOTP vs Email while I have a preference to TOTP,
 since .org already requires working emails for committers for the repo, I
 think email should be offered at least as an option, whether or not TOTP
 is additionally offered.

 > Agreed. I think it should be opt-in as well. Having a single committer
 should not be a detriment to the author, and we shouldn't result in a
 state where every committer ultimately just has two accounts just to work
 it.

 Agreed with ^


 To summarize, I think the best course of action would be:

 2 Person signoff:
 - Large Plugins: Optin always
 - Smaller ones: Also optin always

 2FA (via email or TOTP for the committer to confirm a release):
 - Large plugins: optin for a month (to give some time to work out any
 issues with it and have time to committers to set theirs up), then
 mandatory
 - Smaller plugins: optin for a month(like previous), then opt-out

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5352#comment:8>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org