Artifacts Associated With Ticket 90be78af8b50e255

1. Ticket change [3361d36e77] (rid 1256) by anonymous on 2017-01-19 18:54:42:

   1. foundin initialized to: "1.7.11"
   2. icomment:

      Hi. I originally posted this here: https://sourceforge.net/p/tls/bugs/65/
      
      I'll copy the original report. At the end I include new information.
      
      
      Original report:
      
      I recently ran into a case where my application would crash when using this library (1.6.7). I determined it to be related to the addition of CRYPTO_set_locking_callback() and CRYPTO_set_id_callback(). Specifically, when I deleted the Tcl interpreter (but my application remained running), OpenSSL still called the callback functions, but they were no longer available.
      
      Here are the general steps to reproduce this behaviour:
      
          Have an application with an OpenSSL SSL/TLS connection
          Create a Tcl interpreter
          Load this package
          Delete the Tcl interpreter
          Try to interact with the SSL/TLS connection
      
      I have attached a patch that resolves the problem. It works by registering another callback for when the Tcl interpreter is deleted. At that point, we set the OpenSSL callbacks to what they were prior to this library changing them.
      
      I wrote a post about this issue and my investigation if you would like additional background:
      
      https://blog.summercat.com/tcl-tls-openssl-threads-and-irssi-crashing.html
      
      I am not certain that the patch resolves all possible issues with using these OpenSSL callbacks however. For example, consider the case where we have an application that does the following:
      
          Loads this library (leading to us setting the callbacks)
          Application then sets its own OpenSSL callbacks (unaware they were set)
      
      At that point, can we guarantee the new callbacks are sufficient? Also, if we then throw into the mix unloading this library, we're in the situation where there are no callbacks set at all.
      
      Perhaps this is a far out possibility. It makes me wonder whether it is appropriate for this library to be setting these at all though. I would be very interested in your thoughts on the matter as I am by no means an expert here.
      
      Original patch (1.6.7): https://sourceforge.net/p/tls/bugs/65/attachment/tcl-tls-openssl-callbacks.diff
      
      
      New information:
      
      I re-tested this with 1.7.11. I found the crash still occurs. I updated my patch against 1.7.11:
      
      https://sourceforge.net/p/tls/bugs/_discuss/thread/60039baf/3703/attachment/tcl-tls-openssl-callbacks-1.7.11.diff
      
      One thing I have not figured out yet is this: The crash happens when I test on Debian Jessie (both 1.6.7 and 1.7.11), but not when I test in Debian Stretch. I believe this may be due to the different openssl version. (Jessie is on 1.0.1 and Stretch on 1.1.0).
      
      I noticed there is now a parameter to deinitialize the interpreter (to TclLibInit). I wonder if my strategy could be combined better with that approach.
      
      If I can provide any more information, please let me know.
      
      Thanks for your time.
      

   3. login: "anonymous"
   4. mimetype: "text/x-fossil-plain"
   5. private_contact initialized to: "04c1862265e2a8b43d5fea3ea2054987c3e1d7de"
   6. severity initialized to: "Important"
   7. status initialized to: "Open"
   8. title initialized to:

      Crashes due to OpenSSL threading callbacks if interpreter is deleted
      

   9. type initialized to: "Code Defect"

2. Ticket change [3da4fc388f] (rid 3678) by bohagan on 2024-06-28 22:00:27:

   1. icomment: "This is fixed in commit [0de7b4fc0aa601b2]"
   2. login: "bohagan"
   3. mimetype: "text/x-fossil-plain"
   4. priority changed to: "Immediate"
   5. resolution changed to: "Fixed"
   6. status changed to: "Closed"