#pinentry — Public Fediverse posts

Me and my new #yubikey5 part 2:

Now we get to the nitty-gritty parts. I'm using #mbsync to sync multiple #imap accounts to local #maildir and I am automating this via #systemd : a timer calls a service very 5 minutes, that will call mbsync on all mail accounts if connected to the internet.

Providing the passwords via #pass that is encrypted with #yubikey will need that yubikey to be unlocked (i.e. a pin needs to be provided). When providing this pin (e.g. by manually calling mbsync on one of my mail accounts), it will be stored for at least 12h, and up to 24h (on my home pc; mobile and remote devices will of course hav different settings).

However, if I never manually provide the PIN, the systemd automated scripts will fail. E.g. I just connected the key, but not used it.

First I thought, this was due to me using the `curses` version #pinentry . But that's not the whole truth. Even with `pinentry-gtk` the systemd script will not trigger a PIN entry. I didn't quite understand why, and therefore ran a different direction:

Could I just auto-unlock the yubikey if I connected it? I wrote a #udev rule that would recognize the yubikey. Learning that I need to put scripts for udev in certain dirs, and being unhappy with it, I then wrote a systemd service for the udev to call instead, and with that I maanged to finally get a PIN entry request using the gtk version.

And then it got me thinking. Why did that work, but my mailsync that basically has the same things involved (script instead of udev that triggers systemd that wants to decrypt something using yubikey triggering PIN entry). And then it hit me: My mailsync systemd service was missing the `DISPLAY=:0` environment variable, thus the script can't trigger the GUI. Half a days worth of work, all for nothing :picardfacepalm:

But hey, the weekend is young. Next up: If triggered via CLI i want gpg to trigger `pinentry-curses` instead of `pinentry-gtk`. Sounds easy: have a `pinentry-auto` script figuring out where it has been called from. Well... not really #wip

Me and my new #yubikey5 part 2:

Now we get to the nitty-gritty parts. I'm using #mbsync to sync multiple #imap accounts to local #maildir and I am automating this via #systemd : a timer calls a service very 5 minutes, that will call mbsync on all mail accounts if connected to the internet.

Providing the passwords via #pass that is encrypted with #yubikey will need that yubikey to be unlocked (i.e. a pin needs to be provided). When providing this pin (e.g. by manually calling mbsync on one of my mail accounts), it will be stored for at least 12h, and up to 24h (on my home pc; mobile and remote devices will of course hav different settings).

However, if I never manually provide the PIN, the systemd automated scripts will fail. E.g. I just connected the key, but not used it.

First I thought, this was due to me using the `curses` version #pinentry . But that's not the whole truth. Even with `pinentry-gtk` the systemd script will not trigger a PIN entry. I didn't quite understand why, and therefore ran a different direction:

Could I just auto-unlock the yubikey if I connected it? I wrote a #udev rule that would recognize the yubikey. Learning that I need to put scripts for udev in certain dirs, and being unhappy with it, I then wrote a systemd service for the udev to call instead, and with that I maanged to finally get a PIN entry request using the gtk version.

And then it got me thinking. Why did that work, but my mailsync that basically has the same things involved (script instead of udev that triggers systemd that wants to decrypt something using yubikey triggering PIN entry). And then it hit me: My mailsync systemd service was missing the `DISPLAY=:0` environment variable, thus the script can't trigger the GUI. Half a days worth of work, all for nothing :picardfacepalm:

But hey, the weekend is young. Next up: If triggered via CLI i want gpg to trigger `pinentry-curses` instead of `pinentry-gtk`. Sounds easy: have a `pinentry-auto` script figuring out where it has been called from. Well... not really #wip

Updated my old blogpost about common configuration bits in my Emacs configuration — added an update about pain in the ass^W^W^W^Wpinentry and TRAMP configuration

https://eugene-andrienko.com/it/2025/06/30/my-emacs-configuration-common.html

#Emacs #TRAMP #pinentry

Updated my old blogpost about common configuration bits in my Emacs configuration — added an update about pain in the ass^W^W^W^Wpinentry and TRAMP configuration

https://eugene-andrienko.com/it/2025/06/30/my-emacs-configuration-common.html

#Emacs #TRAMP #pinentry

Updated my old blogpost about common configuration bits in my Emacs configuration — added an update about pain in the ass^W^W^W^Wpinentry and TRAMP configuration

https://eugene-andrienko.com/it/2025/06/30/my-emacs-configuration-common.html

#Emacs #TRAMP #pinentry

Updated my old blogpost about common configuration bits in my Emacs configuration — added an update about pain in the ass^W^W^W^Wpinentry and TRAMP configuration

https://eugene-andrienko.com/it/2025/06/30/my-emacs-configuration-common.html

#Emacs #TRAMP #pinentry

Updated my old blogpost about common configuration bits in my Emacs configuration — added an update about pain in the ass^W^W^W^Wpinentry and TRAMP configuration

https://eugene-andrienko.com/it/2025/06/30/my-emacs-configuration-common.html

#Emacs #TRAMP #pinentry

Why is it so hard to implement a way to smartly determine whether to use a graphical #pinentry (like pinentry-kwallet for #KDE/#Kwallet users) when you're using a desktop graphically, or fallback to a terminal-based pinentry when it should know if you cannot respond to a graphical prompt i.e. when you're in an SSH connection.

I've been trying to achieve this for so long, in so many different ways and nothing seems to work - nothing not too janky to maintain that is. How do you do this on #Linux (specifically #ArchLinux though it shouldn't matter)? This honestly should be the default behaviour cos I couldn't think of a situation where this behaviour I'm expecting isn't the most sensible.

Why is it so hard to implement a way to smartly determine whether to use a graphical #pinentry (like pinentry-kwallet for #KDE/#Kwallet users) when you're using a desktop graphically, or fallback to a terminal-based pinentry when it should know if you cannot respond to a graphical prompt i.e. when you're in an SSH connection.

I've been trying to achieve this for so long, in so many different ways and nothing seems to work - nothing not too janky to maintain that is. How do you do this on #Linux (specifically #ArchLinux though it shouldn't matter)? This honestly should be the default behaviour cos I couldn't think of a situation where this behaviour I'm expecting isn't the most sensible.

Why is it so hard to implement a way to smartly determine whether to use a graphical #pinentry (like pinentry-kwallet for #KDE/#Kwallet users) when you're using a desktop graphically, or fallback to a terminal-based pinentry when it should know if you cannot respond to a graphical prompt i.e. when you're in an SSH connection.

I've been trying to achieve this for so long, in so many different ways and nothing seems to work - nothing not too janky to maintain that is. How do you do this on #Linux (specifically #ArchLinux though it shouldn't matter)? This honestly should be the default behaviour cos I couldn't think of a situation where this behaviour I'm expecting isn't the most sensible.

Why is it so hard to implement a way to smartly determine whether to use a graphical #pinentry (like pinentry-kwallet for #KDE/#Kwallet users) when you're using a desktop graphically, or fallback to a terminal-based pinentry when it should know if you cannot respond to a graphical prompt i.e. when you're in an SSH connection.

I've been trying to achieve this for so long, in so many different ways and nothing seems to work - nothing not too janky to maintain that is. How do you do this on #Linux (specifically #ArchLinux though it shouldn't matter)? This honestly should be the default behaviour cos I couldn't think of a situation where this behaviour I'm expecting isn't the most sensible.

Why is it so hard to implement a way to smartly determine whether to use a graphical #pinentry (like pinentry-kwallet for #KDE/#Kwallet users) when you're using a desktop graphically, or fallback to a terminal-based pinentry when it should know if you cannot respond to a graphical prompt i.e. when you're in an SSH connection.

I've been trying to achieve this for so long, in so many different ways and nothing seems to work - nothing not too janky to maintain that is. How do you do this on #Linux (specifically #ArchLinux though it shouldn't matter)? This honestly should be the default behaviour cos I couldn't think of a situation where this behaviour I'm expecting isn't the most sensible.

Persuaded #gnupg and #pinentry to as for the pin in the console.

Now the test automation for the #securitykeys can continue. 👍

Persuaded #gnupg and #pinentry to as for the pin in the console.

Now the test automation for the #securitykeys can continue. 👍

Persuaded #gnupg and #pinentry to as for the pin in the console.

Now the test automation for the #securitykeys can continue. 👍

Persuaded #gnupg and #pinentry to as for the pin in the console.

Now the test automation for the #securitykeys can continue. 👍

I am currently testing with #gnupg and #securitykeys

Automating the gnupg key generation for test purposes got me stuck. It seems on my #linuxmint gnupg refuses to request the #pinentry from the terminal. Instead it opens a GUI window.

Little side project: figuring out how to force #gnupg to ask for #pinentry in the terminal !?!?

I am currently testing with #gnupg and #securitykeys

Automating the gnupg key generation for test purposes got me stuck. It seems on my #linuxmint gnupg refuses to request the #pinentry from the terminal. Instead it opens a GUI window.

Little side project: figuring out how to force #gnupg to ask for #pinentry in the terminal !?!?

I am currently testing with #gnupg and #securitykeys

Automating the gnupg key generation for test purposes got me stuck. It seems on my #linuxmint gnupg refuses to request the #pinentry from the terminal. Instead it opens a GUI window.

Little side project: figuring out how to force #gnupg to ask for #pinentry in the terminal !?!?

I am currently testing with #gnupg and #securitykeys

Automating the gnupg key generation for test purposes got me stuck. It seems on my #linuxmint gnupg refuses to request the #pinentry from the terminal. Instead it opens a GUI window.

Little side project: figuring out how to force #gnupg to ask for #pinentry in the terminal !?!?