code signing with foreign function interface?

code signing with foreign function interface?

[joakim]

The GPL cannot prevent free and non-free code being distributed
together. Therefore a distributor can push GPL non-compliance to an
unknowing user.

If code signing of dynamic libraries is employed, the end-user can be
made aware he is breaking the intentions of the GPL. Would this be
enough to satisfy the requirements for an Emacs FFI?

Recently I was involved in a project which made me understand better why
dynamic linking might be problematic for a free project. Also I didn't
find a mention of this particular approach to an Emacs FFI, so that's why
I (probably mistakenly) bring up this subject again.

Here are some statements the list might want to refute or confirm:

- While DRM is evil, code signing is not in itself.

- Supporting code signing in Emacs should be simple on some platforms,
but maybe not all interesting ones.

- Removing the code-signing check is of course trivial, but no more
trivial than adding a FFI to Emacs withouth checks today.

- We don't necessarily need a complete secure infrastructure for this. A
  simple solution might be to check for the presence of a form of GNU
  license in binary form in the dll. This particular GNU license is
  itself protected by copyright and cannot be combined with other works
  without creating a derived work. This signature might be added
  to an existing dll by code signing. While this is of course
  circumventable, I dont see that it opens any new holes.


-- 
Joakim Verona

Re: code signing with foreign function interface?

[David Kastrup]

joakim@verona.se writes:

> - We don't necessarily need a complete secure infrastructure for
> this. A simple solution might be to check for the presence of a form
> of GNU license in binary form in the dll. This particular GNU license
> is itself protected by copyright and cannot be combined with other
> works without creating a derived work.

Useless:

     Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.

So you can copy the license into any work you like.  The presence of the
GPL as a binary blob is meaningless with regard to licensing.  A book
may also print the GPL without becoming GPLed.

The GPL becomes relevant only when it is made clear that the acquisition
of some software is governed by it.  Its mere presence in some manner is
not more than a pointer.  If it is needed as a key without legal
meaning, that use is perfectly covered by its license.

-- 
David Kastrup

Re: code signing with foreign function interface?

[joakim]

David Kastrup <dak@gnu.org> writes:

> joakim@verona.se writes:
>
>> - We don't necessarily need a complete secure infrastructure for
>> this. A simple solution might be to check for the presence of a form
>> of GNU license in binary form in the dll. This particular GNU license
>> is itself protected by copyright and cannot be combined with other
>> works without creating a derived work.
>
> Useless:
>
>      Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
>      Everyone is permitted to copy and distribute verbatim copies
>      of this license document, but changing it is not allowed.
>
> So you can copy the license into any work you like.  The presence of the
> GPL as a binary blob is meaningless with regard to licensing.  A book
> may also print the GPL without becoming GPLed.
>
> The GPL becomes relevant only when it is made clear that the acquisition
> of some software is governed by it.  Its mere presence in some manner is
> not more than a pointer.  If it is needed as a key without legal
> meaning, that use is perfectly covered by its license.

Ok, I was unclear. I didn't mean that the GPL in itself would be used for
this. I meant another new license, derived from the GPL, but specialized
for this purpose, specifically avoiding the pitfall you describe.

Maybe its still useless, but lets describe each step:

- Define a copyrightable text that might also be used as a binary blob.
this text has a license that allows it to be bundled with other GPL:ed
binary blobs, such as GPL:ed dll:s. Since these dll:s are GPL:ed its ok
to produce a new signed dll with the text in it.

- Sign a dll with this text with some kind of signing tool. Maybe static
  linking will be enough.

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

-- 
Joakim Verona

Re: code signing with foreign function interface?

[Stephen J. Turnbull]

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.

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

And if you're serious about a true FFI that can be called from Lisp,
the situation is even worse: very likely the user wishes to call
routines from a library which doesn't know or care that Emacs exists.

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.

Re: code signing with foreign function interface?

[joakim]

"Stephen J. Turnbull" <stephen@xemacs.org> 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.

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

> And if you're serious about a true FFI that can be called from Lisp,
> the situation is even worse: very likely the user wishes to call
> routines from a library which doesn't know or care that Emacs exists.

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.

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


-- 
Joakim Verona

Re: code signing with foreign function interface?

[Stephen J. Turnbull]

joakim@verona.se writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> 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". ;-)

Re: code signing with foreign function interface?

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> 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". ;-)

Technical protection measures in Free Software appear mostly meaningless
to me since we are talking about an environment where tracing the action
of the protection is quite feasible.  Building a version which just
circumvents any such protection is easy enough, distributing it should
be perfectly within the scope of the GPL.

In short: you land with an approach inconveniencing those users most who
are willing to accept the decisions leading to the technical restriction
measures.  But for those, we don't need the technical restrictions in
the first place.

It does not seem useful to me to inconvenience our friends more than our
opponents with some measure.

-- 
David Kastrup

Re: code signing with foreign function interface?

[joakim]

joakim@verona.se writes:

> David Kastrup <dak@gnu.org> writes:
>
>> joakim@verona.se writes:
>>
>>> - We don't necessarily need a complete secure infrastructure for
>>> this. A simple solution might be to check for the presence of a form
>>> of GNU license in binary form in the dll. This particular GNU license
>>> is itself protected by copyright and cannot be combined with other
>>> works without creating a derived work.
>>
>> Useless:
>>
>>      Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>>      Everyone is permitted to copy and distribute verbatim copies
>>      of this license document, but changing it is not allowed.
>>
>> So you can copy the license into any work you like.  The presence of the
>> GPL as a binary blob is meaningless with regard to licensing.  A book
>> may also print the GPL without becoming GPLed.
>>
>> The GPL becomes relevant only when it is made clear that the acquisition
>> of some software is governed by it.  Its mere presence in some manner is
>> not more than a pointer.  If it is needed as a key without legal
>> meaning, that use is perfectly covered by its license.
>
> Ok, I was unclear. I didn't mean that the GPL in itself would be used for
> this. I meant another new license, derived from the GPL, but specialized
> for this purpose, specifically avoiding the pitfall you describe.
>
> Maybe its still useless, but lets describe each step:
>
> - Define a copyrightable text that might also be used as a binary blob.
> this text has a license that allows it to be bundled with other GPL:ed
> binary blobs, such as GPL:ed dll:s. Since these dll:s are GPL:ed its ok
> to produce a new signed dll with the text in it.
>
> - Sign a dll with this text with some kind of signing tool. Maybe static
>   linking will be enough.
>
> - 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.

Explaining this idea in technical terms wasnt incredibly
productive. Instead, lets ask this question:

- Emacs gets a new FFI facility. When this FFI facility tries to load a
  dll the first time in a session, it asks the user if the dll has a
  valid license. 

That's all. No code signing, no nothing to further prevent the user from
making a mistake. Would this be enough for an Emacs FFI?


-- 
Joakim Verona

Re: code signing with foreign function interface?

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Sun, 07 Mar 2010 07:24:47 +0100
> 
> The GPL cannot prevent free and non-free code being distributed
> together. Therefore a distributor can push GPL non-compliance to an
> unknowing user.
> 
> If code signing of dynamic libraries is employed, the end-user can be
> made aware he is breaking the intentions of the GPL. Would this be
> enough to satisfy the requirements for an Emacs FFI?

Forgive me for asking a possibly dumb question (due to my total
ignorance on this subject): How will you distinguish system libraries
(which are exempt of being under GPL) from the other kind?

Re: code signing with foreign function interface?

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: joakim@verona.se
>> Date: Sun, 07 Mar 2010 07:24:47 +0100
>> 
>> The GPL cannot prevent free and non-free code being distributed
>> together. Therefore a distributor can push GPL non-compliance to an
>> unknowing user.
>> 
>> If code signing of dynamic libraries is employed, the end-user can be
>> made aware he is breaking the intentions of the GPL. Would this be
>> enough to satisfy the requirements for an Emacs FFI?
>
> Forgive me for asking a possibly dumb question (due to my total
> ignorance on this subject): How will you distinguish system libraries
> (which are exempt of being under GPL) from the other kind?

I didnt mean that all dynamic linkage would use this particular
interface.

To exemplify:

- librsvg2.so is dynamically loaded in image.c.  This will be
untouched.

- libmediastreamer2.so, a random dll I want to use, is loaded with the new
  emacs-ffi facility. But oh no! it doesnt have a proper GPL manifest
  signature. I then use a signing tool to add the signature to the .so
  file, and emacs-ffi is now happy.

- now I want to add the signature to a non-free dll. I can do it easily
  but I will feel bad. If I redistribute the wrongly signed non-free dll
  I will be discovered and humiliated.

- Now I want to add the signature to a free dll with some form of hard
  to understand license which isnt GPL compatible. If I redistribute the
  wrongly signed dll I will be discovered and humiliated, this
  time perhaps unjustly.

  
-- 
Joakim Verona

Re: code signing with foreign function interface?

[Richard Stallman]

    If code signing of dynamic libraries is employed, the end-user can be
    made aware he is breaking the intentions of the GPL. Would this be
    enough to satisfy the requirements for an Emacs FFI?

We gave GCC a plug-in interface last year, after developing a method
to make it safer.  So now it is ok to do this in Emacs as well.

I will ask someone to write down the details and put them in the GNU
coding standards.

Re: code signing with foreign function interface?

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     If code signing of dynamic libraries is employed, the end-user can be
>     made aware he is breaking the intentions of the GPL. Would this be
>     enough to satisfy the requirements for an Emacs FFI?
>
> We gave GCC a plug-in interface last year, after developing a method
> to make it safer.  So now it is ok to do this in Emacs as well.
>
> I will ask someone to write down the details and put them in the GNU
> coding standards.

Sounds great, thanks!

-- 
Joakim Verona

Re: code signing with foreign function interface?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> We gave GCC a plug-in interface last year, after developing a method
> to make it safer.  So now it is ok to do this in Emacs as well.
>
> I will ask someone to write down the details and put them in the GNU
> coding standards.

Excellent!

[Hmm, I guess the details are probably on the gcc website somewhere too...]

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: code signing with foreign function interface?

[Stephen Berman]

On Mon, 08 Mar 2010 17:24:00 +0900 Miles Bader <miles@gnu.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
>> We gave GCC a plug-in interface last year, after developing a method
>> to make it safer.  So now it is ok to do this in Emacs as well.
>>
>> I will ask someone to write down the details and put them in the GNU
>> coding standards.
>
> Excellent!
>
> [Hmm, I guess the details are probably on the gcc website somewhere too...]
>
> -Miles

Here, I guess: http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

Steve Berman

Re: code signing with foreign function interface?

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Mon, 08 Mar 2010 10:02:07 +0100
> 
> On Mon, 08 Mar 2010 17:24:00 +0900 Miles Bader <miles@gnu.org> wrote:
> 
> > Richard Stallman <rms@gnu.org> writes:
> >> We gave GCC a plug-in interface last year, after developing a method
> >> to make it safer.  So now it is ok to do this in Emacs as well.
> >>
> >> I will ask someone to write down the details and put them in the GNU
> >> coding standards.
> >
> > Excellent!
> >
> > [Hmm, I guess the details are probably on the gcc website somewhere too...]
> >
> > -Miles
> 
> Here, I guess: http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

Thanks.

This is part of the "GCC Internals" manual that gets installed with
GCC.  So no need to go to any Web site.

Re: code signing with foreign function interface?

[Stefan Monnier]

>     If code signing of dynamic libraries is employed, the end-user can be
>     made aware he is breaking the intentions of the GPL. Would this be
>     enough to satisfy the requirements for an Emacs FFI?

> We gave GCC a plug-in interface last year, after developing a method
> to make it safer.  So now it is ok to do this in Emacs as well.

Sounds wonderful.

So if I understand http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
correctly, all we have to do is to check that the dynamically loaded
object defines a global symbol "plugin_is_GPL_compatible"?


        Stefan

Re: code signing with foreign function interface?

[Richard Stallman]

    So if I understand http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
    correctly, all we have to do is to check that the dynamically loaded
    object defines a global symbol "plugin_is_GPL_compatible"?

I am not sure that page accurately describes all that we need to do.
So please don't jump the gun.  I am having people check this.