Mats Lidell writes:
> 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, [...]
This is not about the security of our machines. It is about securing
the traffic going in and out.
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.
> The core support *is* OpenSSL (or nss or gnutls), and they all
> support the older protocols. [...]
What I mean is that, at least when it comes to GNUS, it uses the
openssl client through some process interface.
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.
I guessed/thought/dreamed our tls-module would provide some API
instead (which might use the openssl client below the surface for
what I know) and that we should use that in gnus, ssl.el and
whatever other places we use tls/ssl. I haven't looked at it though
more than I know we now have a file called tls.c.
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