unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: joakim@verona.se
To: Emacs development discussions <emacs-devel@gnu.org>
Subject: code signing with foreign function interface?
Date: Sun, 07 Mar 2010 07:24:47 +0100	[thread overview]
Message-ID: <m3y6i46440.fsf@verona.se> (raw)

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




             reply	other threads:[~2010-03-07  6:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-07  6:24 joakim [this message]
2010-03-07 16:13 ` code signing with foreign function interface? David Kastrup
2010-03-07 17:05   ` joakim
2010-03-07 18:06     ` Stephen J. Turnbull
2010-03-07 19:19       ` joakim
2010-03-08  4:22         ` Stephen J. Turnbull
2010-03-08  8:01           ` David Kastrup
2010-03-08  7:41     ` joakim
2010-03-07 18:04 ` Eli Zaretskii
2010-03-07 19:39   ` joakim
2010-03-08  8:04 ` Richard Stallman
2010-03-08  8:15   ` joakim
2010-03-08  8:24   ` Miles Bader
2010-03-08  9:02     ` Stephen Berman
2010-03-08  9:12       ` Eli Zaretskii
2010-03-08 15:20   ` Stefan Monnier
2010-03-09  3:18     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3y6i46440.fsf@verona.se \
    --to=joakim@verona.se \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).