gpg keys

GPG Key Migration


packagecloud is changing the way certain older repositories have their metadata signed with GPG keys. Only a small set of repositories on packagecloud with Debian and RPM packages are affected. All other repositories do not need migration. Any unmigrated repositories will be automatically migrated by our system on January 7, 2019.

You can see which repositories of yours are affected by logging in to and checking your list of repositories for the “migrate GPG key” icon.

In this post, we’ll explain what this means, the consequences for repository owners and users, and how to migrate.

Why are some repository GPG keys being migrated?

In the early days of, our system used a global GPG key to sign repository metadata. As we grew, we began generating GPG keys for each repository created on packagecloud.

The time has come for older repositories which use the global GPG key to be migrated to GPG keys generated specifically for that repository.

Any repositories which have not been migrated by January 7, 2019 will be automatically migrated by our system.

We recommend repository owners perform the migration themselves to minimize any possibly confusing error messages that their users may see from tools like APT or YUM.


Repository owners: How can I tell if my repositories are affected?

All affected users have received an email listing all affected repositories associated with their account.

You can double check if your repositories are affected by logging into and looking at your repository list. Any repositories that must be migrated will display a badge to the right of the repository name. Click this badge to be taken to a page with more information about the GPG key migration.

Here’s an example of what this looks like:

Screenshot of GPG migrate badge

Please note: this is only visible to respository owners and collaborators.

As you can see in the screen shot above, only repository1 is affected, since it has the “migrate gpg key” badge. repository2 is fine as is.

Clicking the “migrate gpg key” badge will bring you to a detailed GPG migration page for the affected repository.


Repository owners: How can I migrate my repository to the new signing key?

Only repositories with the “migrate gpg key” badge displayed next to their name on the repository page must be migrated. All other repositories are fine as is. Check the screenshot provided in the previous section to see what this looks like.

If you are the owner of a repository that needs to be migrated, you have two options depending on how the repository is being used.

  1. The simplest option: click the migrate button to migrate the GPG key. Re-run the installation scripts on your systems (or ask your users to do the same). This will automatically import the correct key. The downside to this method is that any user who runs apt-get update or yum update after the GPG key has been migrated, but before they have reinstalled the repository will get a warning from APT and/or YUM. This warning will occur because the package manager will see that the repository is signed with a new key, but that new key has not been imported yet. This option may be fine for folks who control their own infrastructure who can simply import the key before re-running their configuration management solutions.

  2. A more complex, but smoother option: include a post-install script in the next version of your package to import the new GPG key. Once your users have downloaded this new package, you can then click the migrate button to migrate the GPG key. This will prevent users from getting cryptic error messages from APT and/or YUM as the new key will already be imported when APT and/or YUM run.

More details about each of these methods is available to repositories owners on the GPG migration page for their repository. Simply log in to and click the “migrate gpg key” badge to be taken to the GPG migration page with more information.


Repository users: Why am I getting GPG errors from a repository?

As a repository user you may get GPG errors from a repository that has had its GPG key migrated if you have not imported the new key.

A common error message for this from APT looks like this:

W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: xenial Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 888B8661C90E7829

A common error message for this from YUM looks like this: [Errno -1] repomd.xml signature could not be verified for username_repositoryname

failure: repodata/repomd.xml from username_repositoryname: [Errno 256] No more mirrors to try.

Both error messages are saying the same thing: the repository’s metadata was signed with a new GPG key that your system does not have imported yet.

Since your system does not have the new key the package manager (APT or YUM) cannot verify the signature on the metadata. Read the next section for more information on how to fix this.


Repository users: How can I fix the GPG errors from a repository?

If you are using a repository and receiving GPG errors, you can quickly and easily fix them by re-running the install script for the repository. Simply go to the repository page, click the install tab, and follow the directions for reinstalling the repository.

If you’d to like resolve this issue manually instead of re-running the install process:

  • For APT repositories: Use apt-key to import the repository’s new GPG key. Be sure to substitute the user and repository in this example before running it: curl -L | apt-key add -. You will need to be root to run this command.

  • For YUM repositories: check your repository’s yum configuration (located in /etc/yum.repos.d/username_repositoryname.repo) and ensure that all lines which start with gpgkey= are set to the URL Simply run yum makecache and the new GPG key will be automatically downloaded and imported.

Need help?

As always, if you have any questions or need any help feel free to reach out to us:

You might also like other posts...