Kp <kp at valhallalegends.com> and myself have already been working (somewhat) on a fix for this as time permits. There are some fundamental design problems, however, as the SilcClientConnection object is not referenced counted as it must be (as you have noticed).
All of the key confirmation prompts suffer from this flaw. I've got a fix for /getkey being broken, other than the lack of reference counting for the SilcClient and SilcClientConnection objects. There is nothing that can really be done about the SilcClient object not being refcounted - somewhat of a design problem in the exposed interface of the silc client library unfortunately - but as long as you don't unload the silc .so in irssi while it is running, you shouldn't run into trouble there. The SilcClientConnection issue remains, but as that seems to have its lifetime more or less controlled by the library itself, it seems more feasible to fix (if somewhat of a pain to inject reference counting into things after the fact that should have been referenced counted in the first place.) The other option is to modify irssi to add a way to cancel the keyboard input prompt, but this looked nontrivial, and even if that were done, there are still other issues with the key prompt system that need to be carefully looked at. - S -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jérémy Bobbio Sent: Friday, July 11, 2008 3:22 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: silc client segfaults if key is verified after disconnection Hi! I have spent some time trying to fix the bug reported to the Debian SILC package as #482145 [1], but solving this might require some pretty bad tricks (or an API change). [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482145 In the silc client (or the irssi plugin), during the first connection to an unknown server, the client asks the user about the key. It's pretty easy to start the connection and jump to do something else while the client is connecting (especially if the network is slow). If the answer takes too much time to come, the remote server will simply drop the connection. But the minibuffer is still asking for a reply, and answering will result in a segfault. This segfault will be triggered by client_ops.c:verify_public_key_completion() when calling silc_pkcs_save_public_key() with a free'd public_key. I have tried to resolve the issue by trying to verify the connection status in verify_public_key_completion(). But "verify->conn" is already free'd as well. The SILC_SERVER_REC has a "disconnected" field, which seems to be updated when the server is disconnected. So I thought about adding another field of type SILC_SERVER_REC * to PublicKeyVerify, but there seems to be no way to get a proper reference. When the PublicKeyVerify structure is initialized in silc_verify_public_key_internal(), SilcClientConnection has just been created by silc_client_add_connection() and the caller of silc_client_connect_to_server() has no way to set the context field at that time. So well, here's my current findings, and I don't think that I will be able to solve this issue without some external help. :) Cheers, -- Jérémy Bobbio .''`. [EMAIL PROTECTED] : :Ⓐ : # apt-get install anarchism `. `'` `-
