[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

From: Stephen J. Turnbull
Subject: Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.
Date: Sat, 25 Oct 2014 06:47:37 +0900

Perry E. Metzger writes:

 > When you study the failures in enough real world deployed systems,
 > even when used by trained personnel, you lose your belief that it
 > is okay to provide knobs to the users that they don't understand very
 > well. Really the only safe system follows "there should be only one
 > mode, and it should be secure".

I heard you the first time.  What your discussion ignores is that
that's already a moot point, especially in free software.  The
insecure alternative exists, is installed, and will be used in
preference to an upgrade with "one mode and that mode is secure" if
the inconvenience of security is great enough.

It's possible that the inconvenience is small.  Your anecdote about
P25 radios suggests that in that case in fact it was, but that can
only be determined by finding out whether organizations different in
many ways are the same in that dimension.  On the other hand, it is a
fact that people have died (and to this day are dying in Japan)
because of lack of compatibility between communication systems among
cooperating organizations such as fire and police.  It's possible that
fallback-to-compatible capability did matter and still does matter.

I'm not going to attempt to deny the importance of security, the lack
of information and training in use of optional security features among
users, or the rapid escalation of frequency and power of attacks.
Nevertheless, advocating extreme security policy is unlikely to
achieve the goal of extreme security in the current environment, and I
believe that a more balanced approach can do better.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]