Hi Sean, xemacs-beta, On Fri, Nov 21, 2014 at 5:11 AM, Sean MacLennan <seanm(a)seanm.ca&gt; wrote: Is M-x customize-variable RET ssl-program-arguments RET easy enough? Again, I've not tested these arguments, only looked in the man page. Johann _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Johann 'Myrkraverk' Oskarsson writes: There's a long thread on this issue on emacs-devel. It was inconclusive, there are security hawks and doves. larsi and tzz are busily creating a "network security manager" nsm, though I'm not terribly impressed with their understanding of security. My own opinion is that any security measure that interrupts the user's browsing likely to get disabled, and we really should find better ways to address these issues. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Johann 'Myrkraverk' Oskarsson writes: *sigh* What the big browsers do in their bleeding edge version is not the relevant information. What matters is what is happening where our users live, and there is some evidence (eg, the discussions on Python-Dev) that many corporations' intranets remain a big mess[1], and those are precisely the places that are conservative about upgrading things like browsers. Perhaps they would be equally conservative about upgrading Emacsen, but the folks I know who have worked in those environments think that Emacsen tend to get upgraded somewhat faster because the users are more sophisticated and/or have more power over what's installed on their machines. Again, not really the interesting information. What is interesting is which sites still speak only obsolete versions of SSL and versions of TLS that are considered vulnerable, and whether our users need to access those sites. I don't want to hold anything back. I want to avoid screwing our users by removing support for something that (they think) they need. 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 option). Footnotes: [1] Including some like Google! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: As I say, I don't care about the default. Default off, let people who know why they need it opt in. BTW, informed decisions are nice, but the human factors research with respect to security is very discouraging. For 90% of users-off-the- street (which admittedly is not likely to be representative of XEmacs users), the cost of two keystrokes beats risking having your bank account emptied. Specifically, most users are completely unaware of the difference between http: and https: URLS (which, believe it or not, is apparently *made worse* by the practice of some browsers of displaying the scheme "https://" but not the scheme "http://"), and do not know how to interpret the little lock symbol. That means that if SSL2/3 are not available, 90% of users will happily fall back to unencrypted connections to get their work done. :-( Bottom line: disabling buggy encryption protocols is not a no-brainer. These days I'd say the odds strongly favor defaulting SSL2/3 *off*. I'm not ready to remove them, though. TLS 1.0[1] has some known issues, too, but I don't think we can default that off yet. I think if you're that worried about security, you shouldn't being using Emacsen at all. Half-joking, of course, but really, if there's real insecurity in your system, Emacs use is a crack waiting to happen. Are all your elisp files secure? Are you *sure*? Do you have a list of SHA1s on readonly material, and verify your elcs against them whenever you load? The core support *is* OpenSSL (or nss or gnutls), and they all support the older protocols. The problem with OpenSSL is that in the 0.9.x series, which is still prevalent on many platforms, the default at the library level is to fall all the way back to SSL2. I'm not even sure when TLS 1.0 support was added; Mac OS X Tiger and Leopard (maybe even Snow Leopard) may not even *have* proper TLS support. OTOH, OpenSSL 1.01j is state-of-the-art in this respect (including the fix for HeartBleed). OTOH, AFAIK none of the packages we can use refuse to make a connection if they can't verify the signature back to a known root certificate. Anybody can self-sign, so spoofing via cousin domains (YourBank.com.my, anyone?) is trivial. Footnotes: [1] IIRC. I'm sure I recall somebody on Python-Dev advocating disabling one of the TLS versions. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: There's no real difference. Most exploits happen at endpoints, not by cracking streams en route. SSL2 is good enough to prevent casual eavesdropping. If somebody *wants* to steal your information, I don't think they'll stop trying just because your transport security is the latest and greatest. Yes, I understand that. My point is that basically, because this is system security, if you decide to disable a protocol, you want to do it system-wide rather than one app at a time. Similarly, if a new stronger protocol is developed, you'd like your TLS library to provide it to all apps without rebuilding the apps if possible, and surely without changing their source code. Thus, that client is just a thin layer (command line parser, basically) over the library which provides the defaults -- that's the only way you can get such system-wide behavior. If some app or use case really needs it, that app can change the protocols in use explicitly. I don't see that Emacsen have special needs here. But some users may, thus the need for configurability. It does provide such an API, but it's not clear to me that the new API provides all that many advantages over the existing use of a TLS helper process. I don't think it's worth the effort to rewrite existing programs. Let the Emacs guys do that. ;-) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

ssl.el is part of the w3 package so I guess that is it! And we don't have w3m in the packages. It has been on my, maybe-I-should-add-that-to-the-packages list for a decade or so but I haven't done it yet. Well I have never got it to work very well for me but is it officially deprecated? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

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