Composer.lock in Bundle
acidjames opened this issue · 7 comments
Hi,
apparently, it is not always recommended to commit composer.lock to bundles as stated here :
https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file
I'm posting this issue as this bundle has some security issues with the composer.lock, it's not an important security issue but still has to do with how the composer.lock is commited to this repo.
From Sensio Security Advisory:
Vulnerability Report
Caution
The checker detected 2 package(s) that have known* vulnerabilities in your project. We recommend you to check the related security advisories and upgrade these dependencies.
doctrine/orm (2.4.x-dev)
Security Misconfiguration Vulnerability in various Doctrine projects — CVE-2015-5723
symfony/symfony (2.5.x-dev)
CVE-2016-1902: SecureRandom's fallback not secure when OpenSSL fails — CVE-2016-1902
Unsafe methods in the Request class — CVE-2015-2309
CVE-2015-4050: ESI unauthorized access — CVE-2015-4050
Code injection in the way Symfony implements translation caching in FrameworkBundle — CVE-2014-4931
CSRF vulnerability in the Web Profiler — CVE-2014-6072
CVE-2016-4423: Large username storage in session — CVE-2016-4423
Esi Code Injection — CVE-2015-2308
CVE-2015-8125: Potential Remote Timing Attack Vulnerability in Security Remember-Me Service — CVE-2015-8125
Security issue when parsing the Authorization header — CVE-2014-6061
Denial of service with a malicious HTTP Host header — CVE-2014-5244
CVE-2015-8124: Session Fixation in the "Remember Me" Login Feature — CVE-2015-8124
Direct access of ESI URLs behind a trusted proxy — CVE-2014-5245
I will post a PR if you guys are okay with this
I'm sorry but I don't agree. You should always commit composer.lock if you want to ensure what version are you using of your dependencies.
If you want to fix some vulnerabilities you should update the composer.lock with the version of dependencies that fix them.
Hi @jordillonch,
from a projet perspective this is correct but not from a library perspective.
When you work on a project, you should have only one composer.lock. Imagine, your bundle uses doctrine-annotations and another bundle too but with different commit versions in composer.lock, this doesn't make sense.
When you use "composer require jordillonch/crudgeneratorbundle", the composer.lock is not read.
As you can see in FosUserBundle .gitignore, https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/.gitignore
This is just being picky but as i am automating security detection in composer projets i noticed your bundle has this security issue, quoted in my first post :)
Regards,
James
Ok. Make sense. Thanks!
Please fix the test on your PR and I will accept them.
Weird, it seems travis doesn't like deleting a single file in a commit. I don't get it :(
Okay, so apparently, the build is failing because the travis virtual machine doesn't have enough ram to use composer. Standard admin problem ... I guess you can accept the PR without breaking anything.
PHP Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 134217728 bytes) in phar:///home/travis/build/jordillonch/CrudGeneratorBundle/composer.phar/src/Composer/DependencyResolver/RuleSetGenerator.php on line 126
@gonzakpo i'm talking about the travis ci virtual machine, i'm not an admin there :)
https://travis-ci.org/