Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

[WIP] SSL/TLS Support #2745

Open
wants to merge 38 commits into from

8 participants

@padraic

This is a work in progress! Please do review and comment.

This PR is designed to do a few things:
1. The RemoteFilesystem class configures itself with default TLS options in line with PHP 5.6's adopted values if TLS protection has NOT been explicitly disabled by the user. This means Composer does everything possible to do HTTPS right - and lets the user shoulder the risk of disabling it. All instances are now created using Composer\Factory::createRemoteFilesystem().
2. Where any TLS option needs user input, e.g. a CA certificate file, we give them an error. They can now set a cafile option in config.json or pass a cafile option with value on CLI. If they can't/won't do that, they can resort to setting a disable-tls option in config.json or via CLI at their own risk.
3. Composer will distribute a cacert.pem file. This is used as a last resort option wherever possible and will be updated alongside Composer self-updates. There will need to be a process introduced to regularly check/update this file in the git repository.

This should resolve the TLS portion of #1074.

The Composer Installer is also being updated: composer/getcomposer.org#61

TODO:
1. Most of the TLS configuration is unnecessary under PHP 5.6 since it does all this automatically from that version.
2. Documentation updates.

I'm hoping to complete the PR over the next week - but feel free to PR my fork (the tls-config branch).

@Ocramius

Hmm - can't it use the same URI without actually checking certs?

You could - but why make it look secure if it's not? :) Beyond self-update (we take Composer.org for granted), it's entirely possible using a https instead of http will net you an error when connections to port 443 fail because the server has no TLS support enabled.

Gotcha - didn't think the connection would be refused

@rdlowrey

PHP 5.3 will definitely never have SAN matching backported. SAN matching won't make it into the next line of 5.4/5.5 bugfix releases, but should be in the following batch (so probably 5.5.11 and 5.4.27).

How names are matched internally

  1. Determine which host name we need to use when matching against the name(s) in the peer's cert.

    • If "CN_match" specified this name is used
    • Otherwise, the host component of the requested URI is used. If your request is against an IP address and doesn't specify a name you must specify the "CN_match" context option or your connection will fail (assuming the peer cert isn't using the IP address in its name).
  2. The name determined in step 1 is matched against the DNS entries of the SAN extension list (if present) in the peer's certificate. If a match is found we're finished verifying the name and no further action is required.

  3. If we're still here no SAN match was found and we try matching against the peer cert's common name (CN) field with (wildcard matching if the CN looks like *.mydomain.com).

As of 5.6 you generally don't need to specify a "cafile" because PHP is able to fallback to the CA cert store managed by the operating system. So for 5.6+ most everything will "just work" in the same way people are used to in their browsers.

Once SAN support is backported to 5.4/5.5 you will still need to manually set "verify_peer" => true as verification WILL NOT be enabled automatically. Also, you will still need to manually specify a "cafile" context option or verification will fail because the cert itself can't be verified and you'll never arrive at the name matching step.

SAN backporting is not implemented at this time and my estimates for version numbers are just that: estimates. I will try to backport it as soon as I have time, though. The surest bet will be to encourage everyone you know to upgrade to 5.6 if possible once released.

@padraic

For those watching the Travis CI build, looks like openssl_x509_parse() isn't available for PHP 5.3.3 so it's erroring out. The function has some pretty bad security issues not fixed in that version, so it may have been disabled or something.

.travis.yml
@@ -7,10 +7,12 @@ php:
- 5.5
- 5.6
- hhvm
+ - 5.6
@till
till added a note

:trollface:

@padraic
padraic added a note

haha :P /me should RTFS!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
src/Composer/Factory.php
@@ -193,7 +194,28 @@ public function createComposer(IOInterface $io, $localConfig = null, $disablePlu
if (is_string($localConfig)) {
$composerFile = $localConfig;
- $file = new JsonFile($localConfig, new RemoteFilesystem($io));
+
+ $rfs = null;
+ if (preg_match("|^https?://|i", $localConfig)) {
+ $disableTls = false;
+ if($input->getOption('disable-tls')) {
+ //$output->writeln('<warning>You are running Composer with SSL/TLS protection disabled.</warning>'); //TODO
+ $disableTls = true;
+ } elseif (!extension_loaded('openssl')) {
@till
till added a note

Throw first, then check option. Avoid if/elseif.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@till till commented on the diff
src/Composer/Util/RemoteFilesystem.php
((113 lines not shown))
+ */
+ protected static function getSystemCaRootBundlePath()
+ {
+ if (isset($found)) {
+ return $found;
+ }
+ // If SSL_CERT_FILE env variable points to a valid certificate/bundle, use that.
+ // This mimics how OpenSSL uses the SSL_CERT_FILE env variable.
+ $envCertFile = getenv('SSL_CERT_FILE');
+ if ($envCertFile && is_readable($envCertFile) && \openssl_x509_parse(file_get_contents($envCertFile))) {
+ // Possibly throw exception instead of ignoring SSL_CERT_FILE if it's invalid?
+ return $envCertFile;
+ }
+
+ $caBundlePaths = array(
+ '/etc/pki/tls/certs/ca-bundle.crt', // Fedora, RHEL, CentOS (ca-certificates package)
@till
till added a note

Is it a good idea to have these here? Because what about all these other distributions which are not on here. Who knows what they all do. Just wondering if instead the installer should try to determine this and you rather advertise how to override it.

@padraic
padraic added a note

Possibly, let's get it all working first though ;). Also need to add new openssl.cafile INI check for PHP 5.6, capath checks for all, etc.

@till
till added a note

In addition, it's probably not the best idea to rely on a gov-friendly CA which is shipped with the OS and instead educate people how to do this right. I mean, that is after all why you're coding this. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@till

@padraic Kudos for working on this.

src/Composer/Factory.php
@@ -441,10 +444,49 @@ protected function purgePackages(Repository\RepositoryManager $rm, Installer\Ins
* @param bool $disablePlugins Whether plugins should not be loaded
* @return Composer
*/
- public static function create(IOInterface $io, $config = null, $disablePlugins = false)
+ public static function create(IOInterface $io, $config = null, $disablePlugins = false, InputInterface $input = null)
@till
till added a note

Trying to figure out why you added this. But going in circles.

From what I understand, or thought (so take this with a grain of salt), everything supplied via input/option is merged into the configuration instance. Same for settings from any .json files involved from composer. So maybe see about this so you can drop the dependency on the InputInterface.

@padraic
padraic added a note

At the moment it's an artifact (to be removed) - I replaced this by adding IOInterface methods: getInputOption() and getInputArgument(). IOInterface objects are already passed into RemoteFilesystem and other places.

I don't think IO options are merged into Config anywhere. I wouldn't expect them to be either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@till till commented on the diff
src/Composer/Command/DiagnoseCommand.php
((17 lines not shown))
+ if (!extension_loaded('openssl') && !$disableTls) {
+ $result[] = '<error>Composer is configured to use SSL/TLS protection but the openssl extension is not available.</error>';
+ }
+
+ $rfsOptions = array();
+ if (!$disableTls && !is_null($config->get('cafile'))) {
+ $rfsOptions = array('ssl'=>array('cafile'=>$config->get('cafile')));
+ }
+ try {
+ $this->rfs = new RemoteFilesystem($this->getIO(), $rfsOptions, $disableTls);
+ } catch (TransportException $e) {
+ if (preg_match('|cafile|', $e->getMessage())) {
+ $result[] = '<error>[' . get_class($e) . '] ' . $e->getMessage() . '</error>';
+ $result[] = '<error>Unable to locate a valid CA certificate file. You must set a valid \'cafile\' option.</error>';
+ $result[] = '<error>You can alternatively disable this error, at your own risk, by enabling the \'disable-tls\' option.</error>';
+ } else {
@till
till added a note

Minor nitpick, but I'd reverse this. Throw first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@padraic

I have also made a start on updating the Composer Installer: composer/getcomposer.org#61

@padraic padraic referenced this pull request
Open

Curl transfer #2696

@StormTide StormTide commented on the diff
doc/00-intro.md
@@ -152,6 +154,14 @@ run this instead:
Following the [example above](#declaring-dependencies), this will download
monolog into the `vendor/monolog/monolog` directory.
+> **Note:** Composer will attempt to protect all HTTPS requests using SSL/TLS. It
+> implements peer verification using a certificate bundle, either one installed on
+> the local system or a copy distributed with Composer. You may also pass the path
+> to a bundle using the --cafile option for most commands. While you can also
+> disable peer verification by passing the --disable-tls option, this is not
+> recommended and will leave all downloads susceptible to Man-In-The-Middle (MITM)
+> attacks.

I question the use case for adding --disable-tls. This will be abused like verifypeer=false is. At the very least, should be renamed --idiot-mode or similar to make clear that this is a really stupid thing to enable.

@padraic
padraic added a note

You can also question why browsers allows it, why curl allows, etc. Composer is a tool. It is not a judge. If users wish to take risks, that's their business. My only concern is making sure the tool doesn't make the wrong choice by default.

That cURL allowed this has resulted in unprecedented compromise of personal information, credit card data and caused extreme harm to the ecosystem. (See IN11-003/PeerJacking) Browsers don't allow it for mechanisms they control, (all browsers installed signed updates for example)... and you cant disable tls/ssl and still use https scheme in any browser I know of. No commercial browser will communicate on port 443 with peer verification disabled.

@renan
renan added a note

We should have a way to disable peer verification like any other tool, including all browsers. Chrome for example will ask you whenever you try to access a website that uses a self-signed certificate and if accepted will show a This certificate has not been verified by a third party message on the address bar.

I am just not sure if --disable-tls is the right option name. Any communication on HTTPS will have the data encrypted with the certificate, be it verified by a Peer (eg: Thawte) or not. Perhaps --verify-peer=false describes the functionality better, unless --disable-tls is really disabling encryption. But IMO either the option or the description of the functionality needs to change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@StormTide StormTide commented on the diff
doc/03-cli.md
@@ -88,6 +88,8 @@ resolution.
* **--optimize-autoloader (-o):** Convert PSR-0/4 autoloading to classmap to get a faster
autoloader. This is recommended especially for production, but can take
a bit of time to run so it is currently not done by default.
+* **--disable-tls:** Display SSL/TLS peer verification.

s/Display/Disables

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
doc/03-cli.md
@@ -125,6 +127,8 @@ You can also use wildcards to update a bunch of packages at once:
lock file being out of date.
* **--with-dependencies** Add also all dependencies of whitelisted packages to the whitelist.
So all packages with their dependencies are updated recursively.
+* **--disable-tls:** Display SSL/TLS peer verification.

s/Display/Disables

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@StormTide StormTide commented on the diff
src/Composer/Factory.php
((4 lines not shown))
+
+ /**
+ * @param IOInterface $io IO instance
+ * @param Config $config Config instance
+ * @param array $options Array of options passed directly to RemoteFilesystem constructor
+ * @return RemoteFilesystem
+ */
+ public static function createRemoteFilesystem(IOInterface $io, Config $config = null, $options = array())
+ {
+ $disableTls = false;
+ if((isset($config) && $config->get('disable-tls') === true) || $io->getInputOption('disable-tls')) {
+ $io->write('<warning>You are running Composer with SSL/TLS protection disabled.</warning>');
+ $disableTls = true;
+ } elseif (!extension_loaded('openssl')) {
+ throw new \RuntimeException('The openssl extension is required for SSL/TLS protection but is not available. '
+ . 'You can disable this error, at your own risk, by passing the \'--disable-tls\' option to this command.');

This is bad advice. Teach how to install the openssl extension, dont give the easy fish of --disable-tls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@StormTide StormTide commented on the diff
src/Composer/Util/RemoteFilesystem.php
((6 lines not shown))
{
$this->io = $io;
- $this->options = $options;
+
+ /**
+ * Setup TLS options
+ * The cafile option can be set via config.json
+ */
+ if ($disableTls === false) {
+ $this->options = $this->getTlsDefaults();
+ if (isset($options['ssl']['cafile'])
+ && (!is_readable($options['ssl']['cafile'])
+ || !\openssl_x509_parse(file_get_contents($options['ssl']['cafile'])))) {

This introduces a security vulnerability. Needs version checking before calling openssl_x509_parse. See. https://www.sektioneins.de/advisories/advisory-012013-php-openssl_x509_parse-memory-corruption-vulnerability.html

@rdlowrey
rdlowrey added a note

Considering the context in which this usage of openssl_x509_parse() occurs this is basically a complete non-issue. The very worst-case scenario is that your composer script segfaults. No one should be performing composer installations during script execution in a web SAPI environment, so there's no real DoS risk here. The advisory only has security implications if using the function to parse certificates submitted from an unsafe source.

Beyond this, for the "security vulnerability" to be exploitable in this case the certificate file under your control must already have been compromised. If this is the case you have significantly larger problems than your composer script segfaulting.

It boils down to a case of eval(cafile) essentially. I'd argue that this is dangerous, but one could argue that the cafile can be trusted to not run arbitrary code. I'd add the version checks.

@rdlowrey
rdlowrey added a note

Just so everyone is clear: these notes do address a very real bug in the old openssl_x509_parse() function that can lead to memory corruption. I'm not suggesting they don't :)

I'm just suggesting that something like this can only cause problems if the certificates you trust inherently (and those your OS trusts in the case of most of these paths) are already compromised.

Adding version checks could basically only prevent you from using a CA file that you trust. Unless you're using a very recent PHP version you won't be able to use encryption to retrieve composer resources. At this point your only remaining option would be to disable peer verification (short of removing the openssl_x509_parse() call altogether) and this would lead to a much more significant security risk. This would definitely be a case of the medicine being worse than the disease.

Actually I cant see why this parse call is even needed in this code. Its only being used as a validator.
As for the the alternative being to disable tls, thats not the case. If (vulnversion) { die() } is also a valid way to handle this -- lets not continue to be a slave to sacrificing security to bad sysadmins who refuse to patch in the name of compatibility.

As detailed below, this could result in privilege escalation attacks and other nastiness.

@rdlowrey
rdlowrey added a note

Not sure how die() could possibly make sense as an alternative. The point is to retrieve the information securely. Of course, not using the program (die()) is always an option ... but it's just not a valid one in this case.

It should be said that I 100% agree with you: people should be expected to keep their software up-to-date. Anything less is negligent. Should people who can't or don't be subsidized? Probably not. But that's a decision for maintainers and not me :)

if(vulnversion) { die('Your php version is insecure/broken; please upgrade to <safeversion> and run this command again'); } <---- totally valid way to handle this.

@rdlowrey
rdlowrey added a note

\o/ ... I would be thrilled if more people started doing this. The users who aren't capable or don't have permission to instigate an upgrade themselves would start complaining to hosting companies and technology departments en masse. The result would likely be much quicker uptake of security fixes and new features.

Indeed. This should be the norm. Can always add the above proposed --idiot-mode override to this too ;)

@Seldaek Owner
Seldaek added a note

@StormTide just to be sure I didn't misunderstand this, passing a bad CA file into the stream context options is safe in those vulnerable php versions? The vulnerability only applies to openssl_x509_parse as far as I can tell.

@Seldaek yes, I believe this is safe. The openssl_x509_parse vulnerability comes specifically from their trying to add date information to the parsed structure, which I dont believe the context options do.

@rdlowrey
rdlowrey added a note

@Seldaek That's correct. The problem was that the original openssl_x509_parse implementor didn't verify the expected string length against that of the ASN1 string (which can contain null bytes) that results from manually parsing the certificate data. Any parsing of files passed in via the cafile stream context is done by the underlying OpenSSL lib and isn't affected by this issue.

@Seldaek Owner
Seldaek added a note

Alright so we just skip it on vulnerable versions. The chances of having an accidentally invalid CA file are probably equally low vs the chances of having an exploited CA file, so I'd rather take the safer approach. Would you mind doing a similar thing to composer/getcomposer.org@a345c19 @padraic ?

@padraic
padraic added a note

@Seldaek Agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@StormTide StormTide commented on the diff
src/Composer/Util/RemoteFilesystem.php
((120 lines not shown))
+ * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+ protected static function getSystemCaRootBundlePath()
+ {
+ if (isset($found)) {
+ return $found;
+ }
+ // If SSL_CERT_FILE env variable points to a valid certificate/bundle, use that.
+ // This mimics how OpenSSL uses the SSL_CERT_FILE env variable.
+ $envCertFile = getenv('SSL_CERT_FILE');
+ if ($envCertFile && is_readable($envCertFile) && \openssl_x509_parse(file_get_contents($envCertFile))) {

This introduces a security vulnerability. Needs version checking before calling openssl_x509_parse. See. https://www.sektioneins.de/advisories/advisory-012013-php-openssl_x509_parse-memory-corruption-vulnerability.html

@rdlowrey
rdlowrey added a note

Since copy/pasting the same message is pointless, see the further explication instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@StormTide StormTide commented on the diff
src/Composer/Util/RemoteFilesystem.php
((139 lines not shown))
+
+ $caBundlePaths = array(
+ '/etc/pki/tls/certs/ca-bundle.crt', // Fedora, RHEL, CentOS (ca-certificates package)
+ '/etc/ssl/certs/ca-certificates.crt', // Debian, Ubuntu, Gentoo, Arch Linux (ca-certificates package)
+ '/etc/ssl/ca-bundle.pem', // SUSE, openSUSE (ca-certificates package)
+ '/usr/local/share/certs/ca-root-nss.crt', // FreeBSD (ca_root_nss_package)
+ '/usr/ssl/certs/ca-bundle.crt', // Cygwin
+ '/opt/local/share/curl/curl-ca-bundle.crt', // OS X macports, curl-ca-bundle package
+ '/usr/local/share/curl/curl-ca-bundle.crt', // Default cURL CA bunde path (without --with-ca-bundle option)
+ '/usr/share/ssl/certs/ca-bundle.crt', // Really old RedHat?
+ __DIR__.'/../../../res/cacert.pem', // Bundled with Composer
+ );
+
+ static $found = false;
+ $configured = ini_get('openssl.cafile');
+ if ($configured && strlen($configured) > 0 && is_readable($caBundle) && \openssl_x509_parse(file_get_contents($caBundle))) {

This introduces a security vulnerability. Needs version checking before calling openssl_x509_parse. See. https://www.sektioneins.de/advisories/advisory-012013-php-openssl_x509_parse-memory-corruption-vulnerability.html

Its a good place to point out privilege escalation scenarios arising from being able to write any of these cafile locations (that may or may not exist, or be writable)... create a malicious bundle and wait for root to run composer. Theres obviously easier ways, but add the version checks ;)

@rdlowrey
rdlowrey added a note

Since copy/pasting the same message is pointless, see the further explication instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@StormTide StormTide commented on the diff
src/Composer/Util/RemoteFilesystem.php
((144 lines not shown))
+ '/usr/local/share/certs/ca-root-nss.crt', // FreeBSD (ca_root_nss_package)
+ '/usr/ssl/certs/ca-bundle.crt', // Cygwin
+ '/opt/local/share/curl/curl-ca-bundle.crt', // OS X macports, curl-ca-bundle package
+ '/usr/local/share/curl/curl-ca-bundle.crt', // Default cURL CA bunde path (without --with-ca-bundle option)
+ '/usr/share/ssl/certs/ca-bundle.crt', // Really old RedHat?
+ __DIR__.'/../../../res/cacert.pem', // Bundled with Composer
+ );
+
+ static $found = false;
+ $configured = ini_get('openssl.cafile');
+ if ($configured && strlen($configured) > 0 && is_readable($caBundle) && \openssl_x509_parse(file_get_contents($caBundle))) {
+ $found = true;
+ $caBundle = $configured;
+ } else {
+ foreach ($caBundlePaths as $caBundle) {
+ if (is_readable($caBundle) && \openssl_x509_parse(file_get_contents($caBundle))) {

This introduces a security vulnerability. Needs version checking before calling openssl_x509_parse. See. https://www.sektioneins.de/advisories/advisory-012013-php-openssl_x509_parse-memory-corruption-vulnerability.html

@rdlowrey
rdlowrey added a note

Since copy/pasting the same message is pointless, see the further explication instead.

@padraic
padraic added a note

As @rdlowrey has indicated, the only certs we check are those at a system level or those bundled by composer, or something the user passes. If any such certificate has been compromised, it's already game over. I don't wish to debate the obviousness of a vulnerability, but we will need an alternative as a best attempt to tell users what's wrong instead of leaving them with some ambiguous security warning that may or may not apply to them in reality.

This allows a local privilege escalation attack with arbitrary code execution. This is a security vulnerability. You have to remember that composer is run by a number of different system users, and often as root. The paths composer is scanning are not being checked for permissions, writableness by non-root users, etc. The fix is straightforward, version check before parse or get rid of the parse call (its not even needed here)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@Seldaek Seldaek added this to the Urgent milestone
@Seldaek Seldaek added the Feature label
@Seldaek Seldaek referenced this pull request
Closed

Composer on PHP 5.6 #2887

@xsist10 xsist10 commented on the diff
src/Composer/Compiler.php
@@ -110,6 +110,9 @@ public function compile($pharFile = 'composer.phar')
$this->addFile($phar, new \SplFileInfo(__DIR__.'/../../vendor/composer/include_paths.php'));
}
$this->addFile($phar, new \SplFileInfo(__DIR__.'/../../vendor/composer/ClassLoader.php'));
+
+ $this->addFile($phar, new \SplFileInfo(__DIR__ . '/../../res/cacert.pem'), false);
@xsist10
xsist10 added a note

The bundled cert file will need to be extracted from the composer.phar otherwise the openssl lib won't be able access it (similar to how Guzzle handles it here: https://github.com/guzzle/guzzle/blob/045ade85d801ce932b9e85bd94be4931110393e6/phar-stub.php)

This is true for PHP < 5.6 ... As of 5.6 ext/openssl supports non-remote stream wrappers (e.g. phar://) when loading CA certs. This functionality was originally requested in Bug #65538 and support for this feature is added in 5.6.

Note that I made the "executive decision" to prohibit the use of remote stream wrappers for this purpose so people couldn't facepalm themselves in this manner:

<?php // Note this WILL NOT work (thankfully)
$ctx = stream_context_create(['ssl' => [
    'cafile' => 'http://curl.haxx.se/ca/cacert.pem'
]]);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@texdc texdc referenced this pull request in zencart/zc-v1-series
Merged

Initial commit for basic vendor autoloading #95

1 of 1 task complete
padraic added some commits
@padraic padraic Merge branch 'master' into tls-config
Conflicts:
	.travis.yml
	doc/03-cli.md
	src/Composer/Command/ConfigCommand.php
	src/Composer/Command/CreateProjectCommand.php
	src/Composer/Command/DiagnoseCommand.php
	src/Composer/Command/InstallCommand.php
	src/Composer/Command/RequireCommand.php
	src/Composer/Command/SelfUpdateCommand.php
	src/Composer/Command/ShowCommand.php
	src/Composer/Command/UpdateCommand.php
	src/Composer/Config.php
	src/Composer/Downloader/FileDownloader.php
	src/Composer/Factory.php
	src/Composer/Repository/ComposerRepository.php
	src/Composer/Repository/PearRepository.php
	src/Composer/Repository/Vcs/VcsDriver.php
	src/Composer/Util/GitHub.php
	src/Composer/Util/RemoteFilesystem.php
19e24c5
@padraic padraic Resolve final conflicts 6ce20d3
@padraic

I expect it's broken in Travis, but I did an initial update to current master. Will need to fix issues and review comments.

@Seldaek Seldaek modified the milestone: Urgent, Backwards Compatible
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 23, 2014
  1. @padraic
  2. @padraic

    Restructure self-update http/https decision

    padraic authored
    Error on non-openssl and warn user about setting disable-tls to disable error.
    If disable-tls is true, ad an info message about running in non-TLS mode.
  3. @padraic

    Added Exceptions, errors and info messages for self-update command an…

    padraic authored
    …d TLS defaults to RemoteFilesystem
  4. @padraic
  5. @padraic
  6. @padraic
  7. @padraic
  8. @padraic
  9. @padraic

    Some typos/corrections

    padraic authored
  10. @padraic
  11. @padraic
  12. @padraic
  13. @padraic
Commits on Feb 24, 2014
  1. @padraic
  2. @padraic
  3. @padraic
  4. @padraic
Commits on Feb 25, 2014
  1. @padraic
  2. @padraic

    Add Common Name (CN) matching checks and TLS connection retry (by def…

    padraic authored
    …ault).
    
    For example, the communicated host will be github.com, but the CN is *.github.com. Also not matching api.github.com.
    The logic detects an initial TLS CN-mismatch error, and parses the correct CN from the error, then checks if the CN and URL have same host before retrying.
Commits on Feb 26, 2014
  1. @padraic
  2. @padraic

    Fix CN matching to use correct host (should almost eliminate TLS retr…

    padraic authored
    …ies where wildcard CNs are used)
Commits on Feb 27, 2014
  1. @padraic
  2. @padraic

    Merge branch 'master' of github.com:composer/composer into tls-config

    padraic authored
    Conflicts:
    	src/Composer/Util/RemoteFilesystem.php
Commits on Feb 28, 2014
  1. @padraic
  2. @padraic
  3. @padraic
  4. @padraic
Commits on Mar 1, 2014
  1. @padraic

    Adds Composer\Factory::createRemoteFilesystem():

    padraic authored
    - Implemented in self-update command
    - Added to Composer\IO\BaseIO the getInputOption() and getInputArgument() getters to allow access to input
    - Fixed some minor bugs
  2. @padraic

    Implement the RemoteFilesystem Factory everywhere...

    padraic authored
     - also fixes impacted test
Commits on Mar 2, 2014
  1. @padraic
  2. @padraic

    Remove InputInterface passing from previous commits

    padraic authored
     - no longer necessary with IOInterface update
  3. @padraic
  4. @padraic
  5. @padraic
Commits on Jan 29, 2015
  1. @padraic

    Merge branch 'master' into tls-config

    padraic authored
    Conflicts:
    	.travis.yml
    	doc/03-cli.md
    	src/Composer/Command/ConfigCommand.php
    	src/Composer/Command/CreateProjectCommand.php
    	src/Composer/Command/DiagnoseCommand.php
    	src/Composer/Command/InstallCommand.php
    	src/Composer/Command/RequireCommand.php
    	src/Composer/Command/SelfUpdateCommand.php
    	src/Composer/Command/ShowCommand.php
    	src/Composer/Command/UpdateCommand.php
    	src/Composer/Config.php
    	src/Composer/Downloader/FileDownloader.php
    	src/Composer/Factory.php
    	src/Composer/Repository/ComposerRepository.php
    	src/Composer/Repository/PearRepository.php
    	src/Composer/Repository/Vcs/VcsDriver.php
    	src/Composer/Util/GitHub.php
    	src/Composer/Util/RemoteFilesystem.php
  2. @padraic

    Resolve final conflicts

    padraic authored
  3. @padraic
  4. @padraic
Something went wrong with that request. Please try again.