Does OpenPGP work?

[guest]

Hello,

whenever in my Jabber account I specify an OpenPGP key, CPU goes 99% for an undetermined time. If I switch off and on PSI, I'm not able to connect anymore. If I delete the OpenPGP key and restart PSI again, connection is almost immediate. I'm not sure if this is PSI's or Jabber server's fault: can you suggest me something to test this more?

Best wishes and thank you for this great port! Gabriele Gamba

[dmik]

Gabriele, thanks for your report. I can't say much about Psi and OpenPGP right now because I didn't have a chance to look at it at all yet. I suspect your problems are related to the Psi code that starts the gpg executable (this code is untested on OS/2). I plan to review PGP support before 0.10.2 comes out.

Btw, what version of GnuPG are you using?

[guest]

Hi dmik,

it says:

gpg (GnuPG) 1.4.3 Copyright (C) 2006 Free Software Foundation, Inc.

I'm testing PSI also on a different machine, that should have the exactly same GPG installed, but where I'm not able to select the GPG key in PSI (button remains grey, also after enabling SSL connection). At the same time, connection on this machine is immediate while on the other machine it requires sometimes half a minute with CPU at 99%. I'll do more test while waiting for next PSI version: thank you for your work!!

Bye Gabriele

[(none)]

Hi dmik

I confirm my last message: connection from the laptop (eCS 2.0 beta) is immediate, from the desktop (eCS 1.2MR) it requires at least half a minute, sometimes more, with CPU at 99%. I tried copying installation and profile from one machine to the other: behaviour remains the same, so this seems connected to something different in the eCS environment of the two machines and not Psi related...

Bye Gabriele

[dmik]

I've installed gnupg-1.4.5-os2-bin.zip and did some research. I my case, I can successfully select my public key to use in Psi (on the Details page of the Account Properties dialog), but an attempt to log into the account says: "There was an error during OpenPGP processing. Check your settings and try again".

As far as I can tell after studying the debug output a bit, Psi uses pipes to communicate to the gpg executable and pases pipe descriptors using special options like --status-fd 16 --command-fd 13, but gpg says

gpg: [stdin]: read error: Socket is not connected

Seems that file descriptors are treated differently by Qt's LIBC and gpg's LIBC.

[dmik]

As I see, GnuPG also uses kLIBC, but 0.6.R1, not 0.6.1 as Qt/Psi? does. Though, I'm not sure Knut has changed the logic of numbering file descriptors between these two versions. Probably, the OS/2 version of QPipe (wrapeer for LIBC pipes) is just wrong. Anyway, treating these descriptors as LIBC-dependent doesn't seem to be a good idea (no any guarantee that future versions of gpg and Qt/Psi? will use compatible LIBC libraries). Assuming OS/2 file handle should be better; I'll look into what can be done there (such a change may probably require a lot of modifications in gpg).

[dmik]

I've found the reason of communication problems. QProcess currently uses DosExecPgm?() to start a child process which does not implement inheritance of LIBC file descriptors, so that the child simply cannot access them. I will try to use spawn*() in QProcess instead of DosExecPgm?().

[dmik]

Well, I'm really getting tired of this problem. I've replaced DosExecPgm?() with spawnwpe() and *nothing* has changed. The status socket gets notified (I get a QSocketNotifier signal), but read() on the signaled socket handle still returns zero (i.e. exactly the same as it did with DosExecPgm?()).

I'll have to write a simple testcase to check whether this way of communication between the parent and child works at all in LIBC061 or not.

[dmik]

The simple testcase (a single socketpair()) works very well, both way (parent->child and child->parent). Digging further into the problem I've found the following:

1. LIBC versions of Psi and gpg must match. I.e. gpg 1.4.5 (taken from ​http://www.tobiashuerlimann.de/software/GnuPG/) is using LIBC06R1.dll which maps LIBC file descriptors to OS/2 sockets/file handles in a way incompatible with LIBC061.DLL, which makes it impossible to inherit them and use from a child process.

2. The version of GnuPG 1.4.5 I built myself to base it on LIBC061.DLL works better (no inheritance problems), but there is a different kind of issues. After some activity (in particular, upon login, after several runs of gpg.exe including the --verify command to verify the status signature of the account), LIBC's select() stops working properly: it begins to constantly return -1 and errno set to 38 (Socket operation on non-socket) in a tight loop with no actual delay which causes the thread doing select() to achieve the 100% CPU load. Normal socket notifications never occur anymore, so Psi becomes inoperable (i.e. chat messages cannot be sent out and are not delivered from outside). The set of sockets passed to select() represents the normal TCP sockets by that time (i.e. not local "pipe" sockets used for gpg.exe), so I'm still not sure is it a problem of the LIBC select() implementation, or some hidden OS/2 TCP/IP stack problem (I don't even know yet how local sockets are implemented in kLIBC). Moreover, after some time, select() may return error 22 (Invalid argument) instead of 38 for the same set of sockets, which then may change to 9 (Bad file number). It of course may be a Qt problem, but I did some checks to find it out and found nothing so far.

[dmik]

Regarding 2 above, I did fstat on all sockets in the set: when errors 38 and 22 are returned, all sockets are fine (fstat() returns 0). When the error swithces to 9, one of four active sockets is indeed reported as -1 with the same error, however I don't know why (Qt didn't close it).

[dmik]

I'm closing this defect until someone has debugged spawn*() and descriptior inheritance and fixed kLIBC (if necessary). Provided that my assumption about the place of the problem is correct, OpenPGP will work once kLIBC is fixed.