#9 issue #8: libphutil also ships resources/
Opened by derkuci. Modified
derkuci/phabphourphedora libphutil-ship-resources  into  master

Download 9.patch

This fixes issue #8 by also shipping the resources/ folder.

Comparing with the other suggested solution (set curl.cainfo in /etc/php.d/20-curl.ini to /etc/pki/tls/certs/ca-bundle.crt), I personally prefer shipping the resources/ folder, since this is more local to libphutil, and also it is suggested that a custom.pem could be placed in the resources/ssl/ folder to work with special cases.

Fundamentally, one of the guiding principles to any Fedora or Fedora-derived installation (Red Hat, CentOS) is to not allow individual applications to ship things such as ca-trust bundles or anchors "as if" they were to be considered equally valid to system-wide such bundles or anchors.

From a personal perspective, I would adhere to such standard. I would rely on the proper maintenance of ca-certificates much, much more than I would rely on phacility being sufficiently on top of things, and us being on top of things in appropriate fashion.

That being said, the underlying issue of php's curl not being configured quite correctly by default should be an issue not exclusive to the use of php's curl by libphutil. It should be impacting quite a variety of packages, albeit clearly not composer. Nonetheless, I would seek the resolution for the underlying issue to be sought with the default configuration of PHP itself, rather than providing the principally invalid approach in sub-ordinate packages such as libphutil.

I actually agree with you, in principle. In practice, since php is an RHEL package, I don't really know if CentOS is willing to make modifications, or how long the process might take. I'll file a bug report with Fedora rawhide and hope it'll propagate to RHEL/CentOS some day. For my immediate need, I can of course make my own libphutil package, or carry out the modifications to /etc/php.d/20-curl.ini manually, but thought it would be beneficial to other users of your repo. With that said, I can totally understand why you don't want to do this.

Metadata