Re: Release plans

[Johannes Weiner]

Hi, Alan!

Alan Mackenzie <address@hidden> writes:

> 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.

It is certainly easier to reverse-engineer, I guess.

>> 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?

It still damages your freedom.

I thought twice about appending `*SCNR*' to the previous sentence as it
was first meant as a satirical response in the RMS style.  You write up
arguments and all you get back is a totally generic, ignoring everything
you said, `this is bad[tm] for freedom[tm]'.

But after thinking more about it, yes, this should really be _your_
argument, too.

I really don't think it makes more harm compared to a nasty .elc because
Emacs has so much of its core accessible through Lisp.

And then, practically, it does not matter which way you damage freedom,
right?

As a user, you won't even realize the difference:

  apt-get install some-nonfree-emacs-extension

Whether this is a shared library that loads into Emacs, a precompiled
.elc that loads into Emacs or an .el wrapper and a non-free executable.

And all the user sees is this, in either case:

  (require 'nonfree-extension)
  (non-free-extension-mode 1)

And what I also consider important: you can modify every variable or
function binding from the Lisp side.  That means that you don't need to
go to the C level to be really harmful.  You can also just rebind every
core symbol and already modify Emacs' behaviour quite severely.

Save the old binding, rebind it and you have total control over
everything the user does.  You can decide whether you want to allow
garbage collection at the moment by rebinding GARBAGE-COLLECT and decide
according to the phase of the moon whether you pass on to #<subr
garbage-collect> or ignore the request.  I really wonder what you could
NOT do.

Emacs is already so powerful that I don't understand all the fuzz about
the shared library loader.  It would be nothing more than convenience.
But don't see it introducing any extra danger at all.

I probably repeat myself, sorry.

>> 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?

That's probably it.

        Hannes