- Other Assignee
|Open||None||T261469 Launch demonstration system|
|Open||Krinkle||T261341 Performance review of Wikifunctions|
|In Progress||Jdforrester-WMF||T284162 Create a Beta Cluster version of Wikifunctions.org|
|Resolved||Jdforrester-WMF||T290274 Add any necessary dependencies for WikiLambda to production vendor once they've passed Security review|
Feels like I may have discussed this with James F in IRC DM before... But why are we adding https://packagist.org/packages/opis/json-schema "Json Schema Validator for PHP" when we already have https://packagist.org/packages/justinrainbow/json-schema "A library to validate a json schema." reviewed/deployed (it is a require-dev, but is in mediawiki-vendor already)...?
Or to put it another way, can we (ie Abstract Wikipedia team) please document why we need yet another JSON Schema Validator library in PHP put into MediaWiki-Vendor?
If there is a good reason, that's fine... Or similarly, if we plan to replace justinrainbow/json-schema with opis/json-schema longer term (sometime in the mysterious future)...
It's require-dev in CirrusSearch and require in Maps (Kartographer) - https://codesearch.wmcloud.org/search/?q=justinrainbow%2Fjson-schema&i=nope&files=&excludeFiles=&repos=
Security Review Summary - T290274 - 2021-10-15
Last commit reviewed: n/a
We're already deploying numerous symfony libraries, and as such, adding others that are maintained by the core symfony team is not really an issue. Keeping the package up to date can happen with the other usual updates to packages in MediaWiki vendor.
Symfony packages are widely used, whilst also being actively maintained with responsive developers. They also have a security vulnerability reporting policy at https://symfony.com/doc/current/contributing/code/security.html.
symfony/yaml is also currently deployed in the fundraising/REL1_35 branch.
There is one historic CVE related to symfony/yaml - https://www.cvedetails.com/cve/CVE-2013-1348/
For symonfy/yaml there is therefore an overall risk rating of: low.
It's because justinrainbow/json-schema is bad at error reporting, and so rather than using that and writing half the library for them, we're using opis/json-schema as it's a library that actually works for our needs here. Other repos migrating to this library instead would make sense, and I'd be happy to help them longer-term.
Security Review Summary - T290274 - 2021-11-05
Last commit reviewed: n/a
There was no security policy on the opis/json-schema repo. I filed https://github.com/opis/json-schema/issues/95 last week, and within a couple of hours one had been added to the repo. Can now be viewed at https://github.com/opis/json-schema/blob/master/SECURITY.md - Nice to see responsive developers.
Having numerous libraries to do the same thing isn't the best, especially when we control what we use. But as per T290274#7432359 and the subsequently filed T293710, we should minimise this in future. Of course, this doesn't then stop a 3rd party library then depending on`justinrainbow/json-schema`... Oh well.
No obvious CVE's or historical security issues.
It's an actively well used library (most users still on 1.x as we are using until we bump our PHP version in WMF prod).
For opis/json-schema there is therefore also an overall risk rating of: low.