Can anyone from SS HQ tell me if it's a reasonable assumption to make that no package-name given in a security advisory, infers "silverstripe/framework"? (Ref: https://www.silverstripe.org/download/security-releases/rss) (edited)
Looking at FriendsOfPHP/security-advisories, the SS advisories are well out of date. I'm wondering why it doesn't look at the official RSS feed instead: https://www.silverstripe.org/download/security-releases/rss
At the moment, this package bakes-in YML files comprising official security advisories for SilverStripe (and a bunch of other applications). This seems a pretty high-maintenance procedure for a kind of data that is by its very nature, constantly evolving.
Is there a reason why the package doesn't make use of web-APIs and RSS fedds where available for each of the supported packages? The SilverStripe one is here: https://www.silverstripe.org/download/security-releases/rss|https://www.silverstripe.org/download/security-releases/rss
I believe this one does part of the job? https://github.com/bringyourownideas/silverstripe-maintenance (edited)
Helps with the day by day work to run a SilverStripe application or website.
a bunch of out of date YML files! https://github.com/FriendsOfPHP/security-advisories/tree/master/silverstripe/ (cms|framework|forum|useerforms)
I was meaning an RSS feed or similar. But thinking about it again - SS' RSS feed is exactly that. It carries information about non framework/cms packages. May be a moot point?
Incidentally; The maintainer of FriendsOfPHP/security-advisories gave me an interesting response in https://github.com/FriendsOfPHP/security-advisories/issues/340 (edited)
PHP security vulnerabilities monitoring
What do people use for automated security advisory checking, for composer deps?
could be related? https://github.com/silverstripe/silverstripe-framework/issues/8548 (edited)
https://github.com/Firesphere|@Firesphere raised a good idea in a satellite module about including
roave/security-advisoriesin composer.json to help assert people do not install known security vulnerabilities.
This module works by declaring composer conflicts with packages that are known to have security vulnerabilities - I believe this is auto-generated from the vulnerability database that SensioLabs maintains: https://security.sensiolabs.org/|https://security.sensiolabs.org/ (or apparently https://security.symfony.com/|https://security.symfony.com/ now)
• Does this have value for us? • Should we include this module or just suggest it? • Should we include it in framework or a module like silverstripe/installer (or all modules)