🍻 Default formulae for the missing package manager for macOS

Find a file

Dominyk Tiller 30d3766453 openssl: tweak PEM generation Due to the more or less blind trust external tools place in the PEM generated and stored in `/usr/local/etc/openssl` (Presuming your Homebrew is in the normal place) it's possible for self-signed or explicitly not trusted certificates to be treated as perfectly valid and safe. This results in some potentially unexpected differences between system-provided tools and Homebrew-provided tools linked against different crypto libraries. By default both the system curl (Since Mountain Lion) and Homebrew's curl (For ML and above) are linked to Apple's Secure Transport, which handles self-signed certificates in the Keychain as invalid unless they are explicitly trusted and throws the following error on connection: `* SSL certificate problem: Invalid certificate chain`. If you mark the certificate in the Keychain as explicitly trusted both the system and default Homebrew curl respect that and will permit the connection to be established: ``` Connected to abc.def (xxx.xxx.xxx.xx) port 443 (#0) TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Server certificate: abc.def ... Connection #0 to host abc.def left intact ``` This is also the situation for at least Safari and Google Chrome on OS X, where Keychain trust status guides whether or not the self-signed certificate should be trusted. Where things are potentially more dicey is where you have built Homebrew's curl against OpenSSL or LibreSSL, which is a fairly common configuration, and you have a self-signed certificate in the Keychain when OpenSSL/LibreSSL is installed/upgraded/etc. That self-signed cert is folded into the PEM and treated as perfectly valid, even if it was marked explicitly not trusted in the Keychain at time of PEM creation. This enables self-signed cert connections to go ahead without notification of the potential issue. It's mildly easier to spot on verbose curl connections, but no obvious warning is included that you're using a self-signed certificate for the connection. The example below was explicitly generated as a test cert and tagged as such: ``` * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server did not agree to a protocol * Server certificate: * subject: C=GB; O=TEST.ORG; OU=TESTING; CN=abc.def; emailAddress=test@abc.def * start date: May 9 20:28:52 2016 GMT * expire date: June 9 20:28:52 2016 GMT * common name: abc.def (matched) * issuer: C=GB; O=TEST.ORG; OU=TESTING; CN=abc.def; emailAddress=test@abc.def * SSL certificate verify ok. ``` Although curl is used for testing here, wget and other utilities that trust OpenSSL's PEM file are impacted as well. This change results in the PEM file only containing system root certificates, which is a more secure default position to take. If you relied on the previous behaviour you can re-enable it by copying PEM files into `/usr/local/etc/openssl/certs` & running `$(brew --prefix openssl)/bin/c_rehash`. You may need to pass the directory to specific tools or by setting the SSL_CERT_DIR variable. Credit to Geoff Nixon for the original report. Extra testing done by me against an Ubuntu server running the latest nginx release. Closes #1072. Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>		2016-05-12 02:18:14 +01:00
.github	PR template: use HR to separate checklist from body	2016-05-03 00:31:37 -04:00
Aliases	dbus: rename from d-bus	2016-05-11 21:06:42 +01:00
Formula	openssl: tweak PEM generation	2016-05-12 02:18:14 +01:00
.travis.yml	travis: run test-bot from /usr/local	2016-04-25 14:09:13 +02:00
formula_renames.json	dbus: rename from d-bus	2016-05-11 21:06:42 +01:00
LICENSE.txt	add LICENSE.txt	2016-03-02 18:44:21 +08:00
README.md	README: duplicate more of Homebrew/brew README.md	2016-04-04 03:59:16 -07:00
tap_migrations.json	cvc4: update tap_migrations.json	2016-05-06 13:32:56 -04:00