Version: (using KDE KDE 3.3.1)
Installed from: Gentoo Packages
I cannot seem to get KMail to decrypt emails. If it is possible, it is much more complex than it should be. I have tried to get this to work for two different people, but neither even prompt for a passphrase.
Encrypted message (decryption not possible)
Reason: Crypto plug-in "openpgp" could not decrypt the data.
Error: Bad passphrase
My wife's error:
Encrypted message (decryption not possible)
Reason: Crypto plug-in "openpgp" could not decrypt the data.
Error: Decryption failed
Please follow the instructions at http://kmail.kde.org/kmail-pgpmime-howto.html
These instructions seem to be for using gpg-agent... Is non-agent viewing now unsupported?
On Wednesday 03 November 2004 14:56, Luke-Jr wrote:
> These instructions seem to be for using gpg-agent... Is non-agent viewing now unsupported?
You have to either use gpg-agent or type the password each time - storing the password
in kmail is too insecure.
I would prefer to enter my passphrase each time... I am never given this chance, though...
> I would prefer to enter my passphrase each time... I am never given this chance, though...
Then you're missing the rest of the setup listed in that howto page.
What part are you referring to? Everything else seems fine. Encryption/signing works also.
Here's what I get from reading the code (correct me if I'm wrong):
The "new" way to interact with gpgme is libkleopatra, which provides classes like QGpgMEEncryptJob or QGpgMEDecryptVerifyJob for encryption and decryption, and which takes care of requesting the passphrase from the user if needed.
This framework is used when encrypting a message: the composer calls CryptPlugWrapper::encryptJob, which calls QGpgMEEncryptJob.
For decrypting this does not happen: CryptPlugWrapper::decryptVerifyJob, which calls QGpgMEDecryptVerifyJob, is never called.
The message parser calls the "old" CryptPlug::decryptAndCheckMessage instead, which has its own code to interact with gpgme, and which does not support asking for a password (gpgme_set_passphrase_cb is not called).
Is this what's happening?
*** This bug has been confirmed by popular vote. ***
For me inline pgp doesn't get descrypted, but PGP/MIME does. For the latter on pinentry gets called, but for inline stuff kmail tries to use its own routines as it seems and fails
Sounds quite probably the same problem I'm having. Funny that my KMail sends what it has problems decrypting... you'd think that'd be the first combo to test.
So, guys what's up ? KDE 3.3.2 is now out, and kmail still cannot decrypt emails.
Many people around me have the same problem.
The problem has been existing for many months in *stable* KDE releases.
How can this be ?
Please follow the instructions at http://kmail.kde.org/kmail-pgpmime-howto.html
Thanks for your reply.
But, are you serious ???
I'll better use another email agent than struggle with unnecessary headache.
An I also know that if I ask all the users around me to do this to fix their problem, they will just tell me KDE sucks.
Email decryption was working fine before. Why did you introduce alpha code into stable releases ?
Sorry, but do you really expect users to do this :
(all the libs are already installed on my system)
Configure GnuPG to use gpg-agent
If you updated gpg from 1.0.6 or earlier, please make sure to set your own key to ultimate trust yourself, to move the old options file ~/.gnupg/options to the new location ~/.gnupg/gpg.conf and to run
once. In all cases, add this to your ~/.gnupg/gpg.conf:
Add a file ~/.gnupg/gpg-agent.conf with the following contents:
(replace the path to pinentry-qt depending on where the distribution installed it).
Before using gpg, you need to start gpg-agent:
eval "$(gpg-agent --daemon)"
(gpg-agent outputs a little shell script that sets the environment variable GNUPG_AGENT_INFO). You may want to add this to your ~/.xsession or startkde so that all programs see the environment variable.
Starting with KDE-3.3 you can add the gpg-agent command in ~/.kde/env/gpgagent.sh (the filename doesn't matter). The contents of ~/.kde/env/ is sourced by startkde.
Before you start to configure KMail, please do a short test if GnuPG is working together with the agent.
For this, use a simple command in the shell:
echo "test" | gpg -ase -r 0xDEADBEEF | gpg
Of course, 0xDEADBEAF must be replaced with your own key ID. While running this command the agent should open a graphical password dialog two times. First for signing (gpg -ase) and then for decryption (| gpg).
Starting with gpg 1.2.5, you can use KMail to configure most of the options found in ~/.gnupg/gpg.conf through gpgconf, which was installed along with a few other utilities by the gnupg package in agent-only mode. See KMail's handbook for more info on this.
I have to agree that if a feature is meant to be used by normal users, following the howto cannot be expected, that's why there is a spam-wizard which replaced a howto.
David Faure already posted that URI before and it didn't help at all. Unless this has been fixed with 3.3.2, it is indeed a bug as Prakash K. Cheemplavam described.
I am using 3.3.2. Kmail will decrypt inline OpenPGP messages fine, but fails on OpenPGP/MIME messages. OpenPGP/MIME signed messages seem to work properly, however. I also checked that OpenPGP would decrypt the PGP block out of the failing messages, and it did.
Just updating a bit: I am now running CVS HEAD and the problem *still* exists.
I am running CVS HEAD and Kmail *can* decrypt all kinds of messages fine. I am using gpg-agent and pinentry asks for the passphrase in both inline and MIME.
This code has been working since before KMail 1.6 (I think). I would not call it alpha quality.
Then there is obviously something different about your system's configuration. I am not (and have no desire to) using gpg-agent. KMail used to ask for the passphrase but hasn't since about (IIRC) KDE 3.3.
Maybe KMail cannot do something else than assuming that you use gpg-agent (thus not ask for a passphase)?
The support for the old passphrase caching and asking mechanism has changed. gpg-agent does it a lot better, and in a more secure manner, so KMail has been changed to support it as best as it can. That means the support for non-gpg-agent situations exists, but it will do less than it used to.
Quite frankly, it has been some time since I've last tested non-agent situations (why should I if the agent works better?). I will do so later today and report back.
Now, if you configure your gnupg to use the agent (use-agent in ~/.gnupg/options), then gnupg will never ask for a password and, thus, KMail will always report failure. That's just a configuration problem.
Please verify that you do not have "use-agent" in ~/.gnupg/options or any other configuration file gnupg might use.
I do not have a ~/.gnupg/options file and use-agent does not appear in ~/.gnupg/gpg.conf
I do not have use-agent uncommented in the configuration file.
I'll try to summarize a little bit what all this is about, IMO there seem to be some simple misunderstandings.
- Some people don't complain as kmail presumably works when everything is installed as described in the howto.
- Some people complain because for some reason or another their distro doesn't feature gpg-agent and/or they don't want to install it themselves. One reason might become clear from the following
Quote from http://kmail.kde.org/kmail-pgpmime-howto.html (which we've all read often enough I think)
First, get the following packages:
1. libksba (>= 0.9.8)
2. gnupg (>= 1.9.10)
which means that additionally to the current stable gnupg version (1.2.x/1.4.x) you need the development version 1.9.x. Correct me if I'm wrong bit isn't the whole thing about encryption that you want a solution that is as secure as possible? The gnupg people themselves say:
Note that GnuPG 1.9.x is quite different from the older versions and under
heavy development. Most likely you want the semi-stable 1.3 version or one
of the release candidates.
So far for the pros and cons of gpg-agent.
- But one thing I dont understand is how little attention has been paid to
the posting # 17: http://bugs.kde.org/show_bug.cgi?id=92619#c7 so far which states that this point shouldn't be too difficult to solve after all. I think that this was the real point about this bug.
Have a nice evening, Daniel
Same here (I do not have a ~/.gnupg/options file and use-agent is commented in ~/.gnupg/gpg.conf)
My system is a plain standart kmail and gnupg install on Gentoo.
As someone stated earlier, a KDE end user should not need to edit configuration files manually (this is why the GUI is there in the first place). Or, there should at least be a wizard that updates the config files automatically.
Meanwhile, gnupg is still not able to decrypt anything on my system (as is the case for all other users I know).
There are also people that don't want gpg-agent and want to enter their passphase everytime (like me). I don't send/receive many encrypted emails so for me it'd be more work to set up gpg-agent than to just type my passphase every time it is needed.
I have just tested KMail from HEAD 20050110 (that is, yesterday), ran inside Kontact. GPG_AGENT_INFO was unset at the time, but "use-agent" was on in ~/.gnupg/options.
When I tried to read an OpenPGP/inline encrypted message, KMail asked me for the passphrase. I typed it, the message was shown fine. When I moved out, then back over the message, it did not ask me again for the passphrase, and showed the message (= it cached).
When I tried to read an OpenPGP/MIME encrypted message, KMail did NOT ask for a passphrase. It simply displayed that the plugin could not decrypt the message. That's understandable, because the plugin requires gpg-agent and will not work without.
I did not try sending messages, encrypted, signed or otherwise.
My conclusions are:
- KMail is working fine in my build
- "use-agent" in ~/.gnupg/options is not necessary
- you must use gpg-agent if you want to use OpenPGP/MIME
Installing gpg-agent and making it be loaded at KDE start is simple and should be done by your distributor. If they don't do it, please bug them. It's just a script in $HOME/.kde/env/ containing:
(A more complex solution is proposed in many pages in the web, including some that come with gpg-agent).
Also, please note:
$ gpg --version
gpg (GnuPG) 1.2.6
$ rpm -q libksba0
So I do NOT have the minimum required versions.
OK, so KMail can be made to decrypt pgp/mime messages using gpg-agent/pinentry, but why is this necessary only in this one case? KMail can quite happily fall back on other methods for pgp signing and pgp/inline decryption - why does the same fall-back not exist for pgp/mime?
This was fixed for me by enabling gpg-agent and installing pinentry. Now some ugly QT dialog asks me my password.
The correct term would be "worked-around", not "fixed". Even with gpg-agent, the problem still exists...it just never occurs for you.
True. I still cannot understand why KMail needs pinentry and gpg-agent to display this ugly QT dialog.
Passphrases aren't the only possible "PINs". One of the ideas behind all the ägypten code is that it should also work for smartcards. That way, you insert your smartcard in a cardreader slot and you don't have to type the password to send signed emails or read encrypted ones.
KMail can't do that directly. Even if it could, it wouldn't work for other email clients, such as mutt. The way things were implemented, the same backend is shared.
This bug report has got long and confusing. The *original* report was about not being able to decrypt OpenPGP/MIME emails: that requires gpg-agent. In my opinion, this bug should be changed into a wishlist: ability to use OpenPGP/MIME without gpg-agent. I am not making that call, though.
As for decrypting inline OpenPGP messages, that's a different bug, if it is a bug at all. It worked here for me, so I am suspecting people who have that problem have a local configuration problem somewhere in KMail or gnupg. (Does KGpg also play a role in this?)
A more descriptive error message can be useful too. "Wrong passphrase" while gpg-agent should be installed is not handy.
I would consider removal of a somewhat commonly used feature a bug, especially if there's not really any (obvious during upgrade) documentation saying what people using it would need to do to activate the replacement feature.
What feature are you referring to?
Inline OpenPGP works as it used to. The only change there is that it now supports gpg-agent *as well*. And that happens because of gnupg itself, not because of KMail. In other words, if you run gnupg on the command-line, the pinentry program will show up.
OpenPGP/MIME never worked without gpg-agent. Since it was first introduced, it has always required gpg-agent.
Most KMail users are unaware of the difference between inline and OPGP/MIME, thus it has the effect of making decryption sometimes-it-works-and-sometimes-it-doesn't to such users.
I can see the technical differences between when it works and when it doesn't, but most users wouldn't.
Agreed. KMail should display a more verbose message. If it can, it should also retrieve more information from the openpgp plugin (i.e., the fact that gpg-agent isn't running).
A simple "click here for help" taking to KMail's Handbook should suffice.
Also note: it's the distributor's job to properly install and set up gpg-agent. End-users shouldn't have to do that.
The only problem is that gpg-agent is alpha code - which is the reason that Gentoo does not include it by default (it's available, but not marked as stable)
Ah, I can finally understand what you meant by alpha-quality software:
$ rpm -q gnupg libksba0
$ rpm -q gnupg2 libksba8
/usr/bin/gpg is part of gnupg 1.4, whereas gpg-agent is part of gnupg 1.9.12
The kdepim source tarball includes the alpha-quality libraries, if they are missing (libgpg-error and libgpgme). All that is missing is the gpg-agent. That's why the plugin gets compiled, even if the system does not provide the libraries itself.
What's more, it cannot be turned off.
gnupg is 1.9 is even hardmasked for gentoo (this means that users that have selected to install testing packages will not even get it) but gpg-agent is just marked as testing.
> which means that additionally to the current stable gnupg version (1.2.x/1.4.x) you need the development version 1.9.x.
Yes, but only for gpg-agent. You're supposed to keep using the gpg from 1.2.x or 1.4.x,
and install the "gnupg-1.9.x" package for gpg-agent - it will not overwrite your gpg, since it
installs a "gpg2" binary (which is indeed considered unstable, don't use that one).
Thiago: you *do* have the minimum required versions, if you have gpg-agent installed,
but don't use gpg --version to check your gnupg-1.9.x version, for the reason above :)
I'm giving up on this. I have followed every advice here and in the howto, however I can not get PGP-inline messages to be decoded. Kmail displays a different (somewhat easier) password dialog on these and then doesn't decode anything. I'm using KDE 3.4 beta1. PGP-MIME works as expected.
Another thing is that it is impossible to attach keys to kaddressbook entries. It marks every key other than mine with an "x" so I can't select it.
I must say it is somewhat embarrassing for a software this complex to not be able to decrypt a simple PGP mail easily. I hope this becomes easier.
OK - adding to my last comment, I have figured out that I had to manually sign the keys (as they had been untrusted) to be able to use them. So that's a kaddressbook thing to tell the user about.
Created attachment 9274 [details]
Hi. Along the lines of comment 7, I experimented a bit with kmail code. I must
say that I'm absolutely not familiar with that code, that I have no way to test
all code paths, that I can experiment only with inline or OpenPGP
signed/encrypted mail produced by kmail, and that I know nothing about RFCs
about encryption and all the standars used in real world.
However, with the rough patch above I managed to make kmail decrypt encrypted
messages without using gpg-agent. Basically, I replaced the long and ugly
function bOkDecrypt() with a small function decryptBlock() which uses
libkleopatra to do the same job.
My impression is that with a few hours of work by someone familiar with the
code and able to test it, the old cryptplug architecture can be totally removed
from objecttreeparser.cpp, and replaced with a leaner implementation based on
libkleopatra, probably with a noticeable reduction of the file size.
Debian is another distribution that will not be shipping GnuPG 1.9.x in our upcoming release, and as such does not have gpg-agent available. Our users thus lack full PGP support in KMail, without resorting to 3rd-party packages.
For this reason, we would welcome a patch, usable with the 3.3 branch as well as HEAD, and ideally official but unofficial if necessary, that would allow KMail to decrypt OpenPGP/MIME messages even if gpg-agent is absent. Perhaps Gregorio Guidi's patch can serve as a starting point.
Christopher Martin, on behalf of the Debian KDE Maintainers
Can't you simply ship gpg-agent, without the rest of gpg2?
for the Debian packagers:
For the bug reporters and Thiago:
Please compare the value of kpgprc's pgpType key with each other. We still use kpgp for inline decryption, but there's no config GUI for it anymore. If the pgpType value isn't set to 0 (auto) or 1 (gpg), then it tries to use pgp 2/5/6 (2,3,4), or is explicitly set to off (5).
$ grep pgpType /home/thiago/.kde/share/config/kpgprc
Now that you mention it, I remember touching that file manually once to fix a bug related to signing. I think it was pgpType that I changed.
Thanks, Marc! I had pgpType=5 and simply deleting kpgprc (and restarting kontact) solved the problem for me (current standard stable gentoo installation, i.e. KDE 3.3.2, gnupg 1.2.6 + gpg-agent 1.9.14).
I should add that I didn't touch the standard configuration files for gnupg, i.e. I have no (active) use-agent in there.
The passphrase-dialog I am seeing in both OpenPGP/MIME and inline cases is pinentry-qt with the long user instruction (the one that contains the key ID), before deleting kpgprc I had this dialog only for OpenPGP/MIME which worked, for inline I had a different (more basic) one which did not work.
Thanks! This helped a lot, it now works just as it should! That should be automatically done by kmail then as appearantly a lot of people run into this when they upgrade.
CVS commit by faure:
Ignore pgpType config key, to fix migration issues, given that the kpgp backend isn't available anymore.
M +5 -2 kpgp.cpp 1.73
--- kdepim/libkpgp/kpgp.cpp #1.72:1.73
@@ -111,5 +111,8 @@ Module::readConfig()
showEncryptionResult = config->readBoolEntry("showEncryptionResult", true);
mShowKeyApprovalDlg = config->readBoolEntry( "showKeysForApproval", true );
- pgpType = (Module::PGPType) config->readNumEntry("pgpType", tAuto);
+ // We have no config GUI for this key anymore, and the KPGP backend isn't ported,
+ // so let's just use Auto all the time. See #92619.
+ ///pgpType = (Module::PGPType) config->readNumEntry("pgpType", tAuto);
+ pgpType = tAuto;
flagEncryptToSelf = config->readBoolEntry("encryptToSelf", true);
@@ -121,5 +124,5 @@ Module::writeConfig(bool sync)
config->writeEntry( "showKeysForApproval", mShowKeyApprovalDlg );
- config->writeEntry("pgpType", (int) pgpType);
+ //config->writeEntry("pgpType", (int) pgpType);
We were wondering why has the bug been marked as fixed, since it seems that the commited fix does not provide a solution to people who don't want or can't use the gnupg agent.
If you prefer that a separate wishlist report is opened for the above, please state so.
Right, the reader-window code doesn't have support for the non-gpg-agent case.
I re-titled the bug to narrow it to that case (kmail _can_ view encrypted mails, if you use gpg-agent) and reopened it.
Even if this bug ever get fixed (IMHO not before 3.4 since the code change required to port to the new framework would be quite big), please note however that gpg-agent is the recommended secure solution. Why would debian not choose the secure solution over the non-working non-secure one?
> Even if this bug ever get fixed (IMHO not before 3.4 since the code change
> required to port to the new framework would be quite big), please note however
> that gpg-agent is the recommended secure solution. Why would debian not choose
> the secure solution over the non-working non-secure one?
- gpg-agent is *not* the secure solution since it is part of the gnupg-1.9.x package. Guilty by association.
- Inline OpenPGP should be the *default* (not depreciated) until gnupg-1.9.x becomes stable/secure.
- For poor hapless end-users who just want encryption to work with minimal effort:
1) Click Settings --> Configure kmail... --> Identities
2) Click on your account
3) Click Modify
4) Click Cryptography
5) Select Preferred crypto message format: Inline OpenPGP (depreciated)
The bug is not caused by the different encryption style, but rather KMail's differing implementations for them. Inline OpenPGP *is* deprecated, mainly because it looks bad on any mail client lacking PGP support.
> Inline OpenPGP *is* deprecated, mainly because it looks bad on any mail client lacking PGP support.
That's certainly not the reason. The main reason is that it can't encrypt attachments AFAIK.
> The main reason is that it can't encrypt attachments AFAIK.
Hmm, my line could be read two ways. I know for sure it can't encrypt attachments,
I meant that AFAIK this is the main reason :)
Just a short notice to update the position of Debian about this: the internal issues that prevented gnupg2 from being included have been solved, and we'll be able to ship a fully functional KMail in Debian 3.1 without the need of a patch.
Adeodato Simó, speaking for the Debian KDE Maintainers
I think the problem in KMail 1.8 (KDE 3.4.0) is related to this bug: I sended an encrypted mail to a recipient. I cant view this mail myself anymore (Decryption failed, openpgp could not decrypt the message).
BUT: The same works fine if I use KMail 1.7.2
Please advice whether this should be treated as separate bug.
I really really can NOT believe, that this bug is *that* old. I am using KDE 3.4.2 and I remember a time where gpg decryption worked, but that's been a far long time ago.
I'm explicitely want to enter my passphrase when encrypting/decrypting data like these, so gpg-agent is not an option.
Is there any activity (or even willing) to get this fixed?
>I sended an encrypted mail to a recipient. I cant view this mail myself
> anymore (Decryption failed, openpgp could not decrypt the message).
> BUT: The same works fine if I use KMail 1.7.2
> Please advice whether this should be treated as separate bug.
I believe this is a seperate bug.
From Christian Parpart 2005-09-20 05:02
> I'm explicitely want to enter my passphrase when encrypting/decrypting data
> like these, so gpg-agent is not an option.
This conclusion is based on the assumption that gpg-agent always caches
the passphrase. It does not! Just configure gpg-agent to not cache
(--default-cache-ttl 0 ). As you cannot avoid that code sees your passphrase,
you are not losing security by gpg-agent. Instead the usae of gpg-agent will
increase security (a little).
It's been over a year since this bug was first reported. It still exists, as demonstrated by the fact that I can't read an email that I encrypted with my own public key and sent to myself.
Should I assume that KMail is deprecated in favor of Mozilla Thunderbird?
No, it means you should run gpg-agent like you were supposed to.
Besides, I do get a window telling me "gpg-agent was not found running, you have to run it if you don't want to be asked for the password every time" and it asks for the password. So it works for me.
> Besides, I do get a window telling me "gpg-agent was not found
> running, you have to run it if you don't want to be asked for the
> password every time" and it asks for the password. So it works for me.
Not that I particularly care anymore, since Debian finally shipped
gnupg-agent, but: does it work for you when decrypting OpenPGP/MIME
messages? That's what this bug is about, afaik, since Inline PGP
messages get opened fine without gnupg-agent.
Just tested with KMail 1.9.1 as well.
No, that doesn't work. It can send signed OpenPGP/MIME, but not read encrypted ones.
It looks like KDE PIM developers have other priorities, regardless of the vote count. Patches are welcome. There may be yet a release to include it before KDE 4.0.
It is indeed still broken (shows "Encrypted data not shown." w/o even asking for passphrase) in latest 3.5 Svn using the default encryption settings. Not all KDE users want gpg-agent.
kmail 1.8.3 (shipped with KDE 3.4.3) does not ask for a passphrase when decrypting emails encrypted with inline OpenPGP, if gpg-agent is not running. Thus kmail cannot decrypt inline OpenPGP encrypted emails without gpg-agent running.
I consider this a bug because kmail does ask for a passphrase when
signing emails with inline OpenPGP, even if gpg-agent is not running.
Btw. no changes to gpg.conf or gpg-agent.conf are required to make decryption in kmail work, contrary to the instructions at http://kmail.kde.org/kmail-pgpmime-howto.html. I did not test decryption of emails encrypted with S/MIME (gpgsm).
I've just tested KMail 1.9 (Mandriva Cooker-provided). I sent myself two emails: one encrypted with OpenPGP/inline and another with OpenPGP/MIME. In neither case was gpg-agent running.
In both cases, the emails were encrypted and sent. I got the KMail window asking me for the password.
However, when reading them, I could read the inline one, but not the MIME one.
Sorry, contrary to my previous comment, I did test PGP/MIME, not inline PGP encrypted mails. Without gpg-agent running, kmail would not decrypt those emails.
OK, for me everything work after I followed the steps in the HowTo. But it is NOT good that the user has to perform this steps manually. This should all be done automatically when KMAIL is installed. BTW, why is the passphrase not stored in kwallet which is widely used in many KDE apps? I think kwallet should be save enough ...
Together with the bad performance of kgpg (it doesn't sign keys also it says it does) this is an realy bad KDE performance with regard to GPG. This MUST change! I thought open source is so much about securety?
- I'm currently working on a way to setup and/or start gpg-agent automatically
- storing the passphrase in kwallet is a bad idea because kwallet only obfuscates passwords
And now the off-topic part:
- signing keys with kgpg seems to work here
- kgpg problems should be filed for kgpg, mentioning a kgpg problem in a kmail bugreport won't solve anything
> - storing the passphrase in kwallet is a bad idea because
> kwallet only obfuscates passwords
Eh? I don't want to get OT here, but are you sure that's right?
says "KWallet saves this sensitive data for you in a strongly encrypted
file". Thanks, Andrew.
KWallet encrypts your passwords with your password and a good algorithm. It's not reversible without the password itself. (Hence, if you lose your password, you lose everything in the wallet for good)
So we have a common sense about the situation: it is not insecure to store the gpg mantra in kwallet (unless sucurety is your top priority like in firms or you are paronoid)?
Thats nice :-) .. big family
but why in fact is the default storage for the mantra not in Kwallet ??
I am refocussing this report to wishlist.
- not much activity since almost a year.
- many subproblems have been discussed and resolved meanwhile
+ gnupg 2.0 has been released on November 2006,
so gpg-agent is extra stable.
+ KMail can decrypt anything if gpg-agent is running.
+ Many distributions, like Debian are shipping gpg-agent
and scripts that start it right away. So handling got a lot
- gpg-agent is has more potential to be secure because it is less code
that it runs.
To me gpg-agent is the real solution so I suggest to close this report
because most of the votes will have been for some subproblem which is
long gone, also
- Another code path with non-gpg-agent situation will add unnecessarity
complexity, so I advise against.
Does it not matter that this bug is still a regression? Why should we need to use gpg-agent?
Sorry, but gpg-agent will stay a requirement. From my point of view it is not a regression but an improvement (security-wise).
I'm closing this bug as INVALID because it will never be implemented by us.
It was implemented in the past; even if this is defined as a "wishlist", it is still regression in the sense that the feature has been removed.
Then it should be marked as WONTFIX. As far as I understood it, it was removed for a reason, i.e. intentionally. Regressions usually happen by mistake and are considered bugs.
If an application removes the possibility to save passwords in pain-text in some config file, that would also be a "regression", yet it won't be fixed.
However, this is like an SSH client removing support for keyboard-interactive auth.
Re comment #81: According to http://bugs.kde.org/bug_status.html I chose the correct resolution.
Re comment #82: It is not. We have move the responsibility for the keyboard-interactive passphrase entry from KMail to gpg-agent + pinentry-foo. We have not removed something, but replaced it with something superior.
Just for clarity:
at the moment it is correct to say that kmail switched to a hard dependancy on gpg-agent only for 1 case out of 4 where the passphrase is needed (reading encrypted msg with pgp/mime).
For the other 3 cases (reading encrypted msg with pgp/inline, sending signed msg with pgp/mime, sending signed message with pgp/inline) there is still active code (insecure?) to request the passphrase.
Actually, there is code that deals with the passphrase for all 4 cases, it is just not used in one case, more by accident than by design (see comment #7, comment #44).
accidental changes certainly shouldn't be considered design decisions!
*** Bug 136676 has been marked as a duplicate of this bug. ***
A note to comment #77: "KMail can decrypt anything if gpg-agent is running."
When gpg-agent is running but cannot find the pinentry-program,
it still displays a "Bad passphrase" error message. This is
sad, because the user is not being notified, that KMail couldn't
get any passphrase from gpg-agent at all.
There seems to be something wrong with the communication between
KMail and gpg-agent.
Just poiting out that I did some work on this issue (I hadn't read this report though at the time).
I simply added a dialog asking for a passphrase when gpg-agent is not running. This is what libkpgp and qgpgme too, but for some reason cryptplug does not define a passphrase callback.
This does not raise any security issues, the behaviour being the same as qgpgme and the passphrase is not in any way stored.
You can follow the discussion in the ML here: http://lists.kde.org/?t=118673691300005&r=1&w=2
Btw, I'm attaching the patch too... Ideally, all gpg related operations should use one and only library, libkleo... From what I understand here (http://lists.kde.org/?l=kde-commits&m=118323828925628&w=2) libkpgp will be deprecated.
Created attachment 21514 [details]
Adding dialog to enter passphrase if no gpg-agent running
Posted this patch to the wrong bug report, sorry for the inconvenience :S...
Still no news here, despite the 641 votes. Is the patch rejected ? If so, can you please explain why, maybe we could find a proper solution to the issue.
This patch is obsolete now. In KDE4, libkleo is used by KMail instead of certmanager.
Sorry for the long response about the patch, no one understanding the crypto code had looked at it before.
Since this is a BUG, and on top of that a REGRESSION, I feel patches are not obsolete as long as KDE continues to maintain a version it applies to, in this case 3.5.
> Since this is a BUG, and on top of that a REGRESSION, I feel patches are not obsolete as long as KDE continues to maintain a version it applies to, in this case 3.5.
The 3.5 branch for KDEPIM is totally frozen. We're not committing to there anymore, because we had bad experiences with regressions in 3.5.10 (as good as no developers working on it and no testers).
Interested users or distributions can of course apply the patch themselves.
*** Bug 138348 has been marked as a duplicate of this bug. ***
Can any of the reporters please see if this report is still valid in KMail2 and add a comment on what is needed? Thanks in advance, reassigning to KMail2.
No news for more than 5 years, I think we can close this one :)
I've not seen a usable release of KMail2 yet, so I'm still using 1.13.7.