Key generation should finish asynchronously

[weinholt]

The key generation can hang irssi for the duration of the key generation. It can also finish early without notice. I believe that these two problems are different sides to the same coin.

To reproduce the hanging:

1. Start an irssi that does not have the .irssi/otr directory.
2. Connect to an IRC server.
3. Open a private message window (/query anothernick).
4. Type /otr genkey foo@bar (or use your own ident).
5. Type a message in the query window.
6. Observe that irssi hangs until the key generation is completed.

To reproduce the lag in notification:

1. Repeat steps 1-3 from above.
2. Type "/otr init" in the query window.
3. Note that key generation has started.
4. Verify with "ps -eLf|grep irssi" that there are three irssi threads.
5. After a while there will only be two irssi threads. The key generation is complete.
6. Observe that there is no message in irssi that says that the key generation is finished.
7. Type "/otr init" again in the query window.
8. Observe that the "Key generation for foo@localhost completed" message now appears in the status window.

Tested with irssi 0.8.15-5 and ibotr5 4.0.0-2 on Debian wheezy amd64 with irssi-otr v1.0.0-alpha1-5-g5f685aa from git.

[DrWhax]

Hi, thanks for opening a ticket. The older irssi-otr plugin also had a similair if not, the same problem. Feedback to the user whether the key generation was a success, a failure or simply hanging is quite important.. working on a fix.

[dgoulet]

Yah so I had a problem with spawning threads and printing stuff to irssi main window. It segfault inside some perl library (I can't remember exactly where). So, the trade off was to start the key generation in a thread that does no I/O on irssi side and update a flag when done before quitting. At each event, for instance "/otr contexts" or receiving a message, this flag is checked and if in a state that the key was generated, it prints out the message.

I'll be quite happy to have a better solution! I just don't have one for now :S.

Furthermore, if we look at other IMs like pidgin, the key creation freezes the current chat window until completion but not the rest if I'm not mistaken. Same for psi-plus. So, having a hang in the current chat window for which the otr session is being initialized is OK with me.

[DrWhax]

I'm not so sure whether it's even possible to freeze certain windows in Irssi. The least we should do is actually providing something like a window or statusbar to show at which stage the key generation is (busy, failed, OK)

Thoughts?

[viric]

I think that the otr statusbar is already good for that. [plaintext/keygen/OTR, ...].

[DrWhax]

@viric Yes, I agree. Next to that, we should find out if this async generation of a key and chat works.

[thatarchguy]

This is still an issue. Running into this problem right now.

[dgoulet]

Unfortunately there is no easy way out of this.... One thing that was
suggested to me recently is to use the glib main loop for that key
generation.

I'm not too familiar with it but this seems the most promising avenue.

[Tronic]

I am currently testing a polling approach. I have a small "spinner" on statusbar widget showing that key generation is in progress. This can be updated frequently via a timer event until the key generation is finished.

Other things to do (that I haven't yet tried implementing):

• Restart any previously attempted OTR handshakes once the key generation is complete
• Display messages about key generation starting and finishing also in private message windows (needs more UI feedback there)
• Try to eliminate all extra delays (why is there a significant delay after ?OTR? before the key generation begins, and does the peer start generating its keys right away?)

And outside the scope of irssi-otr: figure out why it takes more than ten minutes to generate a key, and fix libotr and/or entropy generation accordingly if possible. There certainly are OTR implementations that work without a noticeable delay, too.