Re: Release plans

[Alan Mackenzie]

Hi, Johannes!

On Tue, Aug 19, 2008 at 01:27:19AM +0200, Johannes Weiner wrote:
> Hi,

> Alan Mackenzie <address@hidden> writes:

> >> And what is the difference between an Emacs that calls non-free code
> >> via a binary module, and an Emacs that accesses files via TRAMP and
> >> non-free SSH?

> > The ability of a binary module to disable `defun' and prevent all but
> > digitally signed code from being loaded.

> How about fset'ing defun to something new?

> You still have not answered to what I said yesterday: This
> microsoft8.dll `functionality' does not in any way rely on the feature
> proposed here.

I suppose not, strictly speaking.  From a publicity point of view, using
a Lisp library to disable Lisp is much more blatantly wrong than using a
binary "to enhance the security of an otherwise complete working system".
It would be easier (technically, and probably legally, too) to remove the
nastiness from a .elc file than a .dll one, whilst still leaving positive
features working.

> And if you would want to do Bad Things, what prevents you from calling a
> non-free binary with Emacs' process interface?

You mean getting other people to call your non-free binary, I think.  The
fact that it's a process-level interface prevents the binary from doing
much damage to the guts of Emacs.  Doesn't it?

> See, I really believe in your points that this feature has the
> potential to be abused.  But to me it is not obvious how it would open
> a _extra_ possibilities besides doing it more technically advanced.

> The libotr bindings I have in mind would also work with the process
> model.  Just hack up an executable that can be controlled by
> command-line arguments to wire up your elisp stuff with libotr.

How much more does the libotr library need than writing to its stdin and
reading from its stdout?

[ .... ]

> But I have no way right now to implement pluggable bindings in a sane
> way that I would consider better than an ugly hack.

OK.

>       Hannes

-- 
Alan Mackenzie (Nuremberg, Germany).