Page MenuHomePhabricator

Bundle SecureLinkFixer extension with MediaWiki
Closed, ResolvedPublic

Description

I'm proposing we bundle the SecureLinkFixer extension with MediaWiki (hopefully starting with 1.35). SLF rewrites URLs to use HTTPS if they're on the HSTS preload list. You can think of it as the "HTTPS Everywhere for MediaWiki". The main people who benefit from this extension are wikis that don't have bots to rewrite links to HTTPS and clients that don't support HSTS. I believe this provides a small security benefit to all wikis at a minimal cost.

The extension comes with everything already included, requires no configuration or schema changes. It's also trivial to uninstall, leaving no traces it was there.

One consideration is that a copy of the HSTS preload list is shipped inside the extension. For Wikimedia deployment purposes, we update it in the master branch weekly. It would be straightforward to have the bot update it in supported MW branches on a monthly or other schedule. In any case, shipping an outdated version of the list is expected, see https://hstspreload.org/#removal.

I believe SLF meets everything on the checklist, but I'll let someone else fill it out.

  • Passed security review or already Wikimedia deployed
  • Voting CI structure tests
  • Runs MediaWiki-CodeSniffer
  • Runs phan
  • Supports MySQL, SQLite, and Postgres (if there are schema changes)
  • GPL v2 or later compatible license
  • Extension's default configuration provides optimal experience
  • Tested with web installer

Event Timeline

Legoktm created this task.Jul 6 2020, 7:02 AM
DannyS712 updated the task description. (Show Details)Jul 6 2020, 7:07 AM
DannyS712 added a subscriber: DannyS712.

What defines a "structure test"? Also, is GPL v3 or later compatible with 2 or later, or is it the other way around?

The checklist has been ad-hoc for a while now, so I took this opportunity to explicitly document it: https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated/Checklist

What defines a "structure test"?

tests/phpunit/structure in MediaWiki core. It gets run by CI in the normal PHPUnit job.

Also, is GPL v3 or later compatible with 2 or later, or is it the other way around?

Yes, it works both ways actually. v3 or later is compatible with v2 or later because for the v2 case, you're exercising your option to use a later version, aka v3. And v2 or later is compatible with v3 or later, because again, you can pick v3. The problem is when authors chose not to include the "or later" part. Plain GPL v2 (SPDX: GPL-2.0-only) is not compatible with GPLv3 (SPDX: GPL-3.0-only). Thankfully MediaWiki is "or later" :)

Reedy added a comment.Jul 6 2020, 2:10 PM

It would be straightforward to have the bot update it in supported MW branches on a monthly or other schedule. In any case, shipping an outdated version of the list is expected, see https://hstspreload.org/#removal.

Just noting this will give quite a size increase to the quarterly patches for the tarballs that include the extensions and skins

Reedy updated the task description. (Show Details)Jul 6 2020, 2:11 PM

I'm OK with this if you can commit to doing the config list back-ports into release branches from time to time.

It would be straightforward to have the bot update it in supported MW branches on a monthly or other schedule. In any case, shipping an outdated version of the list is expected, see https://hstspreload.org/#removal.

Just noting this will give quite a size increase to the quarterly patches for the tarballs that include the extensions and skins

True. I should clarify that it's totally optional, there's no problem or downside to shipping an outdated list.

I'm OK with this if you can commit to doing the config list back-ports into release branches from time to time.

I'd rather not. I think we should either automate updating the list in release branches (monthly, every 2 months, whatever) or just not bother and ship an outdated list. I'd prefer to regularly ship updates to the list because it's a nice extra thing, but not necessary if we're concerned about the size of updates or other stuff.

I can commit to implementing the automation part, if that's what we go with.

I'm also OK with shipping a one-and-done version that gets outdated.

Fine with me :)

Aklapper moved this task from Blocker to Bundling on the MW-1.35-release board.Jul 9 2020, 12:33 PM

Change 612170 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/tools/release@master] Add SecureLinkFixer to the MW tarball

https://gerrit.wikimedia.org/r/612170

Jdforrester-WMF closed this task as Resolved.Jul 13 2020, 10:02 AM
Jdforrester-WMF claimed this task.

We'll need to add some blurb to the MW release notes, but that's fine and doesn't need this to stay open.

Change 612170 merged by jenkins-bot:
[mediawiki/tools/release@master] Add SecureLinkFixer to the MW tarball

https://gerrit.wikimedia.org/r/612170