So this only allows the repository to do the signing right? I'm not sure that brings much value as opposed to just sha1/sha256.. given that (assuming this ssl wreck would be fixed) you'd need to own the server to change the sha1.. then at that point you can as well regenerate signature and do whatever the hell you want actually.

Granted this might help for private repos that aren't served over ssl, but if MITM is a concern you probably want to use ssl if only to avoid leaking your private code.

Anyway what I thought would be nice, would be to allow checking of signed git commits too. I guess this would require source installs though. </random thoughts.>

This approach seems complex, as the repository has to fetch and sign every single package itself. I'd have thought using the same approach that Debian's APT repository uses and generating a cryptographic signature and then using SHA256 checksums to chain that trust down to files.

@cs278 We already do this just without the initial signature, so it wouldn't be too hard to add that I guess.

@Seldaek If you hijack DNS, you can basically change zips and provide a different sha of the file. So there's no security since we currently just validate the sha sum of the file itself. With a private/public key in the mix, this seems harder since you'd have to get the private key to forge the signature.

@till well SSL in theory protects you again DNS hijacking if you have a real cert since CAs shouldn't issue certificates to people that don't own a domain. Or is this bullshit?

@Seldaek No, not bullshit at all. I didn't know composer had facilities to verify/import CAs?

Well it doesn't yet, but that should be fixed either way, since it's the
only way to do SSL reliably in PHP.

@Seldaek http://security.stackexchange.com/a/18861 — pretty comprehensive answer.

@till well that's why composer by default downloads /packages.json with SSL and then downgrades to an http connection for the other files (which are verified via a chain of trust of sha256 hashes coming from the original file, that should be trusted because of SSL).

@Seldaek With proper signing, you wouldn't need that though. I think most/all package managers on Linux and Unix do signing. The public key comes from SSL or at least can be verified using a trusted source like a key server for example.

With signing you can do port 80 all you want. Announce mirrors, use a cdn, etc.. It becomes a no-brainer then.

HTTPS for package downloads is a bad idea because it prevents proxying through local caches (I have a very large upcoming use case for this, details to follow).

I think it's a good idea to re-use existing, established mechanisms for this. Namely, if a git tag is signed, then a package could contain an HTTPS URL to the public key used for signing (could even optionally be hosted on Packagist), and composer could use that to verify the signature upon install.

That leaves dists however, and signing those on Packagist may be problematic because it means that either one key signs everything, or that users need to trust Packagist with their GPG private key, which means if Packagist is ever compromised, all hell would break loose. So that's out of the question, but Packagist could allow package owners to upload signatures for the dists. A --require-signed option would then pull dists that have been signed, and if they haven't, pull git tags from source.

(Of course, that doesn't yet address SVN tags et cetera, but who knows what we can come up with - maybe the "standard" input format for what's to be signed could be whatever composer archive produces)

2014 — 👯

@Seldaek Any idea if we can move forward with this soon?