feat(debian): use explicit, stronger defaults for newly generated repo signing keys#36236
Merged
wxiaoguang merged 5 commits intogo-gitea:mainfrom Jan 1, 2026
Conversation
GiteaBot
added
the
lgtm/need 2
0xMax42
force-pushed
the
feature/improve-debian-registry-key-generation
branch
from
d5d5c42 to
9938866
Compare
delvh
approved these changes
Dec 24, 2025
Member
delvh
left a comment
delvh
left a comment
There was a problem hiding this comment.
LGTM if renaming a user does not break anything.
GiteaBot
added
lgtm/need 1
The username can be renamed, which means that the key can no longer be assigned to the user.
This comment was marked as off-topic.
This comment was marked as off-topic.
Contributor
Author
|
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? |
Member
Yes, if you'd like to that would be very welcome.
Exactly, except it's the PR title + entire description. |
wxiaoguang
reviewed
Jan 1, 2026
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
wxiaoguang
approved these changes
Jan 1, 2026
GiteaBot
added
lgtm/done
zjjhot
added a commit
to zjjhot/gitea
that referenced
this pull request
Jan 5, 2026
* giteaofficial/main: Move assign project when creating pull request to the same database transaction (go-gitea#36244) [skip ci] Updated translations via Crowdin Fix stats bug when syncing release (go-gitea#36285) Fix link/origin referrer and login redirect (go-gitea#36279) Always honor user's choice for "delete branch after merge" (go-gitea#36281) refactor(pprof): use explicit mux instead of DefaultServeMux (go-gitea#36276) improve the compare page (go-gitea#36261) mailer: pass request context to generateAdditionalHeadersForIssue (go-gitea#36274) feat(debian): use explicit, stronger defaults for newly generated repo signing keys (go-gitea#36236) Make "commit statuses" API accept slashes in "ref" (go-gitea#36264) # Conflicts: # templates/base/footer_content.tmpl # templates/base/head_navbar.tmpl
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR updates Debian repository signing key generation to use explicit, stronger defaults and to embed the creation time in the OpenPGP comment 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:Compatibility
Verification
The change was verified by generating a fresh keypair and validating
InReleasesignatures viagpg --verify.Repositories using existing keys continue to work unchanged.
The diff is intentionally small and isolated to key generation only.