Re: Another update of GNU TLS bindings

Re: Another update of GNU TLS bindings

[Richard Stallman]

We don't have papers for ssl.el.  And it is not certain that
we want to distribute it in Emacs; it might be better to include
it in the GNUTLS distribution.

William, could you ask assign@gnu.org for a separate assignment
of ssl.el as a separate program?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

I am wondering if there is any way of generalizing the C code
so that it is not specific to GNUTLS or to encryption, and putting
all encryption-specific code into Lisp.  This would eliminate some
legal issues for those who redistribute Emacs in or from the US.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

> I am wondering if there is any way of generalizing the C code
> so that it is not specific to GNUTLS or to encryption, and putting
> all encryption-specific code into Lisp.

XEmacs has a "Foreign Function Interface" that allows loading shared
objects dynamically and creating lisp API to the C functions.
However, the integration with Lisp_Process (same Lisp functions to
read and write to processes) seems difficult to achieve with that
approach.

There might even be patches for Emacs to achieve this, I remember
discussions about this feature during early Emacs 20.x but nothing
came out of it.

> This would eliminate some legal issues for those who redistribute
> Emacs in or from the US.

Are these real concerns?  As far as I understand, the laws regarding
crypto export and free software has been lifted.  Other free software
projects seem to use crypto as well (e.g., GNU Wget that links with
OpenSSL which isn't GPL, but usually considered a "system library").


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

    Are these real concerns?  As far as I understand, the laws regarding
    crypto export and free software has been lifted.  Other free software
    projects seem to use crypto as well (e.g., GNU Wget that links with
    OpenSSL which isn't GPL, but usually considered a "system library").

The GPL does not actually say "system library"; that is a way of
referring to a more precise criterion which OpenSSL clearly does not
fit.

I will have to write to the wget developer about this.  Thanks for
reporting the problem.  Do you know of any others?


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     Are these real concerns?  As far as I understand, the laws regarding
>     crypto export and free software has been lifted.  Other free software
>     projects seem to use crypto as well (e.g., GNU Wget that links with
>     OpenSSL which isn't GPL, but usually considered a "system library").
>
> The GPL does not actually say "system library"; that is a way of
> referring to a more precise criterion which OpenSSL clearly does not
> fit.
>
> I will have to write to the wget developer about this.  Thanks for
> reporting the problem.  Do you know of any others?

Not on top of my head, but could you please explain why you think this
is a problem?

Several network related GNU projects will be inadequate, to the point
of being useless and even dangerous to use, if they don't support
crypto; projects that come to mind, other than emacs, are adns,
httptunnel, mailman, and zebra.  Not to mention GNUPG and GNU TLS
which solely deal with security.  I guess the network code in Hurd
need to support IPSEC etc to be useful as well.

Naturally, it would be good if GNU projects used GNU libraries for
secure communication, but since there hasn't been any until recently
and that OpenSSL still is alot more mature and tested it doesn't seem
unreasonable to use it until someone offers help to port applications
to GNU TLS.  Compare the situation with how Emacs links with non-GPL
libraries, for widgets and graphics right now.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

    XEmacs has a "Foreign Function Interface" that allows loading shared
    objects dynamically and creating lisp API to the C functions.

We could have such an interface and use it with static linking.  Emacs
really does not need to know much about a file foobar.c in order to
link with it and get it to define Lisp functions and variables.  It
just has to arrange to call syms_of_foobar somehow.

    However, the integration with Lisp_Process (same Lisp functions to
    read and write to processes) seems difficult to achieve with that
    approach.

Yes, I can see why.  But maybe you can generalize your changes to
Lisp_Process and process.c so they could serve a variety of purposes.
What do you think of that idea?

    > This would eliminate some legal issues for those who redistribute
    > Emacs in or from the US.

    Are these real concerns?  As far as I understand, the laws regarding
    crypto export and free software has been lifted.

Not 100%.  There are requirements to notify the government about
distribution sites.  These are not crushing burden but they are
something people could easily forget.  Also, the US might someday
impose new requirements and might try to impose them on redistribution
outside the US of anything that was first exported from the US.
It is a good idea to keep the incidence of crypto limited to fewer
packages rather than more.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

    Not on top of my head, but could you please explain why you think this
    is a problem?

The GPL does not permit linking with OpenSSL.

    Several network related GNU projects will be inadequate, to the point
    of being useless and even dangerous to use, if they don't support
    crypto; projects that come to mind, other than emacs, are adns,
    httptunnel, mailman, and zebra.

What has that got to do with wget and OpenSSL?
I see no connection.  Do these programs use OpenSSL?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Florian Weimer]

Richard Stallman <rms@gnu.org> writes:

>     Not on top of my head, but could you please explain why you think this
>     is a problem?
>
> The GPL does not permit linking with OpenSSL.

Hmm, the GPL does not permit linking with OpenSSL und *redistributing*
the resulting binary, does it?

>     Several network related GNU projects will be inadequate, to the point
>     of being useless and even dangerous to use, if they don't support
>     crypto; projects that come to mind, other than emacs, are adns,
>     httptunnel, mailman, and zebra.
>
> What has that got to do with wget and OpenSSL?
> I see no connection.  Do these programs use OpenSSL?

At least Mailman doesn't use it directly, only directly via the web
server under which it is running.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[William M. Perry]

Richard Stallman <rms@gnu.org> writes:

> We don't have papers for ssl.el.  And it is not certain that we want to
> distribute it in Emacs; it might be better to include it in the GNUTLS
> distribution.

I thought it would fall under the generic assignment I signed.  I am in the
midst of getting my paperwork back up to date - I'll do an assignment for
ssl.el explicitly at the same time.

-bp
-- 
Ceterum censeo vi esse delendam

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

    Wouldn't GNUTLS be a surprising place to find ssl.el? Wmperry's ssl.el
    invokes OpenSSL (`start-process').

We will want to change it to use GNUTLS, that being our replacement
for OpenSSL.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     Wouldn't GNUTLS be a surprising place to find ssl.el? Wmperry's ssl.el
>     invokes OpenSSL (`start-process').
>
> We will want to change it to use GNUTLS, that being our replacement
> for OpenSSL.

It does use GNUTLS, but since GNUTLS is a compile time option, it
cannot be assumed to be available.  Hence the addition of ssl.el which
invokes OpenSSL as a fallback if GNUTLS was not compiled with Emacs.
If GNUTLS is compiled into Emacs, OpenSSL is never used.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

    It does use GNUTLS, but since GNUTLS is a compile time option, it
    cannot be assumed to be available.  Hence the addition of ssl.el which
    invokes OpenSSL as a fallback if GNUTLS was not compiled with Emacs.

How does it invoke OpenSSL (when it does)?  Why can't it invoke
GNUTLS the same way?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     It does use GNUTLS, but since GNUTLS is a compile time option, it
>     cannot be assumed to be available.  Hence the addition of ssl.el which
>     invokes OpenSSL as a fallback if GNUTLS was not compiled with Emacs.
>
> How does it invoke OpenSSL (when it does)?

With `start-process'.

> Why can't it invoke GNUTLS the same way?

GNUTLS is a library, OpenSSL is both a library and an application.
William's ssl.el invokes the binary.  This is a inflexible method, it
is complicated to find out what algorithms chosed during the TLS
handshake, and generally difficult to do anything interactive during
the TLS handshake.

Even if GNUTLS shipped with a binary allowing it to do all the things
OpenSSL currently does, it would not be satisfactory.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

    GNUTLS is a library, OpenSSL is both a library and an application.
    William's ssl.el invokes the binary.  This is a inflexible method, it
    is complicated to find out what algorithms chosed during the TLS
    handshake, and generally difficult to do anything interactive during
    the TLS handshake.

I see why that method is not as flexible.  But it is nonetheless a
useful alternative.  If OpenSSL can do it, why can't we do it?

    Even if GNUTLS shipped with a binary allowing it to do all the things
    OpenSSL currently does, it would not be satisfactory.

Would this method be less satisfactory for GNUTLS than it is for OpenSSL?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     GNUTLS is a library, OpenSSL is both a library and an application.
>     William's ssl.el invokes the binary.  This is a inflexible method, it
>     is complicated to find out what algorithms chosed during the TLS
>     handshake, and generally difficult to do anything interactive during
>     the TLS handshake.
>
> I see why that method is not as flexible.  But it is nonetheless a
> useful alternative.  If OpenSSL can do it, why can't we do it?

I am sure "we" as in the GNUTLS developer can do it.  Should I forward
this request to them?  I agree it would be a useful feature.  It might
even be on their todo list.  However, I'm not sure this would be
useful for Emacs though, because using it would only move us to the
same level as we have with the current OpenSSL support.

>     Even if GNUTLS shipped with a binary allowing it to do all the things
>     OpenSSL currently does, it would not be satisfactory.
>
> Would this method be less satisfactory for GNUTLS than it is for OpenSSL?

No, it would be the same. However this method is generally
unsatisfactory.  That is what prompted me to write the GNUTLS bindings
for Emacs.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Another update of GNU TLS bindings

[Richard Stallman]

    I am sure "we" as in the GNUTLS developer can do it.  Should I forward
    this request to them?

Please do.

      However, I'm not sure this would be
    useful for Emacs though, because using it would only move us to the
    same level as we have with the current OpenSSL support.

It would certainly be useful for Emacs to be able to use GNUTLS in the
same way it can use OpenSSL.  Much better than being *unable* to use
GNUTLS in the same way.

      That is what prompted me to write the GNUTLS bindings
    for Emacs.

Technically, installing those changes is a good idea.  (However, it
would still be a good feature if Emacs can use GNUTLS even if it was
not compiled to use GNUTLS.)

Given the authoritarian climate, and the restrictions now being
proposed in the UK, I think it is desirable to keep crypto code
to the smallest possible number of packages.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel