Skip to content

feat: plugin informing *why* touch is needed - #84

Draft
tobixen wants to merge 1 commit into
max-baz:mainfrom
tobixen:feature/gpg-context-notify-plugin
Draft

feat: plugin informing *why* touch is needed#84
tobixen wants to merge 1 commit into
max-baz:mainfrom
tobixen:feature/gpg-context-notify-plugin

Conversation

@tobixen

@tobixen tobixen commented Jun 4, 2026

Copy link
Copy Markdown

This superceded #82.

Adds a plugin to a new contrib directory. "Draft" because it's AI-generated code that has neither been reviewed nor tested thoroghly yet. It's also an open question if this should be distributed in a contrib-folder, as a stand-alone project or in a different way.

Reimplements the process-context detection from PR max-baz#82
(max-baz#82) as an external
plugin, per the maintainer's suggestion, instead of patching the core app.

The plugin listens on the detector's existing Unix socket
($XDG_RUNTIME_DIR/yubikey-touch-detector.socket) and, on a GPG_1 event, traces
the gpg-agent connection via `ss -xpn` + peer-inode matching to identify the
calling process, then shows it with `notify-send`. No detector changes needed.

- Ports the ss/gpgconf/proc tracing logic to Python with unit tests.
- Excludes gpg-agent, scdaemon and the detector itself (the latter only
  catchable via /proc cmdline basename, since ss reports the 15-char-truncated
  comm "yubikey-touch-d").
- Includes a single replaceable notification with a post-touch banner, a
  systemd user unit, and a README documenting scope/limitations.

prompt: please look into the pull request comments. I'm advised to rewrite the patch into a plugin.
followup-prompt: (decisions) plugin form = Python script; branch = new branch, keep the original

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
@max-baz

max-baz commented Jun 4, 2026

Copy link
Copy Markdown
Owner

Awesome! This is exactly the dream scenario for this project, to enable people to build cool and personalized stuff on top!

I know people used wiki to share tips & snippets, but maybe this code is a bit too much to share via wiki? At the same time LLMs are known to blow the code up, it's quite possible that the same can be achieved in much fewer lines of code if you press it hard enough 😂 In any case, I'm happy to share feedback while you are still developing and testing it, but in the end I don't think I should play the gatekeeper role, I think it would be better if you put the final version into a standalone repo, and if you want link to it from the wiki in this project?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants