packagist
packagist copied to clipboard
composer
Security -- how are malicious or insecure Packagist packages reported
Not so much an issue with the packagist code, so perhaps not the ideal place for voicing this concern, but the main issue I have with Packagist is that it is so open which is both good and bad.
Say I'd discover that some person is sneaking in backdoors or purposely or not introducing exploits, how do I make sure the package is taken offline as soon as possible? If there is an existing procedure it should be much, much more apparant. Probably it should have a prominent place on the Packagist home page.
It's not stopping me from using Composer and Packagist right now but if this bites me in the ass despite the uncomfortable feeling I am communicating right now I'll probably never forgive myself :p I am seriously considering abandoning the use of Packagist packages because of this concern.
The problem is taking it offline from packagist prevents new installs, but it doesn't fix all the composer.lock files all over the place using a package. There is the SensioLabs Security Checker that tries to address this issue. At the packagist level though right now there isn't much in place besides "hit us up on the contact address and we'll respond ASAP". Granted we could probably improve on that, the question is how? For the accidental security fuckups in libraries, I think the sensio tool is a pretty decent approach, people release advisories and you get "notified" that you should upgrade. On the other hand if someone wants to publish malicious code it's gonna be hard to prevent that I think. The best way to defend oneself against that is to use popular package which hopefully have more peer-review and people watching new commits that will pick stuff up. That's just the nature of open-source. If you do have other ideas though please do share.
I think it would be valuable if there was a key in the package schema at the revision/version level of the package metadata that could indicate a particular version of a package has a security issue. It would be up to the package maintainers to set this flag, and composer could potentially run a 'security check' to verify/validate whats in a composer.lock, and respond with 'ok', 'insecure', and 'unknown'. perhaps even a url if insecure that links to whatever cve or details exist.
This would be a large improvement and provide a great way for projects to know if they need to move to a newer version of a dependency. The Friends of PHP repo for vulnerabilities is a great community effort to report things like this, but since its not integrated directly with packagist/composer, so consumers may not know about or use it.
I'd thing this would require a change to the composer.json spec though, https://github.com/composer/composer/issues/591. For instance Drupal is starting to provide a package repo that is not part of packagist and would need to rely on this same method.
Looking at https://packagist.org/feeds/package.guzzlehttp/guzzle.rss, there is nothing to indicate that the recent 6.2.1 release should be considered an important security update.
I think the issue is wider than just security. It's the "yanked" issue on one hand - pulling a version of a package because of a serious security, stability or regression issue - and central update notifications on the other hand. If you include Symfony today, your composer.json will reference ^3.13 and that's it for the unforeseeable future. Unless you the maintainer hit composer update, your package will be stuck in 3.x forever. Unless you monitor the Symfony blog, noone will ever tell you or your users there's a 4.x major one day. Or a 5.x. From that perspective it doesn't matter if 3.1.4 is released tomorrow fixing a critical issue only in 3.1.3 or 4.2.5 in 2 years fixing an issue that's already in today - in both cases you'll never know, and Composer/Packagist can never tell you unless you hit update.
I don't think Composer and Packagist can do much about the second issue. It's the maintainer's responsibility to keep his package up to date, and to read up on his dependencies. VersionEye is one of the tools filling that gap actually.
As for the first issue, yes I do think it makes sense for some way in the Packagist protocol (so also for Satis) to actively yank a specific version for a given reason. It could cause big red flashing warnings when trying to install/update a yanked version. It's not going to solve the real issue though until the package users actually check for their dependency being yanked.
The real issue is discipline on the consumer's end, as it often is.
What would be really cool would be an integration on Composer's end with a VersionEye-like tool, where your lockfile gets automatically uploaded to your account, and it will notify you from there if your recursive dependencies are outdated, yanked, abandoned or replaced. It could even proactively warn you of other dependencies like PHP itself or extensions hitting EOL dates. I myself would likely pay for such a service, integrated in Packagist or not :)
I don't think Composer and Packagist can do much about the second issue. It's the maintainer's responsibility to keep his package up to date, and to read up on his dependencies. VersionEye is one of the tools filling that gap actually.
I agree. The issue (this issue) though is currently VersionEye can't even tell you if a package has a security update. It attempts with https://github.com/FriendsOfPHP/security-advisories but that repo is sort of opt-in and there isn't any real understanding of coverage.