Bug 2672

I looked into kgpg in the past days and I also was wondering how this thing with pinentry works. It looks like it is spawning whatever is defaulted to provide pinentry on the system.
I think we could/should provide tdepinentry or pinentry-trinity package, which will fill the gap. To my understanding there is no such one in TDE, but the debian natives were used. As it moves forward we'll need to port one to TDE.

It would seem to me that since KGPG itself can doing signing, encrypting, and decrypting, it should be able to take the place of pinentry. Granted, I've never looked at the code so I don't know if that would be possible without modifying KGPG, but it seems to me that adding a TDE-specific pinentry program (or using an external one like it does now) is adding an extra layer that ought to be unnecessary when the needed functions already seem to be present in KGPG.

Not really because other applications do use it as well. In fact each app that asks for a pin/pass could use it ... like bluetooth etc. So I think it is just ok.
I think it is simple program, so I may try modify the old qt3 pinentry for trinity and push it to the code base.

Your original post is also not precise. In fact KMail calls Kgpg and if Kgpg is set up correctly it would ask you once for the password and then keep it until end of session, or whatever is setup. At least this is how it works for me. So  actually Kgpg spawns the pinentry program to obtain the password from the user and not the other way around.

regards

(In reply to deloptes from comment #3)
> Not really because other applications do use it as well. In fact each app
> that asks for a pin/pass could use it ... like bluetooth etc. So I think it
> is just ok.

That may be true of non-TDE applications, but aside from my web browser (which can't use GPG anyways) and chat (for which I use OTR, not GPG), everything I use is a TDE-specific application. For me and others out there who tend to stick to desktop-specific applications, it's going to seem a bit redundant to require a non-desktop-specific application for requesting the GPG passphrase when there is already a desktop-specific application for that purpose.

> Your original post is also not precise. In fact KMail calls Kgpg and if Kgpg
> is set up correctly it would ask you once for the password and then keep it
> until end of session, or whatever is setup. At least this is how it works
> for me. So  actually Kgpg spawns the pinentry program to obtain the password
> from the user and not the other way around.

My initial report seems quite precise to me. If it is not, please be more precise on where I wasn't being precise and I will clarify.

For me, KGPG doesn't seem to be used at all. In fact, I cannot get KMail to request my GPG passphrase unless I specify a pinentry-program in ~/.gnupg/gpg.conf , and specifying KGPG (even by full path) doesn't work. I have to specify one of the pinentry programs installed in order to get the passphrase prompt, otherwise KMail will claim it can't find a valid signature. As for KGPG calling pinentry, I have never seen it do this. Even with no pinentry installed or with the CLI-only version of pinentry installed, I see a graphical passphrase prompt appear when trying to decrypt stuff directly through KGPG itself.

Also, my passphrase isn't (and shouldn't!) kept after I type it -- I could send two emails within a minute of each other, and KMail will request my passphrase each time, just as I expect and want. The only way it should do otherwise (when using KGPG) is if I enable gpg-agent support, but KGPG's support of gpg-agent has been broken since before TDE ever existed -- I first tried enabling it in KDE 3.5.9 with the same result as in bug 1183 (which has been sitting unresolved for almost 5 years).

Hi Kristopher,
we can move this discussion to the devel or user list resp. I myself am using kgpg since it is out there and it works perfectly with gnupg-agent.

The reason that pinentry is separate program is that it is working between kgpg, gnupg-agent and gnupg. I can not take decision to alter kgpg - I think it needs broader discussion. Furthermore it is more work (regression testing kgpg).

Regarding  bug 1183 seems to be not reproducible for me and I have pretty standard setup. In fact I looked in all the kgpg related bugs when updating the code few days ago and found out just two duplicating my issue including the one you mentioned. Briefly all other bugs I would close because they are not reproducible and point to misconfiguration or other user related problems.

(In reply to deloptes from comment #5)
> Hi Kristopher,
> we can move this discussion to the devel or user list resp. I myself am
> using kgpg since it is out there and it works perfectly with gnupg-agent.

I'm not sure what you  mean by "devel or user list resp".

> The reason that pinentry is separate program is that it is working between
> kgpg, gnupg-agent and gnupg. I can not take decision to alter kgpg - I think
> it needs broader discussion. Furthermore it is more work (regression testing
> kgpg).

I am not talking about integrating pinentry into anything, and based on what I've seen, I doubt KGPG itself needs altered since it already seems capable of doing what needs to be done for KMail withouth the use of pinentry. If I can decrypt files through KGPG without pinentry being installed, it's easy to think that KMail ought to pipe encrypted emails directly through KGPG so that pinentry is no longer necessary. The same can be said for encrypting, signing, and verifying signatures -- all things I've don with KGPG without pinentry.

> Regarding  bug 1183 seems to be not reproducible for me and I have pretty
> standard setup. In fact I looked in all the kgpg related bugs when updating
> the code few days ago and found out just two duplicating my issue including
> the one you mentioned. Briefly all other bugs I would close because they are
> not reproducible and point to misconfiguration or other user related
> problems.

I have been able to reproduce bug 1183 on several distributions using a plain-vanilla install of KDE 3/ TDE, KGPG and GPG (i.e. using a fresh install with default settings and freshly generated keys). This includes several versions of Debian going from Lenny to Jessie (using KDE 3 for Lenny, TDE for the others), Devuan, CentOS 6, and Ark Linux (using KDE 3). While I haven't put too much effort into it, what few changes to the settings I did try don't seem to help with bug 1183. This tells me the bug is still valid and should not be closed -- especially when a plain-vanilla install shows broken support for gpg-agent before I can even use it.

OK, I suggest we discuss 1183 separately and focus here on this particular request.

Let me clarify first how I see the picture.

This is the flow of information:

KMail -> libgpgme -> gnupg -> libgpgme -> KMail

I have no idea how all this works ATM. I wanted always to look into kmail to fix few issues that were bugging me for the past few years, but it is a big challenge. I managed only fixing the certificate issue.

libgpgme (provided by kleopatra) is using the gpg-agent. I was thinking it uses kgpg, because it looks similar, but now I had a look into this part of kmail and it points to libgpgme - kleopatra and key/cert manager.

... and looking into the code pinentry is required and password prompt is also part of the logic. 

To me it makes sense to ask a passphrase for the secret key. I wish someone would be able to integrate the kgpg interface in kleopatra as alternative to libgpgme. The way your request would be implemented.

Your original post says "it seems sensible that KMail would go through KGPG instead of Pinentry for signing and decryption of messages"

Let me explain: pinentry is just a password prompt to decrypt and it is part of the gpg package.

Your original post says "Pinentry isn't a TDE application and no longer supports Qt3"

pinentry-tqt is now part of official GPG git branch. 

more details here
https://bugs.pearsoncomputing.net/show_bug.cgi?id=2830

the rest is clear - kmail uses a library, which AFAIR uses gpg interface while kgpg uses the gpg interface. I admit there is duplication and a general gpg interface would make more sense. However I do not think someone has the time to do it ATM.

At some point of time it will be included in the builds and release in TDE - I guess 14.1 is good candidate.

I set the status to duplicate 2830. I hope you do not mind.

regards

*** This bug has been marked as a duplicate of bug 2830 ***