Dev Chat summary – March 25, 2020

@francina facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 11 of the 5.4 release cycle.


WordPress 5.4 Release Candidate 4 was released on Tuesday March 24, 2020 and everything went smoothly.

@audrasjb shared an update on WP Auto-updates Feature Plugin: it was moved from his personal GitHub account to WordPress/wp-autoupdates which is the new official GitHub repository of this project. The #core-auto-updates team will try to ship version 0.4 before WP 5.4 is released. This new version aims to handle auto-updates for themes.

@afragen asked for a review of some Trac tickets which are all associated with Theme compatibility checks and will likely have interaction with the auto-updates feature. The idea is to ship them early in WordPress 5.5.

@whyisjake pointed out that he really like the work that is going on in #core-auto-updates Slack channel and think that trying to land in the next few releases would be excellent. Related, He’d love to see #core-passwords (two-factors authentification – 2FA) land in core too. In his opinion, the plugin is so mature at this point that having it left out almost seems like an omission. @whyisjake is going to work on a merge proposal.

@clorith raised that it would be necessary to make sure that the 2FA proposal also highlights the concerns with how to address users locking them selves out (which was the major holdback previously).

@azaozz announced that the patch for image lazy-loading attribute is ready for testing.

Upcoming Releases

The current major is 5.4, scheduled to go out on March 31st 2020; please keep testing for all the bugs!

There are two ways do it:

Trunk has been branched to 5.5 on the beginning of March. That means 5.5 is officially in Alpha.

@francina announced that work for 5.6 –which is going to be an all-women release– has kicked off with an initial round of messages going out to the women that expressed interest. @angelasjin @francina and Chloé Bringmann are contacting them to hear if they are still interested, what skills they have and what expectations.

Components Check-in

@francina shared a proposal to change the Components Check-in. This is always done towards the end of the chat and feels rushed. There is never really time to dig into the topics they might bring up. Francesca shared two ideas:

  1. Schedule a weekly post where they can leave their status update, like the one for Community deputies.
  2. Adopt a Slack Bot that once a week will ask the maintainers for a status update: maybe in a new component-maintainers Slack channel. Core is getting very busy with Trac and Travis bots, and RSS.

@johnbillion added that trying a weekly post could be a good idea. Maybe every Tuesday so it’s ready for the dev chat on Wednesdays in case anything comes up.

@francina proposed to talk to #meta to set this up and test drive it for 8 weeks.

Open floor

@isabel_brison proposed to create a set of guidelines for Internet Explorer support. The CSS team kind of decided on starting to deprecate it, and “graceful degradation” seems a good way to go forward, meaning Core can use unsupported technology to make non-essential enhancements. Isabel wants to agree on what’s “essential” here, and created a Trac ticket to start the discussion: #49696

@paaljoachim suggested to punt default full screen mode to 5.5 as there is a pull request on Gutenberg project GitHub repository to provide an alternative approach.

@audrasjb pointed out that the proposal in this pull request would be a way better than the current implementation.

@whyisjake added that this is not a realistic change for WP 5.4, it’s a proof of concept, and not a fully tested feature.

@francina confirmed that @matt took the decision to ship WordPress 5.4 with this feature. Matt also commented in the Accessibility Team statement post.

@joyously stated it’s hard to contribute when concerns are ignored. @chanthaboune answered she can understand how they can feel ignored. A lot of that research gets done solo, and it’s often hard to remember to recap your own research. For full site editing to be a reality by the end of the year, the work can start bringing incremental changes. This change is feeling very jarring, but there is more worry about not have any mid-point between here and Full Site Editing.

@peterwilsoncc, @clorith and @audrasjb agreed that since RC4 was released, it’s not realistic to revert this change. The discussion can continue in a post-mortem post on Make/Core.

#5-4, #5-5, #5-6, #dev-chat, #feature-autoupdates, #feature-lazyloading, #two-factor

Dev Chat summary – February 12, 2020 (5.4 week 5)

@davidbaumwald facilitated the chat on this agenda.
@audrasjb and @marybaum took care of publishing the meeting notes.

Full meeting transcript on Slack

This devchat marked week 5 of the 5.4 release cycle.


WordPress 5.4 Beta 1 was released on Tuesday 11 as expected 🎉

Highlighted posts

Upcoming releases – 5.4

As mentioned, WordPress 5.4 Beta 1 was released on February 11th, 2020.

Please help by testing the Beta and reporting any bugs on WordPress Trac (or Gutenberg GitHub repository).

The Docs squad has published the first two dev notes:

The idea is to publish dev notes as soon as possible during the beta cycle and then publish the Field Guide before Release Candidate.

@audrasjb offered a quick update on Automatic Updates for Plugins and Themes. Because there is still work needed, along with extensive testing, decision is to start by managing autoupdates in a feature plugin and then merge into Core for 5.5.

Work on this feature plugin will start in the coming weeks.

Components check-in

@valentinbora is the new Administration Component maintainer.

In 2014, Administration was proposed to be moved from a component to a focus so it wouldn’t end up as a dumping ground for tickets. That decision led to its removal from the Components page, but not anywhere else.

Recently, this component returned to the Components page as per this Meta ticket, and it turned out that Administration still has a lot of tickets. The long term idea is to triage all the tickets that are there and, as part of that process, move those tickets to other components with the administration focus.

@whyisjake is now a Security Component maintainer.

Open floor

@whyisjake told the group that he’s going to help Two-Factor Authentication, currently developed on GitHub, move toward becoming a feature plugin for WordPress Core.

A first step: a proposal on Make/Core. @desrosj and @clorith are also interested in the project, which has been a discussion topic in the core-passwords Slack channel and in this GitHub pull request.

@whyisjake shared that he attended the CMS Security Summit last week, and Two-Factor Authentication was a major takeaway from the event, as was bringing automatic updates into Core.

@xkon added that #49200 needs input, so the team asks for yours. If you have any interest at all in cryptographic signature for plugins and themes, please follow the discussion on the dedicated Slack channel, core-signatures, and consider helping out.

#5-4, #auto-update, #security, #two-factor

REST API Authentication

On Thursday of last week, we had an Authentication chat in #core-passwords — truth be told, the discussion spilled over into Friday and a bit on Saturday as well. I delayed posting this summary a bit to make sure there wasn’t anything else about to be said that I’d miss.

Spoiler alert: we didn’t decide anything conclusively, it was more brainstorming and voicing possibilities.

Also worth noting is that we place equal weight on the user experience of the authentication system as we do on the security when evaluating it for core. That isn’t to say that we value the security any less, but rather that we also view the UX as critical to nail down as well, and is likely easier to suss out problems earlier on in casual conversation than evaluating the eccentricities of crypto. So if some of the discussion tended more towards UX considerations than Security considerations, be aware that both are critical, we were just tending to evaluate the UX first, as it’s an easy litmus test for whether a particular method is worth pursuing, and more easily understood by more people than the intricacies of replay attacks and the sort.

There were two major areas of discourse that were addressed: Authentication Scheme, and Authentication Scope.

Authentication Scheme

The scheme would be one of several possibilities, such as OAuth 1.0a, OAuth 2, Application Passwords sent as Basic Authentication, or some other either ad-hoc or previously unconsidered system.

There are assorted concerns with various systems:

  • HTTPS — WordPress cannot guarantee that the site will be hosted on a HTTPS infastructure, and as such, any API tokens passed along with the request could potentially be sniffed in transit. However, if the site doesn’t have HTTPS available, the same thing happens on every page you view already with your authentication cookies. The major difference being that cookies become invalidated on logout or expiration, so cookie thieves have a smaller window to exploit the stolen authentication than tokens that are valid until revoked.
  • OAuth Application Registration — The user experience flow for OAuth can be particularly tricky. Imagine it: You’ve just installed an app on your phone, and you want to link it to your user account on your WordPress site. Your steps are as follows: Log in to your WordPress site, Create an AppID for the phone app, give the phone app it’s Secret tokens. Now from the Phone app, you click a button to go back to your site and approve the link to your user in the application and exchange user access tokens. That is a /lot/ of back and forth-ing. It could be simplified somewhat if there was some sort of central repository for all WordPress sites that apps could register at, and then .org sites could dynamically pull down public keys for applications that they can use to verify the secrets in the apps, but that then becomes a significant amount of overhead for the construction and maintenance of the application ‘clearing house’ and it’s been clarified that it is not something that (the website) is up to build or host. Long story short: this UX flow is so confusing that it really feels much more like plugin territory at its current iteration.

Probably some other points I’m missing, but those felt like the major two.

Authentication Scope

The second issue at hand is one of Authentication Scope. That is, when an application authenticates, what functionality is it permitted to do?

This is significantly different from user capabilities. We had discussed an extra field when auth’ing applications where you could ‘downgrade’ your user role for that application’s API requests (that is, if you’re an Administrator, you could only give an application Author capabilties), but that doesn’t really solve the issue — as every user role has the ability to — for example — update their password or email address. And if an application can do that, then that’s the ballgame, and they can log in to wp-admin as you and do whatever they like.

We also talked about perhaps just disallowing certain functionality from ever being used as a part of the REST API. However, with the rise of third-party site management applications, such as Calypso, or if other programs like ManageWP or InfiniteWP or whatever the other half dozen ones are wants to truly manage your site, they’ll need access to that functionality. After all, what’s the point of aiming at eventually achieving REST API parity with the wp-admin experience if it can’t be used anywhere outside of wp-admin?

The solution we seemed to be leaning towards is a ‘two-tiered’ scope system. That is, provide a default ‘content’ tier — akin to the functionality of the legacy XML-RPC API — that can support writing and updating posts, taxonomies, comments and the like (and any custom endpoints that are explicitly opted in to the limited tier), and a second ‘full control’ tier that allows access to everything — plugins, themes, users, what have you. The second tier would be suited for full control applications like Calypso or remote management tools, whereas the first more limited tier would be more than adequate for the functionality in the legacy WordPress mobile apps, or blogging applications like Desk or Microsoft Word integration. It’s simple enough for users to understand, and technologically could be passed in via the `$args` array to `register_rest_route()` whether an endpoint should be available or not.

Still with us? Thanks for slogging through a somewhat lengthy summary, we’d love to hear your thoughts below on anything you think we missed or didn’t consider sufficiently in depth.

If anyone would like to read the full discussion, it starts here in the Slack logs:

#application-passwords, #authentication, #rest-api, #two-factor

The Two Factor Plugin is currently on a…

The Two-Factor Plugin is currently on a brief hiatus, while we work on splitting off it’s Application Passwords feature into a smaller, solo feature plugin.

Application Passwords was initially a sub-feature of Two-Factor Authentication, but due to the fact that we had very little confidence in Two-Factor being ready for the 4.5 cycle, we spun off a nearly-complete sub-feature that may mesh very well with the existing REST API.

Application Passwords lets each user choose to generate “Application Passwords” — randomly generated 16-character alphanumeric codes, that are only displayed to the user once, upon creation. These passwords can be revoked either individually or all at once, and track usage, so in the admin UI you can view the most recent IP and Date that the password in question was used.

The passwords are only valid for non-interactive prompts. That is, for use with our XML-RPC and REST APIs. They can not be used on `wp-login.php` or to access the admin panel. The idea is that each application you connect to your WordPress account — a mobile app, if this then that, Microsoft Word, or some sort of local blogging software, they all have their own password that can be revoked if the device is lost or no longer in usage, all without dispensing full access to your account.

For folks building a quick one-off script that needs to tie into WordPress, this is far simpler than using the obscure oAuth version that Core has to use because we can’t guarantee HTTPS, and far more secure than the existing “use your account password for api calls” standalone plugin, that many folks would likely choose to default to otherwise.

Screen Shot

Code reviews, issues, and pull requests are very welcome.

#feature-plugins, #two-factor

2FA! 2FA! 2FA!

Howdy, all! I’m back, and we’re getting the Two-Factor Train rolling again!

We had our first meeting yesterday at the usual time (22:00 UTC / 5pm Eastern) in #core-passwords.

Following some critical feedback and discussions both at the Community Summit and at WordCamp US, we’re adjusting our focus. Technical feasibility is turning out to be far less of a concern than ensuring we don’t create an undue support burden by users getting locked out and providing a way back in.

Previously, we had been anticipating the primary way to override a loss of their second factor would be either adding a constant or modifying the database records (either directly or via a shell tool such as WP-CLI). However, we have had a number of concerns from assorted interested parties, and the fact of the matter is that it is feeling like too high of a barrier for many WordPress users. As @macmanx (new Forums Team Rep) summarized in our chat yesterday,

I’ll say it this way: We want users to be able to secure their sites with 2FA, not sit back and watch outdated abandoned sites pile up because they locked themselves out and simply give up when when we mention FTP, Database, or SSH.

So, there are several things that have been brought up:

Require a constant in `wp-config.php` to enable 2FA

The idea being that, by adding a constant to wp-config, the user has demonstrated that they know how to use FTP and edit files on their server manually, so if all goes to heck, they have the ability and knowledge to take the constant back out, so they can get back into their site admin.

I feel that this is a bad idea, because it violates many of the WordPress Core Philosophies. It wouldn’t work out of the box, and we’re no longer designing for the majority. It results in us adding not only an option, but an option that’s hard to set.

If we have to hide it behind a constant, I feel that it shouldn’t even be in Core, and would be better left as a plugin.

(yes, I know Multisite runs this way, but there are other reasons that was merged into core)

Require multiple providers being enabled

The idea here being that if the user has two, there is less likelihood of getting locked out as they’d have a backup. However, for myself, I can’t tell you how many times I’ve downloaded backup codes and promptly lost them. Or how many times my phone has been destroyed (washing machines and phones shouldn’t be friends). There’s still a lot of opportunity for things to go wrong, especially on the scale of powering a quarter of the web. Edge cases become commonplace. 🙁

Send Text Messages

No can do, this would require a third-party server to send them through, and that’s plugin territory.

Leave Emailed Codes as an always-available fallback

This, I feel is our best option.

There are some concerns regarding the large percentage of WordPress sites that are on servers that can’t send email (as high as 25% by some guesstimates I’ve heard floated), so we’d need to send a code and make sure it gets received before turning on the actual two-factor login prompt.

While it doesn’t provide the best security (if someone breaks into your email address, they could both reset your password and get the incoming authentication code), it is 1) no worse than the status quo, 2) not our responsibility to keep secure, and 3) if they’ve broken into your email, you probably have bigger concerns.

We can certainly include a filter for methods to disable / add from plugins, and so if someone wants to disable email manually, they totes can. By explicitly disabling the Core security feature, they’re then demonstrating that they know enough to fix it if it goes wrong.

In the end, my feelings were largely best summed up by @michael-arestad, describing the two ways of balancing ease of use versus airtight security:

Ease-of-use: core potential
Airtight security: plugin town

And we can always ship the plugin ourselves to let folks disable Email, but that feels like if it were in wp-admin that we’d be giving them just enough rope to hang themselves. 🙁


Now, none of this is finalized, so if you disagree, please voice your concerns in the comment section below. I’m hoping that we’ll get enough discussion that we’ll be able to confidently make a final decision on what path we’re taking at next week’s meeting — which will be on Thursday at 5pm Eastern / 22:00 UTC in #core-passwords

#feature-plugins, #two-factor, #updates

Two-Factor Auth Update

It’s been a couple weeks since our last update, but we’ve had some solid headway in the last couple days!

Current status of default providers:

  • Email: In and works.
  • FIDO U2F: In and works, but only for PHP 5.3+ (library dependency, non-trivial to revise for 5.2)
  • Backup Codes: In and works.
  • TOTP (Google Authenticator): Pull request open (several, actually), I expect to see it merged in the next couple days.

For the providers that are in and works, there may be minor issues either via code architecture or enhancements like better ui / ajax or whatnot — it’s just easier to solve those via small pull requests to master, versus endlessly debating in a pull request without actually merging it in. 🙂

Application Passwords are also included in the plugin currently, however I’m not sure whether they should be a part of it or not in the end — they are included to allow users who use two-factor authentication to still use xml-rpc functionality, which can’t support two-factor authentication.

For TOTP, we will need to be able to generate QR codes, and the de facto standard library I’ve found for generating them locally seems to be — which has both PHP and JS implementations and is MIT licensed. I’m currently leaning towards the JS implementation, but I’d be fine with PHP instead. Either way works just as easily.

Please, test and report both errors and suggestions either on GitHub or on our Slack channel — #core-passwords.

As always, our next chat will be on Thursday at 5pm Eastern, in #core-passwords.

#feature-plugins, #two-factor, #updates

Two-Factor Authentication Weekly Update!

We met on Thursday and discussed the providers in progress — TOTP, FIDO U2F, and Backup Codes.

In Attendance:

Last week we merged in the functionality to support fallback methods and have a great pull from @valendesigns to better automate the workflows and systems, as well as adding in some unit tests —

We also need some Design help with some flows and options screens, so if any designers are interested in pitching in, let me know! 🙂

Next meeting will be Thursday, August 6th at 21:00 UTC

#feature-plugins, #two-factor, #updates

Two Factor Meeting Recap

Next week’s meeting will be on July 30th, 2015 at 17:00 ET — two hours later than this week’s meeting, to try and not drop it at 4am for some of our people.


Folks in attendance:


Reviewed rough plans with authentication provider classes and who is working on each. @julien731 has a wealth of experience with TOTP and @extendwings with U2F, and will likely be helping with each respectively.

I’m expecting to have the fallback methods branch finished and merged in by EOD today or tomorrow. At that point, it will likely need some design love, as it will need to account for three different things — what the user’s primary provider is, what providers the user has enabled, and configuring providers. For the moment we’re going for functionality over design, so it’ll just be checkboxes for available, radio button for primary, and letting each provider handle configuration.

Added @valendesigns and @stevenkword as committers on the repo.

#feature-plugins, #two-factor, #updates

Two-Factor Authentication — First Weekly Meeting!

Our very first first weekly meeting will be July 23rd, 2015 at 15:00 EDT in the #core-passwords channel on Slack.

We’ll be addressing some varied issues such as:

  • meeting times (is this a good time for everyone? Is earlier/later better?)
  • Two-Factor Providers, who is working on each.
  • Open Issues.
  • Code Reviews.
  • etc.

As I’m going on Paternity leave in mid-September for a bit, I’m also hoping that over the next few weeks we can collectively find someone else willing to take up the mantle and push Two-Factor forward in my absence.

For anyone else just new to this, who is wondering what the deuce I’m talking about, Two-Factor is a feature proposal for core to introduce two-factor support in the interest of greater security and paving the cowpaths with a standard api for plugins to extend to provide their own two-factor providers. Active development is currently on GitHub here ==> — and I’m happy to add any regular core contributors as contributors on the repo — just ask during our meeting or in the comments below!

#chats, #feature-plugins, #two-factor, #updates