Secure Package Installation

[mike-stewart]

Description

Fixes /issues/578. This secures the package installation against MITM attacks for linux by downloading the GPG key over HTTPS.

I didn't change the linux repo URLs themselves as there is generally less benefit in downloading the packages over HTTPS given GPG checks. It requires an additional package in some cases, and it can get in the way of caching.

For Windows, I changed the package URL, as I'm not aware of a method to check package signatures there.

Motivation and Context

See #578.

How Has This Been Tested?

Executed tests.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.

[majormoses]

👍 we really needed to do this! However as per my comment in #594 we need to install apt-transport-https on debian based installs to avoid a breaking change.

[majormoses]

I can fix it up post acceptance but you should use a ### Security header for security changes.

We follow the same changelog guidelines as here and if you are curious on how we version security changes you can read about it here

[majormoses]

we need to install this not remove it.

[mike-stewart]

Sorry - this was a test commit, just trying to validate an assumption on the Travis build.

[majormoses]

ok, no problem if it is a wip then it's best to label the PR title with [WIP]

[majormoses]

Also sadly we never added travis and kitchen integration. It's something I want to add when I have the time.

[mike-stewart]

@majormoses We shouldn't actually need to install apt-transport-https here - as I mentioned in the description of the PR the difference is that we're not installing the package itself over HTTPS, we're just fetching the GPG key. The package can be downloaded securely over HTTP if it's signed with a GPG key that we can trust.

I've confirmed this through a manual test on Ubuntu 16.04. With apt-transport-https not installed, I can fetch the key over HTTPS, add the repo, and install the package.

Let me know if this makes sense. I can dig into the test suite more later to try to prove this if necessary.

[majormoses]

@mike-stewart gotcha I read the title and the code and after seeing #594 I assumed it was the same deal. 👍 on merging whether we switch over later and agree that a pgp signed artifact is good enough if you download the key over https/ssl. One concern I have about eventually needing to support it down the road is that at some overzealous admin might redirect http -> https. But we can worry about that later.

Let me know if this makes sense. I can dig into the test suite more later to try to prove this if necessary.

Nope I got you, I will run it through the test suites this weekend and if it looks good I will merge and release this before monday.

I won't pretend to know much about windows but from what I read we should be good to use https.

[mike-stewart]

Sounds great. I hadn't noticed #594, but that would have some advantages as well. I decided to go with the least change required to get good security.

From what I've read about apt, it's typically best from a compatibility perspective to allow package download over HTTP, as that doesn't break environments that use caching proxies for distributing packages.

[majormoses]

Validated this looks good with linux, the windows vagrant failed because of other reasons:

---- Begin output of vagrant up --no-provision --provider virtualbox ----
STDOUT: Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'mwrock/Windows2012R2' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
STDERR: The box 'mwrock/Windows2012R2' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: ["https://atlas.hashicorp.com/mwrock/Windows2012R2"]
Error: The requested URL returned error: 404 Not Found

I say

[majormoses]

released: https://supermarket.chef.io/cookbooks/sensu/versions/4.2.1