Storing vulnerability information in composer.json
410 views
Skip to first unread message
Dracony
Nov 12, 2014, 2:09:37 PM11/12/14
to php...@googlegroups.com
I have discussed this in another thread, and since I feel I'm hijaking it I decided to make a separate one.
Basically it would specify an affected version and a link to a webpage explaining the vulnerability. this is the simplest approach, but obviously we could store a lot more data there (like date etc).
there is a PHP Security Advisories Database ( https://github.com/FriendsOfPHP/security-advisories ) one of the features of which is to check your composer files for vulnerabilities. It works great but here are the problems with it:
- It requires an external service to store vulnerability data
- Package developers may not know about the service and not submit the data there
- Reporting vulnerabilities there is an additional step for a developer
- Users still can install a vulnerable version with composer and are not warned about it
This gives us the opportunity to:
- Warn users automatically that they are installing a vulnerable version of a package when they run composer install
- Users can easily check composer.json to see vulnerability information
- Doesn't rely on an external service
- information can be easily read from the json format
- It's easier for developers to update that information in their composer.json than submit it somewhere
Basically it would specify an affected version and a link to a webpage explaining the vulnerability. this is the simplest approach, but obviously we could store a lot more data there (like date etc).
What would be your thoughts?
ɹǝɹǝɥɔs uoɹɐɐ
Nov 12, 2014, 2:12:18 PM11/12/14
to php...@googlegroups.com
Jordi is in the mailing list here, but i'd post this over in composer's github issues
A. Scherer
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0d6db392-3f1c-4913-9acb-92d0f3652e7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Pádraic Brady
Nov 12, 2014, 2:39:15 PM11/12/14
to php...@googlegroups.com
We're also teetering into specifics, and should probably wait for
Lukas to setup a specific mailing list. I know, we need to wait for
about a week for his vacation to end, but we don't need to hit
everyone's inbox over this right now. For that reason, I'll defer
further replies until the new ML is available.
Paddy
> https://groups.google.com/d/msgid/php-fig/CAMGK6yiJW_c4EqfNK%3DwYGnnkvQUcjyz3JofD_%3DOVhTooQdJHhg%40mail.gmail.com.
--
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
Lukas to setup a specific mailing list. I know, we need to wait for
about a week for his vacation to end, but we don't need to hit
everyone's inbox over this right now. For that reason, I'll defer
further replies until the new ML is available.
Paddy
--
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
Jordi Boggiano
Nov 12, 2014, 2:42:27 PM11/12/14
to php...@googlegroups.com
I rather disagree for the following reasons:
- it is weird to have to read data from a latter version (the
composer.json in the vulnerable tags won't contain vulnerability data)
to figure out if an earlier version is vulnerable
- vulnerable packages that are already installed would not trigger a
warning as they don't get reinstalled. Unless we start checking for the
latest version of vulnerabilities whenever composer does something, but
that breaks some assumptions in the workflow IMO.
- external service or packagist, some people will ignore it, some people
will get educated. It's always the same. That's why the FIG
standardizing on a security document and way of handling things is a
good thing. It makes education easier.
- maybe the current advisories db tool could have a nice command to help
creating/sending a pull request or something when you have a new
advisory to send as a package developer.
I would much prefer if this is kept as a third party tool, then
eventually we could integrate it in the composer workflow if we find a
way that makes sense, or users can do it themselves using
post-install-cmd hooks for example.
Maybe the info could remain in the original repo though as a SECURITY
file or whatever that lists everything, that could be crawled by an
external service just like packagist does it really. Down the line if
this gets used widely we can always think of ways to integrate things
tighter to make it easier to use / more universal.
Cheers
On 12/11/2014 19:09, Dracony wrote:
> I have discussed this in another thread, and since I feel I'm hijaking
> it I decided to make a separate one.
>
> there is a PHP Security Advisories Database
> ( https://github.com/FriendsOfPHP/security-advisories ) one of the
> features of which is to check your composer files for vulnerabilities.
> It works great but here are the problems with it:
>
> * It requires an external service to store vulnerability data
> * Package developers may not know about the service and not submit the
> data there
> * Reporting vulnerabilities there is an additional step for a developer
> * Users still can install a vulnerable version with composer and are
> version of a package when they run composer install*
> * *Users can easily check composer.json to see vulnerability information*
> * Doesn't rely on an external service
> * information can be easily read from the json format
> * It's easier for developers to update that information in their
Jordi Boggiano
@seldaek - http://nelm.io/jordi
- it is weird to have to read data from a latter version (the
composer.json in the vulnerable tags won't contain vulnerability data)
to figure out if an earlier version is vulnerable
- vulnerable packages that are already installed would not trigger a
warning as they don't get reinstalled. Unless we start checking for the
latest version of vulnerabilities whenever composer does something, but
that breaks some assumptions in the workflow IMO.
- external service or packagist, some people will ignore it, some people
will get educated. It's always the same. That's why the FIG
standardizing on a security document and way of handling things is a
good thing. It makes education easier.
- maybe the current advisories db tool could have a nice command to help
creating/sending a pull request or something when you have a new
advisory to send as a package developer.
I would much prefer if this is kept as a third party tool, then
eventually we could integrate it in the composer workflow if we find a
way that makes sense, or users can do it themselves using
post-install-cmd hooks for example.
Maybe the info could remain in the original repo though as a SECURITY
file or whatever that lists everything, that could be crawled by an
external service just like packagist does it really. Down the line if
this gets used widely we can always think of ways to integrate things
tighter to make it easier to use / more universal.
Cheers
On 12/11/2014 19:09, Dracony wrote:
> I have discussed this in another thread, and since I feel I'm hijaking
> it I decided to make a separate one.
>
> there is a PHP Security Advisories Database
> ( https://github.com/FriendsOfPHP/security-advisories ) one of the
> features of which is to check your composer files for vulnerabilities.
> It works great but here are the problems with it:
>
> * Package developers may not know about the service and not submit the
> data there
> * Reporting vulnerabilities there is an additional step for a developer
> * Users still can install a vulnerable version with composer and are
> not warned about it
>
> My idea is to instead store vulnerability information in the
> composer.json file. We already store a lot of metadata in it anyway
> (license, developers, description, etc).
> This gives us the opportunity to:
>
> * *Warn users automatically that they are installing a vulnerable
>
> My idea is to instead store vulnerability information in the
> composer.json file. We already store a lot of metadata in it anyway
> (license, developers, description, etc).
> This gives us the opportunity to:
>
> version of a package when they run composer install*
> * *Users can easily check composer.json to see vulnerability information*
> * Doesn't rely on an external service
> * information can be easily read from the json format
> * It's easier for developers to update that information in their
> composer.json than submit it somewhere
>
> For example the format could be:
> |
> vulnerabilities:{
> '<=1.10.12':['http://myawesomepackage.com/new-bug-discover.html']
> }
> |
>
> Basically it would specify an affected version and a link to a webpage
> explaining the vulnerability. this is the simplest approach, but
> obviously we could store a lot more data there (like date etc).
>
> What would be your thoughts?
>
>
> For example the format could be:
> |
> vulnerabilities:{
> '<=1.10.12':['http://myawesomepackage.com/new-bug-discover.html']
> }
> |
>
> Basically it would specify an affected version and a link to a webpage
> explaining the vulnerability. this is the simplest approach, but
> obviously we could store a lot more data there (like date etc).
>
> What would be your thoughts?
>
> --
> You received this message because you are subscribed to the Google
> Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to php-fig+u...@googlegroups.com
> <mailto:php-fig+u...@googlegroups.com>.
> You received this message because you are subscribed to the Google
> Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to php-fig+u...@googlegroups.com
> To post to this group, send email to php...@googlegroups.com
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/0d6db392-3f1c-4913-9acb-92d0f3652e7f%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/0d6db392-3f1c-4913-9acb-92d0f3652e7f%40googlegroups.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/d/msgid/php-fig/0d6db392-3f1c-4913-9acb-92d0f3652e7f%40googlegroups.com
Jordi Boggiano
@seldaek - http://nelm.io/jordi
Marco Pivetta
Nov 12, 2014, 2:45:44 PM11/12/14
to php...@googlegroups.com
I'm actually working on a meta-package that *should* allow this sort of functionality (security checks on install). Not yet there though, it will take a couple of weeks to build all what is needed for it to function correctly.
an email to php-fig+unsubscribe@googlegroups.com
<mailto:php-fig+unsubscribe@googlegroups.com>.
To post to this group, send email to php...@googlegroups.com
<mailto:php-fig@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/0d6db392-3f1c-4913-9acb-92d0f3652e7f%40googlegroups.com
<https://groups.google.com/d/msgid/php-fig/0d6db392-3f1c-4913-9acb-92d0f3652e7f%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5463B81C.60004%40seld.be.
Reply all
Reply to author
Forward
0 new messages