* Re: Another update of GNU TLS bindings [not found] <iluofj6a0j9.fsf@dhcp133.extundo.com> @ 2002-02-07 14:56 ` Richard Stallman 2002-02-21 14:32 ` William M. Perry [not found] ` <200202040736.JAA08217@is.elta.co.il> 1 sibling, 1 reply; 16+ messages in thread From: Richard Stallman @ 2002-02-07 14:56 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-07 14:56 ` Another update of GNU TLS bindings Richard Stallman @ 2002-02-21 14:32 ` William M. Perry 0 siblings, 0 replies; 16+ messages in thread From: William M. Perry @ 2002-02-21 14:32 UTC (permalink / raw) Cc: jas, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <200202040736.JAA08217@is.elta.co.il>]
* Re: Another update of GNU TLS bindings [not found] ` <200202040736.JAA08217@is.elta.co.il> @ 2002-02-07 14:58 ` Richard Stallman 2002-02-07 17:36 ` Simon Josefsson 0 siblings, 1 reply; 16+ messages in thread From: Richard Stallman @ 2002-02-07 14:58 UTC (permalink / raw) Cc: jas, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-07 14:58 ` Richard Stallman @ 2002-02-07 17:36 ` Simon Josefsson 2002-02-08 23:23 ` Richard Stallman 2002-02-10 5:17 ` Richard Stallman 0 siblings, 2 replies; 16+ messages in thread From: Simon Josefsson @ 2002-02-07 17:36 UTC (permalink / raw) Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-07 17:36 ` Simon Josefsson @ 2002-02-08 23:23 ` Richard Stallman 2002-02-09 12:29 ` Simon Josefsson 2002-02-10 5:17 ` Richard Stallman 1 sibling, 1 reply; 16+ messages in thread From: Richard Stallman @ 2002-02-08 23:23 UTC (permalink / raw) Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-08 23:23 ` Richard Stallman @ 2002-02-09 12:29 ` Simon Josefsson 2002-02-11 2:08 ` Richard Stallman 0 siblings, 1 reply; 16+ messages in thread From: Simon Josefsson @ 2002-02-09 12:29 UTC (permalink / raw) Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-09 12:29 ` Simon Josefsson @ 2002-02-11 2:08 ` Richard Stallman 2002-02-13 8:50 ` Florian Weimer 0 siblings, 1 reply; 16+ messages in thread From: Richard Stallman @ 2002-02-11 2:08 UTC (permalink / raw) Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-11 2:08 ` Richard Stallman @ 2002-02-13 8:50 ` Florian Weimer 0 siblings, 0 replies; 16+ messages in thread From: Florian Weimer @ 2002-02-13 8:50 UTC (permalink / raw) Cc: jas, eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-07 17:36 ` Simon Josefsson 2002-02-08 23:23 ` Richard Stallman @ 2002-02-10 5:17 ` Richard Stallman 1 sibling, 0 replies; 16+ messages in thread From: Richard Stallman @ 2002-02-10 5:17 UTC (permalink / raw) Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <Pine.LNX.4.44.0202220939320.7021-100000@yxa.extundo.com>]
* Re: Another update of GNU TLS bindings [not found] <Pine.LNX.4.44.0202220939320.7021-100000@yxa.extundo.com> @ 2002-02-23 20:21 ` Richard Stallman 2002-02-23 20:27 ` Simon Josefsson 0 siblings, 1 reply; 16+ messages in thread From: Richard Stallman @ 2002-02-23 20:21 UTC (permalink / raw) Cc: wmperry, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-23 20:21 ` Richard Stallman @ 2002-02-23 20:27 ` Simon Josefsson 2002-02-24 17:58 ` Richard Stallman 0 siblings, 1 reply; 16+ messages in thread From: Simon Josefsson @ 2002-02-23 20:27 UTC (permalink / raw) Cc: wmperry, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-23 20:27 ` Simon Josefsson @ 2002-02-24 17:58 ` Richard Stallman 2002-02-24 18:18 ` Simon Josefsson 0 siblings, 1 reply; 16+ messages in thread From: Richard Stallman @ 2002-02-24 17:58 UTC (permalink / raw) Cc: wmperry, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-24 17:58 ` Richard Stallman @ 2002-02-24 18:18 ` Simon Josefsson 2002-02-25 16:23 ` Richard Stallman 0 siblings, 1 reply; 16+ messages in thread From: Simon Josefsson @ 2002-02-24 18:18 UTC (permalink / raw) Cc: wmperry, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-24 18:18 ` Simon Josefsson @ 2002-02-25 16:23 ` Richard Stallman 2002-02-25 20:34 ` Simon Josefsson 0 siblings, 1 reply; 16+ messages in thread From: Richard Stallman @ 2002-02-25 16:23 UTC (permalink / raw) Cc: wmperry, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-25 16:23 ` Richard Stallman @ 2002-02-25 20:34 ` Simon Josefsson 2002-02-26 20:15 ` Richard Stallman 0 siblings, 1 reply; 16+ messages in thread From: Simon Josefsson @ 2002-02-25 20:34 UTC (permalink / raw) Cc: wmperry, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Another update of GNU TLS bindings 2002-02-25 20:34 ` Simon Josefsson @ 2002-02-26 20:15 ` Richard Stallman 0 siblings, 0 replies; 16+ messages in thread From: Richard Stallman @ 2002-02-26 20:15 UTC (permalink / raw) Cc: wmperry, emacs-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-02-26 20:15 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <iluofj6a0j9.fsf@dhcp133.extundo.com>
2002-02-07 14:56 ` Another update of GNU TLS bindings Richard Stallman
2002-02-21 14:32 ` William M. Perry
[not found] ` <200202040736.JAA08217@is.elta.co.il>
2002-02-07 14:58 ` Richard Stallman
2002-02-07 17:36 ` Simon Josefsson
2002-02-08 23:23 ` Richard Stallman
2002-02-09 12:29 ` Simon Josefsson
2002-02-11 2:08 ` Richard Stallman
2002-02-13 8:50 ` Florian Weimer
2002-02-10 5:17 ` Richard Stallman
[not found] <Pine.LNX.4.44.0202220939320.7021-100000@yxa.extundo.com>
2002-02-23 20:21 ` Richard Stallman
2002-02-23 20:27 ` Simon Josefsson
2002-02-24 17:58 ` Richard Stallman
2002-02-24 18:18 ` Simon Josefsson
2002-02-25 16:23 ` Richard Stallman
2002-02-25 20:34 ` Simon Josefsson
2002-02-26 20:15 ` Richard Stallman
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).