Announce WordCamp deployments in Slack

This is a low priority, but it’d be helpful to announce wordcamp.org deployments in Slack, like we do with wordpress.org.

I added support for it to deployed.php in [dotorg13900], and tested the necessary changes to the deploy script in ~/deploy-wordcamp-tmp.sh on my sandbox.

Someone from Systems will need to commit/deploy those to the actual script, though.

Thanks 🙂

#prio3

Could you please forward `http://word.press`/`https://word.press`…

Could you please forward http://word.press/https://word.press to https://wordpress.org? @matt okay’d the change.

See https://meta.trac.wordpress.org/ticket/2726

#prio3

Could you please add a…

Could you please add a redirect from wordpress.org/blog to wordpress.org/news, to not have that be a dead end anymore?

See https://meta.trac.wordpress.org/ticket/1416

Thanks!

#prio3

Can I please have commit…

Can I please have commit access granted to both buddypress.svn.wordpress.org and bbpress.svn.wordpress.org for the WordPress.org username espellcaste?

Renato is a several-year contributor to both projects. He will be working on merging his WP-CLI work into the bb’s, and I expect him to stick around once that work is complete.

We had the Uncle Ben call together last week to set expectations, and he has secure passwords on all of the relevant things.

#buddypress, #bbpress, #commit, #prio3

Update Apache on lists.wordpress.org

A report came in via HackerOne informing us that lists.wordpress.org is running a version of the Apache web server which contains several known vulnerabilities. It should be updated to the latest in either the 2.2.x or 2.4.x branch.

#prio3

CAA for wordpress.org

A report came in via HackerOne recommending that Certificate Authority Authorization be implemented for wordpress.org (and other W domains).

CAA allows a domain owner to restrict which CAs are allowed to issue certificates for the domain. It’s been useless until quite recently: the CAB Forum recently voted to enforce CAA checks for all new certificates starting next month, so it’s definitely a useful measure to implement.

More info: https://scotthelme.co.uk/certificate-authority-authorization/

#prio3

Force SSL for plugins-dev.bbpress.org

It looks like https://plugins-dev.bbpress.org/ uses basic auth and can be used over http. Can we force https?

#prio3

Symlink for new template file on meta.trac

[4621] adds a new template file for meta.trac.wordpress.org which, according to @nacin, needs to be symlinked.

Could someone do that please? Thanks!

#prio3

HTTPS for glotpress.org

http://glotpress.org is currently just a redirect to https://glotpress.blog/ but when accessing glotpress.org via https you’ll get a warning about an invalid certificate because it uses the *.wordpress.org one.

Can we get a proper certificate for glotpress.org? Noticed this because https://hackerone.com/wordpress links to https://glotpress.org.

#prio3

Whitelisted WordCamp Production Data for Dev Environments

Right now WordCamp devs use a small subset of the production database that was manually created, because it wouldn’t be safe to keep copies of the production database in local environments.

That works good enough for most things, but we keep running into situations where reproducing bugs and testing fixes is much harder, and takes much longer, than it would if we had real-world data to work with.

So, I’d like to create a way to safely use a whitelisted copy of production data in local environments. Here’s how I envision it working:

  1. Create a script that runs on the production web server once a day
  2. It would create a copy of the primary database on the production database server
  3. Then run lots of SQL commands against that copy in order to redact anything that hasn’t been whitelisted
  4. Have another script in dev environments that uses sftp to download a copy of the whitelisted database once a day

The whitelist would contain a list of tables, columns, and keys that have been determined to not have any sensitive data. For example:

  • wp_users – The table itself would be whitelisted, but only the ID, user_login, user_nicename, user_registered, user_status, display_name, spam, and deleted fields would be whitelisted. Because user_pass, user_email, and user_activation_key would not be in the whitelist, the script would replace the contents of those columns with [redacted] (or in the case of user_email, redacted@example.org).
  • wp_usermeta – The table itself would be whitelisted, along with the umeta_id, user_id, meta_key, and meta_value columns, but only certain meta_key rows would be whitelisted. For instance, first_name, last_name, description, and wp_capabilities would be whitelisted, but session_tokens and wordcamp-qbo-oauth would not be.

Additionally, the script would have some logic to redact potentially sensitive values within whitelisted columns. For example, any e-mail addresses inside a meta_value value would be replaced with redacted@example.org.

What does Systems think about that? I’d do all the work to build the script, but I want to make sure you don’t have any security/privacy concerns.

#prio3