Native executable: use certifi to provide cacert

[fsat]

This is because when packaging as native executable, the ssl.get_default_verify_paths().cafile may return None depending on where the platform the packaging is performed on.

On Ubuntu 14 and Ubuntu 16, the ssl.get_default_verify_paths().cafile returns None, which means there are no cacert package in the Linux CLI executable. When this CLI executable is ran on other flavour of Linux (i.e. CoreOS), the HTTPS url access will fail due to SSL cert validation error.

By importing certifi, the cacert will be included as part of the certifi, and the certifi's cacert is used when the CLI is ran as native executable.

The pip3 install of the CLI will retain its default behaviour, i.e. rely on the cacert supplied by default on the machine's Python 3.

[fsat]

MacOS test instructions

If you'd like to help us test on MacOS, would you perform the following please?

Execute the following to force the sudo password prompt.

sudo ls

Download the attached .zip file and then extract it to a directory.

conductr-cli-certifi-MacOS.zip

In the zip file's extracted directory run the following commands please - you can simply copy and paste the commands below. Note the ./ in front of the command - ensure this is present to execute the extracted native executable.

echo "Remove ESLite from Cache"
rm ~/.conductr/cache/bundle/eslite*.zip

echo "Starting Sandbox"
./sandbox run 2.1.0-alpha.1

echo "Visualizer from Cache"
rm ~/.conductr/cache/bundle/visualizer*.zip

echo "Loading Visualizer to Sandbox"
./conduct load visualizer

echo "Stopping Sandbox"
./sandbox stop

echo "Success"

[fsat]

Manual test is done with successful result on master0 machine provisioned by @bwmcadams.

Prior this change, the CLI fails to obtain ESLite from Bintray with error message Error: Bundle not found: Unable to resolve bundle using eslite.

After this change, the ESLite can be obtained from Bintray without any issue. The last error displayed on the output was due to intentional --host foo input to prevent the bundle from actually being loaded.

lightbend@master0 ~/tmp $ rm ~/.conductr/cache/bundle/eslite*

lightbend@master0 ~/tmp $ ./conduct load eslite --host foo
Retrieving bundle..
Loading bundle from cache typesafe/bundle/eslite
Bintray credentials loaded from /home/lightbend/.lightbend/commercial.credentials
Retrieving file:///home/lightbend/tmp/eslite
Resolving bundle typesafe/bundle/eslite
Bintray credentials loaded from /home/lightbend/.lightbend/commercial.credentials
Retrieving https://dl.bintray.com/typesafe/bundle/typesafe/eslite/v1-7dc78f8c80474dc7ff4cabbdf5b5ce386cdebc3bd52693601bd2383dfb4e86be/eslite-v1-7dc78f8c80474dc7ff4cabbdf5b5ce386cdebc3bd52693601bd2383dfb4e86be.zip
[#################################################] 100%
Loading bundle to ConductR..
Error: Unable to contact ConductR.
Error: Reason: HTTPConnectionPool(host='foo', port=9005): Max retries exceeded with url: /v2/bundles (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f2baff56cf8>: Failed to establish a new connection: [Errno -2] Name or service not known',))
Error: Make sure it can be accessed at http://foo:9005/v2/bundles

[fsat]

I've also performed a manual test on the package built on OSX, and it's working as expected.

Looking at the archive content, the cacert.pem is included as part of the archive:

Felixs-MBP-2:conductr-cli felixsatyaputra$ pyi-archive_viewer dist/conduct | grep certifi/cacert.pem
 (3829585, 174092, 321422, 1, 'x', 'certifi/cacert.pem'),