Current setup of gpgcheck in redhat package is insecure

[XANi]

in manifests/package/redhat.pp there is a gpg key( http://nginx.org/keys/nginx_signing.key ) that:

• is downloaded from same server that is hosting the packages. So if attacker get access to it they can just replace that key with their own
• is downloaded over http which makes MITM attacks trivial

[3flex]

Hi @XANi. Agreed, this isn't ideal. Unfortunately I don't know of any way to specify the actual key that should be used if we use the yumrepo provider. It only provides the gpgkey parameter which is "The URL for the GPG key", but you can't set the key itself like with the puppetlabs-apt provider.

Any suggestions on how to improve this? The nginx key is not available via HTTPS when using nginx.org, is there another source we can use?

[XANi]

I think a good compromise would be adding an option for user to specify path to nginx key and let them do key management if they want to.

It only provides the gpgkey parameter which is "The URL for the GPG key",

It can also specify file on disk

In our internal puppet repo we just include key with our repo like that

this works well for private repo (as we control what goes in) but of course for public module is suboptimal (but imo a bit better than serving key over http).

[geerlingguy]

FYI we're looking into solving this problem in a similar Ansible role using some extra tasks to do the rpm checks: geerlingguy/ansible-role-nginx#26

[wyardley]

Since the signing key is unlikely to change often, maybe this could just be hard-coded as a file in the module itself? This may be somewhat less important with #914, since this will no longer be the default setting, but I agree that this doesn't seem like a great practice.

[XANi]

I'd set is as variable that defaults to key file inside the nginx module. That way in unlikely event that key changes it would be trivial to change it without touching nginx module code.

[wyardley]

I understand the reasons why the current setup is not ideal (for Apt, FWIW, it is possible to pull from MIT keyserver; not sure if that option is better), but spoke with @hunner at the community modules team today, and does sound like pulling the key from a site, even if it's the same site, is pretty standard practice currently w/ modules.

As far as the key expiration thing, it seems like Apt already has something to handle this, but maybe not Yum; this is something that maybe we should file as a bug against the Yum provider if it's not already (I'll try and search). Given all that, I'm going to close this one for now, though we can still have more discussion about it if wanted.