News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Pádraic Brady:
PHP Package Signing My Current Thoughts
March 10, 2014 @ 11:57:49

Pádraic Brady has a new post sharing some of his ideas around PHP package signing and a few possible ways to approach (and possibly solve) the problem.

We figured out how to write good code. We figured out how to write good code in a reusable way...for the most part. We figured out how to distribute and mix all that good reusable code in a sensible fashion. Can we now figure out how to do it all securely? [...] The problem with package signing from my perspective is tied up in a phrase most of you would know: The needs of the many outweigh the needs of the few. Thank you, Spock.

He compares two different alternatives, Public-key infrastructure (PKI) vs (Pretty Good Privacy) GPG, and how the idea of trust fits into the picture. He also points out an unfortunate fact when it comes to the initial adoption of package signing methods - people are lazy (and cheap). They want to get things done and not have extra steps. Signing their packages would be one of these steps. He suggests an alternative, though, using double signatures to verify the integrity and validity of its contents. He also talks about the role that metadata plays in the overall package ecosystem and how signing it as well could be part of the solution.

0 comments voice your opinion now!
package signature signing metadata packagist composer

Link: http://blog.astrumfutura.com/2014/03/php-package-signing-my-current-thoughts

Pádraic Brady:
Thoughts on Composer's Future Security
March 06, 2014 @ 11:09:06

Pádraic Brady has a new "let's watch Paddy think aloud in a completely unstructured manner blog post" about the future of security when it comes to the popular PHP package manager Composer. It's recently come under criticism around its lack of package signing and TLS/SSL support.

The Composer issue, as initially reported by Kevin McArthur, was fairly simple. Since no download connection by Composer was properly secured using SSL/TLS then an attacker could, with the assistance of a Man-In-The-Middle (MITM) attack, substitute the package you wanted to download with a modified version that communicated with the attacker's server. They could, for example, plant a line of code which sends the contents of $_POST to the attacker's server.

He's been working on some updates to the project, one of with is TLS/SSL support as defined in this pull request currently pending. It enables peer verification by default, follows PHP 5.6 TLS recommendations and uses local system certificates in the connection. He talks some about other additional TLS/SSL measures that could be added in the future and how, despite it being safer than nothing, TLS/SSL is not the "cure all" for the problem.

He then moves on to package signing and suggests one method for implementation - signing the "composer.phar" executable and signing "everything else" (packages to be downloaded) to verify their validity.

The flaw in Composer's installer isn't that it's unsigned, it's that it doesn't afford the opportunity for the downloader to read it before it gets piped to PHP. It's a documentation issue. You can go down the route of using a CA, of course, but that's further down the rabbit hole than may be necessary. Signing the composer.phar file is another matter.
0 comments voice your opinion now!
composer package signing tls ssl support security

Link: http://blog.astrumfutura.com/2014/03/thoughts-on-composers-future-security

KnpLabs Blog:
Composer Level2 5 more things like Class Maps, Forking, & Scripts
November 08, 2012 @ 09:17:14

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.

0 comments voice your opinion now!
composer classmap forking scripts package signing


Joshua Thijssen:
Installing composer russian roulette.
October 15, 2012 @ 12:19:19

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.

0 comments voice your opinion now!
composer install package signing hashing security



Community Events





Don't see your event here?
Let us know!


podcast interview tips update library laravel install framework language deployment list zendserver release symfony opinion series package community introduction api

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework