[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp's future
From: |
Richard Stallman |
Subject: |
Re: Emacs Lisp's future |
Date: |
Wed, 08 Oct 2014 21:19:40 -0400 |
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I just want to make sure that Emacs developers in general are aware
that if string properties are added to Guile itself, Emacs will be a
potential vector for attacks.
If you demonstrate that this claim is valid, I will be concerned.
For example, by providing a "back
channel" for malicious information
So what? How would this affect what anyone can do? There are many
other channels to communicate data from one part of a Scheme program
to another, so how would this additional channel make a practical
difference? Why object to adding a window in a wall that has so many
doorways already?
If you show me that there is some real and useful form
of security, which adding string property lists would break,
you could convince me that there is a real issue of security here.
What I advocate is that string properties should be implemented by
using Guile facilities for defining types, not by changing Guile.
It would be a pain in the neck if Emacs strings were something
different from Guile strings. If you want to argue that security
justifies this pain, you need to show it is real security and really
does a useful job.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
- Re: Emacs Lisp's future, (continued)
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/05
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/07
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/07
- Re: Emacs Lisp's future, David Kastrup, 2014/10/08
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/08
- Re: Emacs Lisp's future, David Kastrup, 2014/10/09
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/09
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/09
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/10
- Re: Emacs Lisp's future,
Richard Stallman <=
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/08
- Re: Emacs Lisp's future, Mike Gerwitz, 2014/10/09
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future, Stephen J. Turnbull, 2014/10/09
- Re: Emacs Lisp's future, David Kastrup, 2014/10/09
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/09
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/09
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/11
- Re: Emacs Lisp's future, Eli Zaretskii, 2014/10/12
- Re: Emacs Lisp's future, Richard Stallman, 2014/10/12