Skip to content

Conversation

@0xMax42
Copy link
Contributor

@0xMax42 0xMax42 commented Dec 23, 2025

This PR updates Debian repository signing key generation to use explicit RSA-4096 defaults and to embed the creation time in the OpenPGP UID for newly created keys.

Rationale

Repository signing keys are typically long-lived. Since there is currently no built-in key rotation mechanism, the initial key parameters effectively persist for years.
At the moment, those parameters are implicitly derived from OpenPGP library defaults, which makes the effective crypto policy indirect and potentially subject to upstream library changes.

This change makes the defaults explicit and slightly more future-proof, without affecting existing repositories.

Changes

For newly generated Debian repository keys only:

  • Add a UTC creation timestamp to the key comment

  • Generate keys with an explicit packet.Config:

    • RSA 4096-bit primary key and encryption subkey
    • SHA-256 as default hash
    • AES-256 as default cipher

Compatibility

  • Existing repository keys stored in the database are not modified
  • Only newly created keys are affected
  • RSA-based keys remain fully compatible with APT and GnuPG
  • No changes to signing logic or repository metadata formats

Verification

The change was verified by generating a fresh keypair and validating InRelease signatures via gpg --verify.
Repositories using existing keys continue to work unchanged.

The diff is intentionally small and isolated to key generation only.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 23, 2025
@github-actions github-actions bot added the modifies/go Pull requests that update Go code label Dec 23, 2025
@0xMax42 0xMax42 force-pushed the feature/improve-debian-registry-key-generation branch from d5d5c42 to 9938866 Compare December 23, 2025 18:42
Copy link
Member

@delvh delvh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if renaming a user does not break anything.

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Dec 24, 2025
@inthesquarehole

This comment was marked as spam.

The username can be renamed, which means that the key can no longer be assigned to the user.
@delvh

This comment was marked as off-topic.

@0xMax42
Copy link
Contributor Author

0xMax42 commented Dec 24, 2025

Should I adjust the PR text above?

If I remember correctly, the title and the first line of the text will be included in a possible merge, correct?

@delvh
Copy link
Member

delvh commented Dec 24, 2025

Should I adjust the PR text above?

Yes, if you'd like to that would be very welcome.

If I remember correctly, the title and the first line of the text will be included in a possible merge, correct?

Exactly, except it's the PR title + entire description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

lgtm/need 1 This PR needs approval from one additional maintainer to be merged. modifies/go Pull requests that update Go code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants