Use new gitlab gpg keys for package management

[jkroepke]

Pull Request (PR) description

As document in https://docs.gitlab.com/omnibus/update/package_signatures gitlab gpg keys expire soon and needs to be replace with new one.

The old key is valid until 2020-04-15 while is new keys starts at 2020-04-06.

A release of this module in this time slot should useful to avoid some local breaking changes.

This PR is created at 2020-03-28. I except test failures until 2020-04-06.

[dhoppe]

@jkroepke You also need to cover the RSpec checks for RHEL, since the URL has changed.

[jkroepke]

Unit tests are green now. ITs should work in 3 days.

[baurmatt]

I don't like the fact that we have to wait until the key is active (and the old one is inactive) to merge/release this. What do you think about adding both keys and removing the old one in a couple of days/weeks/months?

[dhoppe]

@baurmatt Just take a look at #333. @dnsmichi explained how to change the configuration manually. It should not be a problem to merge this pull request on time and create a new release.

[dhoppe]

@baurmatt You do not need to reopen this pull request, to trigger an Travis CI build. The result will not change, because GitLab still offers the old GPG key. I already contacted the support via Twitter.

[baurmatt]

@baurmatt You do not need to reopen this pull request, to trigger an Travis CI build. The result will not change, because GitLab still offers the old GPG key. I already contacted the support via Twitter.

Interesting, that explains the failing test ;)

[jkroepke]

Since gitlab is a global team, they should always announce dates with timezones ...

[dnsmichi]

It is hard to track down when things are exactly done, especially when there's a certain chance that assignees change and so will timezones then. I can understand your concerns too, still, not so easy ;)

I'd recommend to follow the infrastructure group for these kind of changes. Luckily everything is developed and discussed in the open :) I just checked in there too, no changes to the issue yet.

https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/9576

[dhoppe]

@JanKoppe You can trigger a rebuild after logging into the Travis CI web interface. I already did that, but there is still an issue regarding CentOS.

[jkroepke]

Looking at

https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/config_file.repo?os=centos&dist=7&source=script

the yum config doesn't need to be change since the gpg key redirects to the new location:

curl -sI https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey | grep Location
Location: https://packages.gitlab.com/gpg.key

See also: 43fa23b

[dhoppe]

@jkroepke I am not sure about this. I think this script will use the old GPG keys:

• E15E78F4 - Expires 2020-04-15
• F27EAB47 - Expires 2020-07-01

I think the packages need to be resigned with the new GPG key:

• 51312F3F - Valid since 2020-03-02

[root@localhost packages]# rpm -qpi gitlab-ce-12.9.2-ce.0.el6.x86_64.rpm
warning: gitlab-ce-12.9.2-ce.0.el6.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID f27eab47: NOKEY
Name        : gitlab-ce                    Relocations: /
Version     : 12.9.2                            Vendor: Omnibus <omnibus@getchef.com>
Release     : ce.0.el6                      Build Date: Tue 31 Mar 2020 06:17:13 PM UTC
Install Date: (not installed)               Build Host: runner-d1f91b99-project-283-concurrent-0
Group       : default                       Source RPM: gitlab-ce-12.9.2-ce.0.el6.src.rpm
Size        : 1739816979                       License: MIT
Signature   : RSA/SHA1, Tue 31 Mar 2020 06:22:59 PM UTC, Key ID 3cfcf9baf27eab47
Packager    : GitLab, Inc. <support@gitlab.com>
URL         : https://about.gitlab.com/
Summary     : GitLab Community Edition (including NGINX, Postgres, Redis)
Description :
GitLab Community Edition (including NGINX, Postgres, Redis)

[jkroepke]

I think the script will use one of the current keys.

Since https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey redirects to
https://packages.gitlab.com/gpg.key which is according to https://docs.gitlab.com/omnibus/update/package_signatures the correct location of the gpg key.

Since we have both two keys configured here it should work with newer packages.