Re: Disable SSL2 and SSL3 in ssl.el?

Johann 'Myrkraverk' Oskarsson writes: That's not my problem. If ssl.el starts with SSL2 and works up, that's a major bug that needs to be fixed immediately, and just disabling those protocols is a reasonable start. If, as I expect, it starts with the most recent version of TLS and works down, then it will hit SSL3 or SSL2 only in the (very rare, according to you) event that the user is contacting a server that only supports those obsolete protocols. Usually the user knows that they need to contact such servers and why, although few users can make a truly informed choice about whether the security risk is worth it. Experience and HCI research say most will choose to force the connection. It is not our job to get in their way, and certainly not our job to require them to write code to restore the capability. A customizable variable is a minimal requirement here. You are, right? ;-) Look, you can write any patch you want for your own modified version. But if you want it in the public distribution, you need to consider the needs and likely behavior of the general population of users. I see no reason to believe that we are likely to save many users who might be vulnerable -- they'll just use a different, more configurable app if they can't get XEmacs to do it. We will, however, annoy and interfere with the work of *all* such users who might be vulnerable: upgrading servers is nontrivial and time-consuming at best, and most likely impossible for these users. It's really not a lot of work to write a defcustom. Eventually I'll do it -- disabling by default is the right thing to do -- but unless you can get three reviewers to agree that a patch without the defcustom is a good enough idea to override my veto, the disabling patch itself will have to wait until somebody finds the time to write the defcustom. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta