| Legoktm | |
| Nov 11 2017, 4:14 AM |
| F26612728: Screenshot_2018-10-15 mediawiki-vendor-security #5 [Jenkins].png | |
| Oct 16 2018, 4:54 AM |
We currently run a check once a day against all of the production dependencies that are deployed in mediawiki/vendor. I propose that in addition to that, we start checking on every commit whether there are any security issues for both production dependencies and development dependencies. At least two of our dev dependencies (codesniffer and phpunit) have had security issues in the past.
This task should be made public once T180231 is disclosed.
https://github.com/FriendsOfPHP/security-advisories/issues/237 asks for what usage limits are.
Also we are currently only checking against master. We need to check all supported release branches.
Mostly ease of implementation when I was thinking about it. It would be pretty easy to add in the check after we've run "composer install" and have a composer.lock file to check against. Also I was thinking of how parsoid runs https://github.com/nodesecurity/nsp on every commit.
But at the same time that requires people to actively be commiting for the checks to be run, which is unlikely for release branches.
The problem with unsafe dependencies is usually not someone introducing a dependency on something broken - it's holes being found in existing dependencies. That would just result in unrelated commits breaking.
Checking every commit of mediawiki/vendor.git would be reasonable, but checking every commit of mediawiki/core.git (and every extension and skin?) seems like a lot of wasted work for our CI infrastructure and for the upstream service. As noted it it probably not very helpful for increasing coverage of branches other than master as well.
The main benefit of per-commit is that it forces people to deal with the issue immediately since it stops people from committing - no potential issue with alerts going to the wrong people.
Other than that, I tend to agree that once a day is probably fine.
There was a comment on the github about https://packagist.org/packages/roave/security-advisories which might be an easy option since we run composer on every commit.
https://github.com/Roave/SecurityAdvisories is another potential variant of the FriendsOfPHP stuff....
Change 460606 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/vendor@master] Add roave/security-advisories
Change 467561 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[integration/config@master] Refactor -composer-security into a matrix based job
Change 467561 merged by jenkins-bot:
[integration/config@master] Refactor -composer-security into a matrix based job
Outside of MediaWiki extensions/skins (which I have a different plan for), what other repositories should we be checking for PHP vulnerabilities on a regular basis?
Change 467765 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[integration/config@master] Add more repositories for PHP dependency security checking
Change 467765 merged by jenkins-bot:
[integration/config@master] Add more repositories for PHP dependency security checking
Change #1109036 had a related patch set uploaded (by Hashar; author: Hashar):
[integration/config@master] Remove php-security scanning
Change #1109036 merged by jenkins-bot:
[integration/config@master] Remove php-security scanning
After discussion on T309655 I have deleted the Jenkins jobs. The notifications were not watched by anyone and thus not acted on.
![Screenshot_2018-10-15 mediawiki-vendor-security #5 [Jenkins].png (1,488×646 px, 68 KB)](https://phab.wmfusercontent.org/file/data/dori3jn3uqftehbhoy2i/PHID-FILE-e4jvrmqydgdjsrduanhq/Screenshot_2018-10-15_mediawiki-vendor-security_5_%5BJenkins%5D.png)