I think this PR is a great step towards making Composer more secure. I cannot help but notice though that a lot of the comments seem defensive, seemingly preferring less secure options. Given that things like these were not built in from the start, and esp. stuff like gpg signing was not included from the start, I have to wonder if it's secure by design, or that the intention is now to patch it up, hoping we cover enough to make it more or less secure?

There was simply no expectation of security at the beginning. To be entirely sure about the security of the code you run you will have to review it yourself. When using 3rd party libraries you always place some trust into those 3rd party libraries. The work being done now, is to make it more difficult for an attacker to get between you and that 3rd party. The responses aren't defensive, they are trying to make sure composer continues to actually work. Because what is the point of making it more secure if you can then no longer use it? Hence we need to come up with secure and working solutions like the proposed option for switching to a mode in which communication is not necessarily secure if that is not an option available on the respective system.

@naderman I totally understand your points. That said, your quote, "To be entirely sure about the security of the code you run you will have to review it yourself. When using 3rd party libraries you always place some trust into those 3rd party libraries," leaves this open: you need to be able to trust that the 3rd party library whose code you are reviewing is actually from the 3rd party you tried to obtain it from. That's the primary driver of this PR, from my standpoint as primarily a user, and secondarily somebody providing packages for others.

@weierophinney Yes absolutely, that's what I meant by "The work being done now, is to make it more difficult for an attacker to get between you and that 3rd party."

👍

@Freeaqingme if you look at the comments here, you may notice that we've for many people deeply interested in security struggling to figure out how exactly to do validate an ssl connection in php. That is part of the reason the network security hasn't been addressed before: it's a huge pain and php is clearly not helping. As for the defensive comments, I was just trying to find a balance between security requirements and usability. Some people just can not enable openssl for various reasons (often bad ones IMO, but we can only nudge in the right direction), and it should not mean they can't use composer at all. That said, I'm glad we now have so many people interested in fixing this for good.

No one should be using composer over http the way it is today without package signing. IMO It shouldnt even be an option. It's like voluntarily installing a backdoor on your machine.

The difficulty here comes from trying to use the built-in openssl stuff which, yes, requires some understanding of SSL to use... cURL could handle this easily, safely and securely with default options on the other hand.

@Seldaek It's understandable that many people can't enable openssl, I know how policy and bureaucracy can get in the way of things. To address this, however, I believe composer should be secure by default and only be insecure if the user specifically configures it to be that way and throws lots of warnings in the users face when they do.

@PHLAK That's what the PR is aiming for. A lot of what is now being discussed (several of us being security knowledgeable) is working through PHP's obstacle course. It's native SSL/TLS handling sucks compared to Curl which is defaulted to be secure and usually has a CA bundle PEM pre-configured on package repos.

@PHLAK, @padraic, The nice thing is, with sslurp, Composer will be able to build and keep up-to-date the exact same CA bundle PEM that cURL uses -- it builds from the same source and in the same way as cURL's mk-ca-bundle.pl, except in a much more secure way (funny that cURL's build script fetches the CA bundle over HTTP).

@EvanDotPro your code needs a refactoring. Get rid of that autoload_* mess in root and refactor strings with values to contants and apply some conding standards.

Sorry for the OT.

@hosiplan, I'll eventually get around to cleaning the code -- right now we are focusing on actual security and integrity of the data. If it's a problem for you right now, I'd gladly accept a pull request.

Status update: I'm just finishing up some stuff in sslurp, then I'll update this PR.

If #1177 is merged, perhaps this can be simplified? For example, if openssl support is enabled, default Composer\Config#defaultRepositories to something like:

public static $defaultRepositories = array(
    'packagist' => array(
        'type' => 'composer',
        'url' => 'https://packagist.org',
        'options' => array(
            'ssl' => array(
                'verify_peer' => true,
                'allow_self_signed' => false,
                'cafile' => SslHelper::initCaBundleFile(),
            ),
        ),
    ),
);

Then, if people have openssl enabled but for some reason want to force a plain HTTP connection, they can simply do this in their composer.json:

{
    "repositorries": [
        {
            "packagist": false,
        },
        {
            "type": "composer",
            "url": "http://packagist.org",
        }
    ]
}

@sandermarechal You would also need to include the CN_match option in the SSL Context (to ensure the valid certificate is for the Host being requested over HTTPS). Secondly, you also need to replace all instances of file_get_contents() across Composer. Recommended security practice is to disable the allow_url_fopen setting in php.ini that Composer currently requires to be enabled. This means switching from file_get_contents() to a non-file op using sockets.

If anyone likes to do some reading ;) https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

@Seldaek http://www.unrest.ca/responsible-disclosure-and-the-academy .... if anyone wants to do some reading ;)

@StormTide eh well, not saying it was smart, but now that it's out there, we might as well take good note of it.

@StormTide ah, read in more details.. sorry to hear. Anyway if sslurp helps with that I'm glad.

What happened to this PR?

Can anyone summairze what the outstanding issues are? :)

@till @EvanDotPro Anything needed to poke this along to completion? It's been five months so where do we stand at this point?

As mentioned on Twitter, I'm looking to finally finish this up this month now that I have the time. I need some help reviewing Sslurp, as I want to make sure the method it uses for establishing a trusted certificate bundle is well-reviewed and agreed to be secure before I integrate it into Composer. I also want to look at fixing the installer script as well, because if they get a compromised copy of Composer in the first place, all this work is for nothing.

@EvanDotPro did you get anywhere? No idea if @padraic helped you review Sslurp.

@till unfortunately, I shortly after SunshinePHP, I began to get pretty busy again. It's looking like there's beginning to be a renewed interest in this again though, and I have a new client interested in implementing composer into their workflow, so maybe with enough poking and prodding from the community, I can try to find some time to wrap this up once and for all. I haven't really gotten any official 👍's on Sslurp from known security professionals yet though, which would certainly be helpful.

/me looks at @padraic and @ircmaxell. 😄

(sorry, didn't mean to close and reopen...)

@EvanDotPro would it make sense to crowdfund this for you? Because this is really important issues which has to be solved. I believe a lot of developers would help you to get your time paid so you can find some time to do it.

Also there are many groups in PHP world which would benefit from this pull request, like Zend, Sensio and everyone who uses composer to install their dependencies which are then used on production servers (this is major issue, because lot of people uses CI to automatically install dependencies and they then deploy these to production directly).

Closing this per @padraic's awesome contributions lately which have addressed most of these concerns!

Thank you so much @padraic for taking the time to do this!

@EvanDotPro so to go back on an old issue, but could you reference the stuff you're talking about here?

@rubensayshi wrote:

could you reference the stuff you're talking about here?

See PR #2745 (which also seems to have stalled out)