From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: code signing with foreign function interface? Date: Mon, 08 Mar 2010 13:22:48 +0900 Message-ID: <878wa3tpbb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87y6i4xg7y.fsf@lola.goethe.zz> <87bpf0t3am.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1268021568 23314 80.91.229.12 (8 Mar 2010 04:12:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 8 Mar 2010 04:12:48 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 08 05:12:44 2010 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.69) (envelope-from ) id 1NoUKd-0004cg-3T for ged-emacs-devel@m.gmane.org; Mon, 08 Mar 2010 05:12:39 +0100 Original-Received: from localhost ([127.0.0.1]:39510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoUKc-0000Tx-0y for ged-emacs-devel@m.gmane.org; Sun, 07 Mar 2010 23:12:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoUKX-0000Ts-5d for emacs-devel@gnu.org; Sun, 07 Mar 2010 23:12:33 -0500 Original-Received: from [140.186.70.92] (port=49328 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoUKV-0000Tk-Pw for emacs-devel@gnu.org; Sun, 07 Mar 2010 23:12:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NoUKV-0006C1-6o for emacs-devel@gnu.org; Sun, 07 Mar 2010 23:12:31 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:48159) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NoUKS-0006Bj-Ex; Sun, 07 Mar 2010 23:12:28 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id E194B820D; Mon, 8 Mar 2010 13:12:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D98C21A382A; Mon, 8 Mar 2010 13:22:48 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/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:121722 Archived-At: joakim@verona.se writes: > "Stephen J. Turnbull" writes: > > > joakim@verona.se writes: > > > > > - Emacs FFI loads the dll and checks that the desired licensed text in > > > binary form is present, and then proceeds to use the dll. If the text > > > is not present, refuse to proceed. > > > > I don't understand what you hope to accomplish with this. On the one > > side, I don't see how this prevents infringing binary distributions. > > One who is violating the GPL anyway is unlikely to deliberately > > *remove* the key which will surely be present in the sample module he > > derives his code from. > > Aparently I totaly suck at explaining this idea. > > Also I dont quite understand your objection above. AFAICS, it is infringing on copyright of Emacs to deliver a module for Emacs that is not licensed under the GPL or comes without source (or a GPL-permitted alternative to source). I doubt that people who do this would balk at adding a signature, or removing the check from their "value-added" distribution of Emacs, or otherwise finding a way to inhibit it, because "our users demand the convenience". Users really do demand convenience, you know. Users who care more about freedom than convenience generally also want the source up front, and won't need such a check. This means that users would have to check that their copy of Emacs does the checks, and that the modules don't subvert the check as described below. However, with the current policy, if your Emacs has FFI or an on-demand DLL loader, you know that it does not conform to Emacs policy, and you know that the modules you are loading are considered suspect by the FSF. > > On the other, it will interfere with private use of DLLs without the > > key, which (a) is not restricted at all by the GPL, and (b) is very > > likely quite legitimate in the case of older GPLed or LGPLed DLLs (ie, > > all that exist today). > > I didnt mean that existing dynamic linkage would change. I meant to add > a new facility. I know you mean to add a new facility. > Yes. The bit about code signing in my other mail was about that. > The DLL either is delivered with the signature, or the user can add > it. The user shouldnt be able to add it withouth knowing that he is > violating the GPL. But how do you plan to ensure that? Suppose I deliver a module with part of the code in elisp and part in a DLL. `(progn (shell-command "emacs-sign-it /path/to/my-module") (require 'my-module))' and we're golden! no? If the user can do it, so can a program. The only way I can see to prevent this would be to protect the signing utility with a password. Even that can be worked around with a little social engineering: "Installing this module requires your permission under the GPL. Please type your signing password in the following dialog." Users sophisticated enough to see through that are sophisticated enough to demand source in advance; they're not the ones the current policy is (mostly) aimed at protecting. BTW, AFAIK, users can't violate the GPL. Only distributors can. > > So I don't see how it addresses the objections to the use of DLLs > > and/or FFI, while noticeably restricting the exercise of rights > > granted under the GPL. > > It shouldnt, AFAICS. Emacs cannot tell if the user has made an explicit decision to load the module or not, but sometimes will refuse to load the module even though the user definitely wants it loaded (and the user may even know that the module *is* GPL and why that matters). That's a "noticeable" restriction. You may not consider it a big deal, but others might. I don't know, so I used the word "noticeable" rather than "unacceptable". ;-)