feat(matic): persist GPG passphrase across reboots - #844
Conversation
Switch pinentry from tty to gnome3 and enable GNOME Keyring secrets component so the GPG signing passphrase survives reboots.
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing touches🧪 Generate unit tests (beta)
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 |
Summary of ChangesHello @shunkakinoki, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the user experience for GPG signing by implementing persistent storage for passphrases. By integrating GNOME Keyring, users will no longer need to re-enter their GPG passphrase after a reboot, streamlining the signing workflow and improving convenience. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
You do not have enough credits to review this pull request. Please purchase more credits to continue. |
Mesa DescriptionTL;DRSwitch What changed?
Description generated by Mesa. Update settings |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly configures gpg-agent with pinentry-gnome3 and enables services.gnome-keyring to persist the GPG passphrase across reboots. The changes are logical and well-contained. I have one suggestion to ensure the GNOME Keyring is automatically unlocked upon login, which will provide a more seamless experience and align with the goal of automatic passphrase retrieval.
| services.gnome-keyring = { | ||
| enable = true; | ||
| components = [ "secrets" ]; | ||
| }; |
There was a problem hiding this comment.
Enabling gnome-keyring is a great step for persisting the GPG passphrase. However, for the keyring to be unlocked automatically on login (and thus for the GPG passphrase to be retrieved without any prompt), you'll also need to configure PAM for greetd.
This requires adding the following to your NixOS system configuration in this file:
security.pam.services.greetd.gnome-keyring.enable = true;Without this, you will likely be prompted for your keyring password the first time a secret is accessed in a new session. This might not match the expectation of the passphrase being retrieved 'automatically' as mentioned in the test plan.
There was a problem hiding this comment.
Pull request overview
Updates the NixOS/Home Manager configuration for the matic host to support GUI pinentry and attempt persistent GPG passphrase storage via GNOME Keyring/libsecret.
Changes:
- Switch GPG agent pinentry from
pinentry-ttytopinentry-gnome3. - Enable Home Manager
services.gnome-keyringwith thesecretscomponent.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| enableSshSupport = false; | ||
| pinentry.package = pkgs.pinentry-tty; | ||
| pinentry.package = pkgs.pinentry-gnome3; | ||
| defaultCacheTtl = 94608000; # 3 years | ||
| maxCacheTtl = 94608000; # 3 years |
There was a problem hiding this comment.
Switching to pkgs.pinentry-gnome3 makes GPG signing depend on a graphical session (DISPLAY/WAYLAND + D-Bus). In pure TTY contexts (e.g., VT, SSH session without GUI forwarding), pinentry-gnome3 will fail to prompt and GPG operations can break. Consider using a pinentry wrapper/fallback (GUI when available, curses/tty otherwise) or keeping pinentry-tty for this host if TTY signing is expected.
| # GNOME Keyring for persistent GPG passphrase storage across reboots | ||
| services.gnome-keyring = { | ||
| enable = true; | ||
| components = [ "secrets" ]; | ||
| }; |
There was a problem hiding this comment.
Enabling Home Manager services.gnome-keyring alone typically won’t auto-unlock the login keyring after reboot; without PAM integration (e.g., security.pam.services.<login-service>.enableGnomeKeyring = true for greetd/login), the first post-reboot signing attempt usually triggers a keyring unlock prompt, so the passphrase won’t be retrieved “automatically” as described. If the goal is truly seamless post-reboot retrieval, add the appropriate NixOS PAM/keyring integration for this host’s greetd login flow.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 1 file
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="named-hosts/matic/default.nix">
<violation number="1" location="named-hosts/matic/default.nix:405">
P2: GNOME Keyring is enabled without enabling the PAM integration for `greetd`, so the keyring stays locked after login and the passphrase won’t auto-unlock across reboots. Configure `security.pam.services.greetd.enableGnomeKeyring = true` alongside this block.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| }; | ||
|
|
||
| # GNOME Keyring for persistent GPG passphrase storage across reboots | ||
| services.gnome-keyring = { |
There was a problem hiding this comment.
P2: GNOME Keyring is enabled without enabling the PAM integration for greetd, so the keyring stays locked after login and the passphrase won’t auto-unlock across reboots. Configure security.pam.services.greetd.enableGnomeKeyring = true alongside this block.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At named-hosts/matic/default.nix, line 405:
<comment>GNOME Keyring is enabled without enabling the PAM integration for `greetd`, so the keyring stays locked after login and the passphrase won’t auto-unlock across reboots. Configure `security.pam.services.greetd.enableGnomeKeyring = true` alongside this block.</comment>
<file context>
@@ -396,11 +396,17 @@ inputs.nixpkgs.lib.nixosSystem {
};
+ # GNOME Keyring for persistent GPG passphrase storage across reboots
+ services.gnome-keyring = {
+ enable = true;
+ components = [ "secrets" ];
</file context>
The original PR #844 was missing the critical PAM integration needed to auto-unlock GNOME Keyring on login via greetd. Without it, the keyring stays locked after reboot and GPG passphrases can't be auto-retrieved. Changes: - Add security.pam.services.greetd.enableGnomeKeyring for auto-unlock - Switch pinentry from tty to gnome3 for keyring integration - Enable GNOME Keyring secrets service for persistent storage https://claude.ai/code/session_01MoWYgtw2oTthtJLLZFHqTo
#874) * fix: add PAM integration for GPG passphrase persistence across reboots The original PR #844 was missing the critical PAM integration needed to auto-unlock GNOME Keyring on login via greetd. Without it, the keyring stays locked after reboot and GPG passphrases can't be auto-retrieved. Changes: - Add security.pam.services.greetd.enableGnomeKeyring for auto-unlock - Switch pinentry from tty to gnome3 for keyring integration - Enable GNOME Keyring secrets service for persistent storage https://claude.ai/code/session_01MoWYgtw2oTthtJLLZFHqTo * chore: update * chore: update * chore: update * fix: enable Docker daemon and group for docker-postgres service Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
Summary
pinentry-ttytopinentry-gnome3for GNOME Keyring (libsecret) integrationservices.gnome-keyringwithsecretscomponent for persistent storageTest plan
sudo nixos-rebuild switchSummary by cubic
Persist the GPG signing passphrase across reboots on matic by switching to pinentry-gnome3 and enabling GNOME Keyring (secrets). Signing prompts can be saved to the keyring and are loaded automatically after reboot.
Written for commit ee36988. Summary will update on new commits.