On the KnpLabs blog there's a new post from Ryan Weaver sharing some cool things you can do with Composer you might not have known about when managing your application's dependencies.

For those of you that are comfortable with Composer, I wanted to talk about a few lesser-known, but really fantastic features. These are inspired by real questions I've heard while running around the country doing my one-man composer-and-dancing show (i.e. conference talks).

He shares four of them with a fifth that's more of an "upcoming feature" than a current one:

• Autoloading & Performance: "I thought class maps were the fastest?"
• Running Post-Deploy Scripts
• "What if I need to fork a library?"
• Can I host private packages on Packagist?
• What about signing the authenticity of Packages?

That last one about package signing is still on the known issues list and is under discussion, but no doubt that future versions of the tool will support it.

In this new post to his site Joshua Thijssen talks about the "russian roulette" that's involved in the single-line install of Composer (as was mentioned here) and how it sets a bad precedent for developers to follow.

Michael Maclean has written a very good article on what is wrong with this. His point essentially boils down to this: you have no way of knowing what you are actually installing on your system and if it's the software as intended by the original developers. Especially developers tend to do this more and more often, and in even more dangerous ways. Now, this is bad by itself of course, but this is not a simple app you run on occasion (if that was an excuse to begin with). Composer is the software that pretty much controls ALL your application dependencies. What would happen if this software would fetch its packages from packagists.org, or packagits.org?

He brings up a scenario where, say Packagist.org gets hacked and links to repositories are altered. If you're blindly installing via Composer, you'd have no idea that the code you're working with is potentially tainted. He notes that it boils down to trusting the source and how some simple hashing could help some of the problems. He also talks briefly about security issues that have been discussed (like "use SSL" or "don't run as root") to help prevent issues.

He suggests the implementation of the hash-based signing of the downloads to ensure that the software you're getting is what you're expecting. He mentions getting rid of auto-updates and the creation of signed packages/tarballs to help increase the security checking abilities of the installer.