Page MenuHomePhabricator

PhpHttpRequest requires a certificate repository
Closed, ResolvedPublic

Description

When I activated $wgInstantCommons on my fresh computer without php-curl (so MW used PhpHttpRequest to download data from Commons), it didn’t work until I specified the caInfo option in PhpHttpRequest (to /etc/ssl/certs, Ubuntu 14.04).

(Then I experienced bug 73199 but this is not directly linked.)

It would be nice if this piece of code could automatically find the certificate repository file or directory. Perhaps some magic value make PHP automatically find the default cert repo of the system or perhaps it works on some couple (PHP version, Operating System).

Else I don’t see other solutions than specifing default cert repo for major OS (I know, it would be a pain to maintain it). Or another option would be to even remove all HTTPS-related code in PhpHttpRequest and require CURL for HTTPS.

Before changing anything, it would be great to see this is bug is widely experienced on various platforms (PHP+OS) or if it is only an isolated case.


Version: 1.25-git
Severity: normal

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:45 AM
bzimport set Reference to bz73203.
bzimport added a subscriber: Unknown Object (MLST).

Starting with php 5.6 we have the nice openssl_get_cert_locations() function... but that doesn't help us on older versions.

I think we should just check if /etc/ssl/certs exists (and whatever other common places exist) and use that

http://www.docnet.nu/tech-portal/2014/06/26/ssl-and-php-streams-part-1-you-are-doing-it-wrongtm/C0 is also interesting reading.

Maybe we should "encourage" people to instal php5-curl in the installer. fopen support for ssl is so borked...

Change 222079 had a related patch set uploaded (by Brian Wolff):
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/222079

Is this ready to merge? into upcoming point releases? we're basically way overdue for giving up on clients that can't do basic HTTPS...

This Stackoverflow answer (written by a PHP dev who works on SSL issues) is a good summary of the situation. Some highlights:

  • PHP pre-5.6 does not support Windows certfiles for SSL (cannot handle the format)
  • PHP 5.6 supports OS cert files (both Linux and Windows) which means it will actually be better than curl (which comes with bundled root certs and is less up to date)

Also, PHP 5.6 got a huge SSL update in general. So we might want to revisit our decision to prefer libcurl when available.

Unrelated to this task but the TLS defaults RFC has an example for sending secure requests in old PHP which includes setting 'disable_compression' => true (to prevent CRIME I presume), which we don't.

Change 222079 merged by jenkins-bot:
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/222079

Change 237000 had a related patch set uploaded (by Gergő Tisza):
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/237000

Change 237002 had a related patch set uploaded (by Gergő Tisza):
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/237002

Change 237003 had a related patch set uploaded (by Gergő Tisza):
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/237003

Change 237000 merged by jenkins-bot:
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/237000

Change 237003 merged by jenkins-bot:
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/237003

Tgr claimed this task.

Change 237002 merged by jenkins-bot:
Use system default location for cafile when using php fopen.

https://gerrit.wikimedia.org/r/237002