fix: add PAM integration for GPG passphrase persistence across reboots - #874
Conversation
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
|
You do not have enough credits to review this pull request. Please purchase more credits to continue. |
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 resolves an issue where GPG passphrases were not persisting across reboots, leading to a locked GNOME Keyring. By integrating GNOME Keyring with the system's PAM services and updating the pinentry mechanism, the changes ensure that GPG passphrases are automatically unlocked and available upon login, significantly improving the user experience for GPG operations. Highlights
Changelog
Activity
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
|
Mesa DescriptionTL;DRFixes GPG passphrase persistence across reboots by integrating PAM with GNOME Keyring for auto-unlock on login via What changed?
Description generated by Mesa. Update settings |
📝 WalkthroughWalkthroughEnables Docker virtualization, adds PAM greetd integration to auto-unlock GNOME Keyring, switches GPG pinentry from tty to gnome3, and adds the GNOME Keyring service (components = ["secrets"]) in two insertion points of the host configuration. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant greetd
participant PAM
participant GNOMEKeyring as "gnome-keyring (secrets)"
participant GPGAgent as "gpg-agent (pinentry-gnome3)"
User->>greetd: Login request
greetd->>PAM: hand off authentication
PAM->>GNOMEKeyring: unlock keyring (enableGnomeKeyring)
GNOMEKeyring->>GPGAgent: provide cached passphrase to gpg-agent
GPGAgent-->>User: GPG operations use unlocked keyring via pinentry-gnome3
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![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 the current code and only fix it if needed.
Inline comments:
In `@named-hosts/matic/default.nix`:
- Line 402: The pinentry choice (pinentry.package = pkgs.pinentry-gnome3) will
silently fall back to curses on Hyprland unless org.gnome.keyring.SystemPrompter
is provided by gcr; update the configuration to ensure pkgs.gcr is installed
(e.g., add pkgs.gcr to home.packages) so pinentry-gnome3 can use the Gcr
SystemPrompter and GPG passphrase persistence works as intended.
There was a problem hiding this comment.
Pull request overview
Adds system/login integration needed to have GNOME Keyring unlocked via greetd so GPG passphrases can be retrieved after reboot.
Changes:
- Enable PAM GNOME Keyring integration for the
greetdservice - Switch GPG pinentry to
pinentry-gnome3 - Enable GNOME Keyring Secret Service component
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| services.gnome-keyring = { | ||
| enable = true; | ||
| components = [ "secrets" ]; | ||
| }; |
There was a problem hiding this comment.
services.gnome-keyring is typically a Home Manager option; on NixOS the GNOME Keyring module is usually namespaced under services.gnome.gnome-keyring. As written, this is likely to fail Nix evaluation with an “option does not exist” error; switch to the NixOS option path (or move this block into the Home Manager user config if that’s the intended scope).
| enable = true; | ||
| enableSshSupport = false; | ||
| pinentry.package = pkgs.pinentry-tty; | ||
| pinentry.package = pkgs.pinentry-gnome3; |
There was a problem hiding this comment.
If this services.gpg-agent block is from Home Manager, the pinentry option is commonly services.gpg-agent.pinentryPackage, not a nested pinentry.package. Since this line is being edited, it’s a good point to align with the module’s expected option name to avoid an unknown-option evaluation failure.
| pinentry.package = pkgs.pinentry-gnome3; | |
| pinentryPackage = pkgs.pinentry-gnome3; |
|
|
||
| security.sudo.wheelNeedsPassword = false; | ||
|
|
||
| # PAM integration for GNOME Keyring auto-unlock on login |
There was a problem hiding this comment.
Consider extending the comment to capture the key assumption for auto-unlock: PAM can only unlock the login keyring when a secret is available from the authentication flow (typically a password-based login). This helps future readers understand why this might not work with passwordless/auto-login greetd setups.
| # PAM integration for GNOME Keyring auto-unlock on login | |
| # PAM integration for GNOME Keyring auto-unlock on login. | |
| # Note: PAM can only unlock the login keyring when a secret is available | |
| # from the authentication flow (typically a password-based login). With | |
| # passwordless or auto-login greetd setups, no such secret may be provided, | |
| # so auto-unlock of the GNOME Keyring might not work as expected. |
![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 integrates GNOME Keyring with greetd and gpg-agent to ensure GPG passphrases persist across reboots. The changes are logical and well-implemented, enabling PAM to unlock the keyring on login and switching to the appropriate pinentry program. I've suggested a small improvement to also leverage the keyring for SSH agent functionality, which would create a more consistent setup for managing secrets.
| # GNOME Keyring for persistent GPG passphrase storage across reboots | ||
| services.gnome-keyring = { | ||
| enable = true; | ||
| components = [ "secrets" ]; |
There was a problem hiding this comment.
Since you're enabling the GNOME Keyring for GPG, you could also leverage it for SSH agent functionality. By adding the ssh component, your SSH key passphrases can also be stored in the keyring and unlocked automatically on login. This would provide a consistent experience for both GPG and SSH, and is a common practice when using gnome-keyring.
components = [ "secrets" "ssh" ];
There was a problem hiding this comment.
🧹 Nitpick comments (1)
named-hosts/matic/default.nix (1)
60-73: Consider rootless Docker to avoid thedockergroup's root-equivalent privilege.The NixOS wiki explicitly warns that docker group membership is effectively equivalent to being root. While this host already grants passwordless sudo (line 75), rootless mode still limits daemon attack surface and is better hygiene.
Rootless Docker can be activated with
virtualisation.docker.rootless = { enable = true; setSocketVariable = true; };— thesetSocketVariableflag automatically pointsDOCKER_HOSTto the per-user socket, so no group membership is required.♻️ Proposed refactor to rootless Docker
- # Docker - virtualisation.docker.enable = true; + # Docker (rootless — no docker group membership required) + virtualisation.docker.rootless = { + enable = true; + setSocketVariable = true; + };And remove the
dockergroup fromextraGroups:extraGroups = [ "wheel" "networkmanager" "input" "video" - "docker" ];🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@named-hosts/matic/default.nix` around lines 60 - 73, Remove the privileged "docker" group membership from the user's extraGroups and enable rootless Docker by replacing/augmenting the current virtualisation.docker.enable setting: set virtualisation.docker.rootless = { enable = true; setSocketVariable = true; } so the per-user daemon/socket is used and DOCKER_HOST is automatically configured; keep virtualisation.docker.enable as needed for system-wide service settings or disable it if you want purely rootless operation (adjust any passwordless sudo expectations accordingly).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@named-hosts/matic/default.nix`:
- Line 406: pinentry-gnome3 can silently fall back to curses on Hyprland unless
org.gnome.keyring.SystemPrompter (provided by pkgs.gcr) is present, so ensure
pkgs.gcr is installed alongside pkgs.pinentry-gnome3; update the nix expression
that sets pinentry.package (the symbol pinentry.package and
pkgs.pinentry-gnome3) to also add pkgs.gcr to the target environment (for
example include pkgs.gcr in environment.systemPackages or the relevant
Hyprland-specific package list) so gcr is available and pinentry-gnome3 will use
the GUI prompter instead of falling back to curses.
---
Nitpick comments:
In `@named-hosts/matic/default.nix`:
- Around line 60-73: Remove the privileged "docker" group membership from the
user's extraGroups and enable rootless Docker by replacing/augmenting the
current virtualisation.docker.enable setting: set virtualisation.docker.rootless
= { enable = true; setSocketVariable = true; } so the per-user daemon/socket is
used and DOCKER_HOST is automatically configured; keep
virtualisation.docker.enable as needed for system-wide service settings or
disable it if you want purely rootless operation (adjust any passwordless sudo
expectations accordingly).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![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 (changes from recent commits).
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">
P2: pinentry-tty only prompts on a controlling TTY, so GUI apps in this Hyprland session won’t be able to unlock keys and GPG prompts will fail. Use a GUI pinentry (e.g., pinentry-gnome3) for a graphical login.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| @@ -62,12 +62,16 @@ inputs.nixpkgs.lib.nixosSystem { | |||
| "networkmanager" | |||
There was a problem hiding this comment.
P2: pinentry-tty only prompts on a controlling TTY, so GUI apps in this Hyprland session won’t be able to unlock keys and GPG prompts will fail. Use a GUI pinentry (e.g., pinentry-gnome3) for a graphical login.
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 403:
<comment>pinentry-tty only prompts on a controlling TTY, so GUI apps in this Hyprland session won’t be able to unlock keys and GPG prompts will fail. Use a GUI pinentry (e.g., pinentry-gnome3) for a graphical login.</comment>
<file context>
@@ -403,17 +400,11 @@ inputs.nixpkgs.lib.nixosSystem {
enable = true;
enableSshSupport = false;
- pinentry.package = pkgs.pinentry-gnome3;
+ pinentry.package = pkgs.pinentry-tty;
defaultCacheTtl = 94608000; # 3 years
maxCacheTtl = 94608000; # 3 years
</file context>
| "networkmanager" | |
| pinentry.package = pkgs.pinentry-gnome3; |
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:
https://claude.ai/code/session_01MoWYgtw2oTthtJLLZFHqTo
Summary by cubic
Ensures GPG passphrases persist across reboots by auto-unlocking GNOME Keyring on greetd login and integrating gpg-agent with GNOME pinentry.
Bug Fixes
New Features
Written for commit 5fec16d. Summary will update on new commits.