Page MenuHomePhabricator

Security Readiness Review For Wikimedia/oauth2-server
Closed, ResolvedPublic

Description

Project Information

Description of the tool/project:
The fork includes changes from a pull request which adds support for private claims in a JSON Web Token. We're working with upstream to get the pull request accepted in the upstream library, and the need for the fork will eventually disappear.

Description of how the tool will be used at WMF:
The fork will be temporarily used by the OAuth and OAuthRateLimiter extensions until a new version of oauth2-server is released with the new changes.

Working test environment
Test environment instructions from T257930 can be used to test these changes

Post-deployment
Platform Engineering will own the fork until a new version is released

Event Timeline

sbassett triaged this task as Medium priority.Aug 20 2020, 4:10 PM
sbassett moved this task from Incoming to Back Orders on the secscrum board.

The fork includes changes from a pull request which adds support for private claims in a JSON Web Token. We're working with upstream to get the pull request accepted in the upstream library, and the need for the fork will eventually disappear.

For clarity/documentation purposes...

Is https://github.com/wikimedia/oauth2-server/commits/v9.0.0-alpha made from https://github.com/wikimedia/oauth2-server/tree/8.1.1 plus https://github.com/thephpleague/oauth2-server/pull/1122 ?

Or more specifically, it's not https://github.com/thephpleague/oauth2-server/tree/9.0.0-WIP plus https://github.com/thephpleague/oauth2-server/pull/1122 is it?

Reedy closed this task as Resolved.EditedAug 27 2020, 9:23 PM

So this is good to go.

As per the task description, and other discussions, the use of the fork must be reverted when the PR lands upstream and an appropriate release is made. Doesn't have to be done immediately, but within a reasonable timescale of it happening. Might want to create a task somewhere in this task tree under T235270: Wikimedia API Gateway for doing that, tagging it Upstream and stalling as appropriate as a reminder that the work has to be done later.

And as appropriate, while we're still using the fork, please keep an eye on the upstream commits (though I admit it's not the busiest of repos, so should be easier) and releases for anything that might be appropriate, ie security fixes or other relevant bug fixes to our deployment, those obviously would have to be manually put into the branch on our fork and vendor updated as appropriate.

The use of a fork obviously brings in a small amount risk (divergence of code, lack of composer telling us of updates etc), but nothing that blocks this going out.