Johann 'Myrkraverk' Oskarsson writes:
Bottom line, emacs-w3m does not use ssl.el. What browser uses it?
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
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.
> I don't care if the default is to not support those
protocols, but a
> minimum level of support for XEmacs is a `supported-tls-protocols'
> variable (name is up for grabs, of course) which has a choice
> customization widget providing the obsolete protocols as options
> (along with a warning as big and red as you like in the doc for each
That's sort of reasonable, but who is going to do that?
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
XEmacs-Beta mailing list