Change Details

I’m using gpg with ssh. I set different timeouts for ssh and non-ssh: max-cache-ttl 0 max-cache-ttl-ssh 600 Now, if I only use non-ssh subkeys I’m asked for the passphrase each time, that’s fine. But as soon as I enter a ssh key, subsequent non-ssh keys keep being cached, I’m not requested for a passphrase until 600 secs have elapsed. It’s as if there were just a global ttl for the entire key, shared by all its subkeys (but I've not tested this with different primary keys, so I can say for sure it's that). I’ve tried setting default-cache-ttl[-ssh] options and also the individual ttls in sshcontrol, but to no avail. environment: gpg (GnuPG) 2.4.3 macOS 13.2 gpg-agent.conf: pinentry-program /opt/homebrew/bin/pinentry-mac enable-ssh-support max-cache-ttl 0 max-cache-ttl-ssh 60 Keys are stored in macOS login keychain, all of them are set to “Confirm before allowing access”. Nevertheless, I have also tested all this in a more vanilla environment with pinentry-tty and no macOS keychain. The behavior is the same in both cases. Everything work as expected except when used in the aforementioned sequence. It seems a serious issue for me. I use ssh all the time (so my ssh ttl is large) and this has been going like that for weeks until I realized, I have secrets encrypted with my non-ssh keys that could have been easily read by any rogue code running in my computer.

I’m using gpg with ssh. I set different timeouts for ssh and non-ssh: max-cache-ttl 0 max-cache-ttl-ssh 600 Now, if I only use non-ssh subkeys I’m asked for the passphrase each time, that’s fine. But as soon as I enter a ssh key, subsequent non-ssh keys keep being cached, I’m not requested for a passphrase until 600 secs have elapsed. It’s as if there were just a global ttl for the entire key, shared by all its subkeys (but I've not tested this with different primary keys, so I can say for sure it's that). I’ve tried setting default-cache-ttl[-ssh] options and also the individual ttls in sshcontrol, but to no avail. environment: gpg (GnuPG) 2.4.3 macOS 13.2 gpg-agent.conf: pinentry-program /opt/homebrew/bin/pinentry-mac enable-ssh-support max-cache-ttl 0 max-cache-ttl-ssh 60 Keys are stored in macOS login keychain, all of them are set to “Confirm before allowing access”. Nevertheless, I have also tested all this in a more vanilla environment with pinentry-tty and no macOS keychain. The behavior is the same in both cases. Everything work as expected except when used in the aforementioned sequence. It seems a serious issue to me. I use ssh all the time (so my ssh ttl is large) and this has been going like that for weeks until I realized, I have secrets encrypted with my non-ssh keys that could have been easily read by any rogue code running in my computer.

I’m using gpg with ssh. I set different timeouts for ssh and non-ssh: max-cache-ttl 0 max-cache-ttl-ssh 600 Now, if I only use non-ssh subkeys I’m asked for the passphrase each time, that’s fine. But as soon as I enter a ssh key, subsequent non-ssh keys keep being cached, I’m not requested for a passphrase until 600 secs have elapsed. It’s as if there were just a global ttl for the entire key, shared by all its subkeys (but I've not tested this with different primary keys, so I can say for sure it's that). I’ve tried setting default-cache-ttl[-ssh] options and also the individual ttls in sshcontrol, but to no avail. environment: gpg (GnuPG) 2.4.3 macOS 13.2 gpg-agent.conf: pinentry-program /opt/homebrew/bin/pinentry-mac enable-ssh-support max-cache-ttl 0 max-cache-ttl-ssh 60 Keys are stored in macOS login keychain, all of them are set to “Confirm before allowing access”. Nevertheless, I have also tested all this in a more vanilla environment with pinentry-tty and no macOS keychain. The behavior is the same in both cases. Everything work as expected except when used in the aforementioned sequence. It seems a serious issue for meto me. I use ssh all the time (so my ssh ttl is large) and this has been going like that for weeks until I realized, I have secrets encrypted with my non-ssh keys that could have been easily read by any rogue code running in my computer.