From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Johannes Weiner Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Tue, 19 Aug 2008 13:56:36 +0200 Message-ID: <873al18bgr.fsf@skyscraper.fehenstaub.lan> References: <48A740CB.4050404@emf.net> <20080816213508.GA8530@muc.de> <87hc9ka8eg.fsf@uwakimon.sk.tsukuba.ac.jp> <20080817073124.GA1294@muc.de> <87ljyv5gy5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818101802.GA2615@muc.de> <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818210927.GD2615@muc.de> <87vdxx9a5k.fsf@skyscraper.fehenstaub.lan> <20080819102354.GA5137@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219147058 32184 80.91.229.12 (19 Aug 2008 11:57:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Aug 2008 11:57:38 +0000 (UTC) Cc: "Stephen J. Turnbull" , rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 19 13:58:30 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KVPql-0000xW-4W for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 13:58:11 +0200 Original-Received: from localhost ([127.0.0.1]:41217 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVPpn-00065X-Vq for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 07:57:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVPpj-000658-GU for emacs-devel@gnu.org; Tue, 19 Aug 2008 07:57:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVPpi-00064w-PO for emacs-devel@gnu.org; Tue, 19 Aug 2008 07:57:06 -0400 Original-Received: from [199.232.76.173] (port=56219 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVPpi-00064t-Mj for emacs-devel@gnu.org; Tue, 19 Aug 2008 07:57:06 -0400 Original-Received: from saeurebad.de ([85.214.36.134]:53300) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVPpe-0005fc-0f; Tue, 19 Aug 2008 07:57:02 -0400 Original-Received: by saeurebad.de (Postfix, from userid 107) id 753732F00CA; Tue, 19 Aug 2008 13:56:58 +0200 (CEST) Original-Received: from localhost (217-68-166-87.dynamic.primacom.net [217.68.166.87]) by saeurebad.de (Postfix) with ESMTP id 90C1D2F00C6; Tue, 19 Aug 2008 13:56:57 +0200 (CEST) In-Reply-To: <20080819102354.GA5137@muc.de> (Alan Mackenzie's message of "Tue, 19 Aug 2008 10:23:54 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102644 Archived-At: Hi, Alan! Alan Mackenzie writes: > Hi, Johannes! > > On Tue, Aug 19, 2008 at 01:27:19AM +0200, Johannes Weiner wrote: >> Hi, > >> Alan Mackenzie 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 # 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