It seems Kgpg can decrypt a file without asking for password. This happened when I encrypt a file, and then try to decrypt it again (shorthly after). But if I restart my computer after encryption I have to write the password to decrypt. My operation was:
vandel@linux-wkck:~> gpg --symmetric -v test.txt [now a kgpg popup opened automatically and asked me to "enter passphrase"]
gpg: using cipher CAST5
gpg: writing to `test.txt.gpg'
vandel@linux-wkck:~> rm test.txt
vandel@linux-wkck:~> gpg -v test.txt.gpg [this decrypted the file without asking for passphrase]
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: original file name='test.txt'
gpg: WARNING: message was not integrity protected
I get the same result if I rightclick test.txt.gpg in Dolphin and select open with Kgpg or “Decrypt/Verify file” with Kleopatra.
Also if I just decrypted a file and entered the password, and then try to decrypt it a second time, I’m not asked to enter the password the second time.
On 2014-05-09 18:16, nrickert wrote:
> Vandel;2642154 Wrote:
>> I don’t have a file with that name, only ~/.gnupg/gpg.conf.
> You can create one. Check the man pages for gpg-agent. According to
> those pages, the default time to remember the key is 600 seconds.
It can be gpg-agent, but both kde and gnome provide their own
password/passphrases agents (seahorse, kleopatra), and you can configure
how much / if they are remembered.
I don’t have the full KDE installed in this laptop, so I can’t check
where it is done exactly.
As far as I know, “seahorse” and “kleopatra” are two very different animals.
In Gnome, “seahorse” replaces gpg-agent, and remembers keys without a time limit. Moreover, you can tell “seahorse” to save the key in the Gnome keyring, in which case it remembers keys across sessions.
In KDE, as best I remember, “kleopatra” is just a gpg client which remains active once started, and does cache keys. Come to think of it, “kgpg” does the same thing, so it might have been “kgpg” rather than “gpg-agent” that was caching the key for the OP.
I’ve mostly used “gpg” at the command line, where only gpg-agent is involved in caching.
I checked Kgpg and Kleopatra and in Kleopatra there is a possibility to set the expiration time like this:
In Settings -> Configure Kleopatra -> GnuPG System -> GPG agent
I changed “Expire cached PINs after N seconds” to 60 s.
Doing this in Kleopatra created the file gpg-agent.conf!
vandel@linux-wkck:~/.gnupg> cat gpg-agent.conf
###+++--- GPGConf ---+++###
###+++--- GPGConf ---+++### Sat 10 May 2014 12:20:24 PM CEST
# GPGConf edited this configuration file.
# It will disable options before this marked block, but it will
# never change anything below these lines.
Creating the file manually with this content I suppose also would have the same effect. I couldn’t see that it was possible to configure the cache time in Kgpg too.
Then Kleopatra is not actually caching your key. It is relying on gpg-agent to do that.
Maybe Kgpg does the same – relies on gpg-agent. In that case, the gpg-agent.conf setting will also apply to Kgpg. Now that you have it set to 60 seconds, you might test that with Kgpg. I’ll note that what’s in gpg-agent.conf probably does not take effect until you logout and login.
I’m pretty sure that thunderbird with Enigmail also relies on gpg-agent for key caching.
On 2014-05-10 14:56, nrickert wrote:
> Vandel;2642284 Wrote:
>> Doing this in Kleopatra created the file gpg-agent.conf!
> Then Kleopatra is not actually caching your key. It is relying on
> gpg-agent to do that.
If I recall correctly (I don’t have a full kde system in this laptop to
check this out) you can tell kleopatra to use gpg agent or use some
other method - which I can’t precise because I don’t have kleopatra
installed here, as I said.
> I’m pretty sure that thunderbird with Enigmail also relies on gpg-agent
> for key caching.
Depends on the desktop. In XFCE, for instance, it starts the “Gnome
keyring GPG agent, or equivalent”, to do it. But Thunderbird can also be
configured to do the caching on its own.
Sometime ago I had problems because I had two or three agents competing
for control. I had a generic session start file that started the gpg
agent, and the desktop was also starting that or a different agent…
because that was the old way of doing it.