Skip to content

Ensure a smoother GPG key update process for September 2026 expiration #9572

@williammartin

Description

@williammartin

Description

In #9569, we detail the expiration of the GPG key used to sign our .deb and .rpm package repository contents. With the late notice, we were limited in the options available to us, choosing to extend the expiration date of the existing key. Unfortunately, all our users need to obtain this new key through some mechanism, and this is likely to be an inconvenient process for many.

In #6856 there was a suggested approach to avoiding this issue in the future by packaging the key inside the .deb, so that as users updated their version of the CLI, with enough advanced notice, they would hopefully already have the new key long before their expiration. Another approach discussed internally is to package the key separately and to make that a dependency of gh. Thus, as users ran apt update, with enough advanced notice, they would hopefully already have the new key long before their expiration.

The approaches above were primarily focused on our .deb repository. We should ensure that any solution is also relevant for our .rpm repository.

We should decide an approach to follow up on fairly quickly, such that this doesn't get lost through team changes or in the myriad other work.

If anyone in the community has experience with managing GPG keys for self-hosted repositories, we'd love to hear from you on this issue.

Expected Output

The expected output of this issue is:

  • A document in this repository outlining the options and recommending one
  • A comment closing out this issue pointing to that document
  • A new issue in this repository capturing the recommended work

Metadata

Metadata

Assignees

Labels

feedbacktech-debtA chore that addresses technical debt

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions