Maven central deploy gpg expires#3030
Conversation
…' into maven-central-deploy-gpg-expires
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Maven publish workflow adds a new "Check GPG key expiry" step that parses the ChangesGPG Key Expiry Check in CI
Estimated code review effort🎯 2 (Simple) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/maven-publish.yml:
- Around line 28-42: The GPG expiry check in the maven-publish workflow only
matches the “expires:” text from gpg output, so already-expired keys can be
misclassified as having no expiry. Update the expiry parsing logic in this step
to use gpg’s machine-readable --with-colons output, read the expiration from the
sec record’s 7th field, and keep the existing comparison/exit behavior in the
same workflow step.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e02b8827-daa2-424e-b609-56a739a4cc66
📒 Files selected for processing (1)
.github/workflows/maven-publish.yml
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/maven-publish.yml:
- Around line 28-42: The GPG expiry check in the maven-publish workflow only
matches the “expires:” text from gpg output, so already-expired keys can be
misclassified as having no expiry. Update the expiry parsing logic in this step
to use gpg’s machine-readable --with-colons output, read the expiration from the
sec record’s 7th field, and keep the existing comparison/exit behavior in the
same workflow step.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e02b8827-daa2-424e-b609-56a739a4cc66
📒 Files selected for processing (1)
.github/workflows/maven-publish.yml
🛑 Comments failed to post (1)
.github/workflows/maven-publish.yml (1)
28-42: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
gpg --list-secret-keys output "[expired:" vs "[expires:" format and --with-colons sec record field 7 expiration timestamp💡 Result:
In the human-readable output of GPG (e.g., gpg --list-secret-keys), the labels "[expired: YYYY-MM-DD]" and "[expires: YYYY-MM-DD]" indicate the status of the key or subkey [1]. Specifically, "[expired:...]" denotes that the key has already passed its expiration date, while "[expires:...]" indicates a key that is currently valid but set to expire at the specified future date [1]. These labels are part of the user-facing output intended for human readability and are not recommended for automated scripts [2][3]. For automated processing, GnuPG provides the --with-colons option, which outputs data in a stable, machine-parseable format documented in the GnuPG source file doc/DETAILS [4][2][5]. Regarding the --with-colons output format: - The "sec" (or "ssb") record type is used for secret keys and subkeys [6][7]. - Field 7 contains the expiration date [8][9]. - The expiration date in this field is represented either as a numeric timestamp (seconds since the Epoch) or, in some contexts, as an ISO 8601 string (detectable by the presence of the letter 'T') [4][8]. - If the field is empty, it indicates that the key does not expire [8][9]. Because the default human-readable output format is subject to change, scripts should rely exclusively on the --with-colons output for parsing key metadata [2][3].
Citations:
- 1: https://stackoverflow.com/questions/48914338/how-to-get-expiration-date-from-a-gpg-key
- 2: https://www.gnupg.org/documentation/manuals/gnupg24/gpg.1.html
- 3: https://www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html
- 4: https://github.com/gpg/gnupg/blob/f59455d054a79068ebf480cd28f02993c1facf3b/doc/DETAILS
- 5: https://www.gnupg.org/(en)/documentation/manuals/gnupg/GPG-Input-and-Output.html
- 6: https://security.stackexchange.com/questions/162336/where-can-i-find-the-detailed-manual-page-for-gpg-list-secret-keys-output
- 7: https://stackoverflow.com/questions/45362488/parsing-the-gnupg-secret-key-list
- 8: https://github.com/gpg/gnupg/blob/master/doc/DETAILS
- 9: https://dev.gnupg.org/source/gnupg/browse/master/doc/DETAILS;gnupg-2.4.3%241511
Already-expired GPG keys can pass this check.
gpg --list-secret-keyscan emit[expired: YYYY-MM-DD], but this grep only matchesexpires:. When the key is already expired,EXPIRYstays empty and the step reports “no expiry date set,” so the expired key is treated as valid. Parsegpg --with-colonsinstead and read the expiry from thesecrecord’s 7th field.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/maven-publish.yml around lines 28 - 42, The GPG expiry check in the maven-publish workflow only matches the “expires:” text from gpg output, so already-expired keys can be misclassified as having no expiry. Update the expiry parsing logic in this step to use gpg’s machine-readable --with-colons output, read the expiration from the sec record’s 7th field, and keep the existing comparison/exit behavior in the same workflow step.
3 participants
Summary by CodeRabbit