GnuTLS/TLS proposals for after the release

GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

Here are some thoughts about the near future of gnutls.el and friends
(none urgently needed for the release):

1) Proposal: after the 25.1 release, opening a secure network connection
without `gnutls-available-p' should be an annoying warning. The
alternative (tls.el) is less secure and IMHO should be discouraged.

2) I am concerned that SSLv3 is explicitly in the tls.el defaults. See
http://disablessl3.com/ for why, no need to write up all the reasons
here. I propose to cut those lines out.

3) refactor gnutls.el a bit to support per-host settings more easily:
`gnutls-algorithm-priority', `gnutls-verify-error', `gnutls-trustfiles',
and `gnutls-min-prime-bits' all have different kinds of customizations.
For instance `gnutls-verify-error' can be global or per host regex,
while `gnutls-trustfiles' can be a function. This mish-mash reflects the
staggered work on that library over the years.

I propose a single variable, `gnutls-settings' which can be set per host
regex or globally, and which can contain an alist or plist specifying
each of the settings above as a string/string list or as a function.
Basically a unified view of all GnuTLS-related connectivity settings
instead of scattering them over several variables. I think in Customize
that will look nicer and more friendly, plus the code will be simplified.

If proposal 3 is accepted, the old variables will be accepted for some
time, deprecated later, and finally killed off. It won't be a sudden
transition.

Thanks
Ted

Re: GnuTLS/TLS proposals for after the release

[John Wiegley]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

> Here are some thoughts about the near future of gnutls.el and friends (none
> urgently needed for the release):

Ted, can you, or someone with more experience in this area, help me to
understand these alternatives? If we are all generally agreed on one over the
others, I'm willing to go with the wisdom of consensus.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Tue, 05 Jul 2016 17:32:59 -0700 John Wiegley <jwiegley@gmail.com> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Here are some thoughts about the near future of gnutls.el and friends (none
>> urgently needed for the release):

JW> Ted, can you, or someone with more experience in this area, help me to
JW> understand these alternatives? If we are all generally agreed on one over the
JW> others, I'm willing to go with the wisdom of consensus.

These are three separate proposals, not alternatives of each other.

They have different purposes: (1) is to make tls.el, which uses
command-line tunnels, more noisy by default, so users are led to the C
bindings to GnuTLS (gnutls.el). (2) is to disable SSLv3 in tls.el. (3)
is to change the variables in gnutls.el a bit to make customization and
future work easier. (3) is the only risky one because it affects user
customizations, but I think we have to bite that buller sooner or later.

There are several people who have worked in this area besides me, mainly
Lars and Paul Eggert I think. I asked Lars about (3) already but haven't
heard back. Any comments are welcome, of course.

Ted

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Wed, 06 Jul 2016 08:21:44 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Tue, 05 Jul 2016 17:32:59 -0700 John Wiegley <jwiegley@gmail.com> wrote: 
>>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> Here are some thoughts about the near future of gnutls.el and friends (none
>>> urgently needed for the release):

JW> Ted, can you, or someone with more experience in this area, help me to
JW> understand these alternatives? If we are all generally agreed on one over the
JW> others, I'm willing to go with the wisdom of consensus.

TZ> These are three separate proposals, not alternatives of each other.

TZ> They have different purposes: (1) is to make tls.el, which uses
TZ> command-line tunnels, more noisy by default, so users are led to the C
TZ> bindings to GnuTLS (gnutls.el). (2) is to disable SSLv3 in tls.el. (3)
TZ> is to change the variables in gnutls.el a bit to make customization and
TZ> future work easier. (3) is the only risky one because it affects user
TZ> customizations, but I think we have to bite that buller sooner or later.

TZ> There are several people who have worked in this area besides me, mainly
TZ> Lars and Paul Eggert I think. I asked Lars about (3) already but haven't
TZ> heard back. Any comments are welcome, of course.

In support of (1) and (2), see
http://permalink.gmane.org/gmane.emacs.devel/200356 (thread:
http://comments.gmane.org/gmane.linux.debian.devel.bugs.general/1203642 )
where Lars and Kurt discussed the dangerously outdated state of
s_client invocation strings. So some work in that direction has already
been done; I'm just proposing to continue it.

Ted

Re: GnuTLS/TLS proposals for after the release

[John Wiegley]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

> They have different purposes: (1) is to make tls.el, which uses command-line
> tunnels, more noisy by default, so users are led to the C bindings to GnuTLS
> (gnutls.el). (2) is to disable SSLv3 in tls.el. (3) is to change the
> variables in gnutls.el a bit to make customization and future work easier.
> (3) is the only risky one because it affects user customizations, but I
> think we have to bite that buller sooner or later.

OK. Does anyone else have a reason to object to these changes?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: GnuTLS/TLS proposals for after the release

[Robert Pluim]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> They have different purposes: (1) is to make tls.el, which uses command-line
>> tunnels, more noisy by default, so users are led to the C bindings to GnuTLS
>> (gnutls.el). (2) is to disable SSLv3 in tls.el. (3) is to change the
>> variables in gnutls.el a bit to make customization and future work easier.
>> (3) is the only risky one because it affects user customizations, but I
>> think we have to bite that buller sooner or later.
>
> OK. Does anyone else have a reason to object to these changes?

rfc7568 says, with good reason:

>3.  Do Not Use SSL Version 3.0
>
>   SSLv3 MUST NOT be used.  Negotiation of SSLv3 from any version of TLS
>   MUST NOT be permitted.

so I definitely vote for disabling SSLv3 (and rapidly deprecating
tls.el)

Robert

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Wed, 06 Jul 2016 10:44:43 -0700 John Wiegley <jwiegley@gmail.com> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> They have different purposes: (1) is to make tls.el, which uses command-line
>> tunnels, more noisy by default, so users are led to the C bindings to GnuTLS
>> (gnutls.el). (2) is to disable SSLv3 in tls.el. (3) is to change the
>> variables in gnutls.el a bit to make customization and future work easier.
>> (3) is the only risky one because it affects user customizations, but I
>> think we have to bite that buller sooner or later.

JW> OK. Does anyone else have a reason to object to these changes?

We seem to have aceptance of this for the next release.

Should we enact (2) now, before the upcoming RC?

I understand the risk to the release, but OTOH there's a significant
risk to our users from shipping with an insecure setting by default.

I'm neutral on this, sorry...

Thanks
Ted

Re: GnuTLS/TLS proposals for after the release

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:

TZ> We seem to have aceptance of this for the next release.
TZ> Should we enact (2) now, before the upcoming RC?

TZ> I understand the risk to the release, but OTOH there's a significant risk
TZ> to our users from shipping with an insecure setting by default.

I think it's far too late for that. Eli?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: GnuTLS/TLS proposals for after the release

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 12 Jul 2016 15:03:31 -0700
> 
> >>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
> 
> TZ> We seem to have aceptance of this for the next release.
> TZ> Should we enact (2) now, before the upcoming RC?
> 
> TZ> I understand the risk to the release, but OTOH there's a significant risk
> TZ> to our users from shipping with an insecure setting by default.
> 
> I think it's far too late for that. Eli?

Yes, I agree: far too late.  Changing that is likely to trigger
non-trivial problems, and we would like to make an RC in a few days.

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Wed, 13 Jul 2016 17:26:42 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: John Wiegley <jwiegley@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>
>> Date: Tue, 12 Jul 2016 15:03:31 -0700
>> 
>> >>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
TZ> We seem to have aceptance of this for the next release.
TZ> Should we enact (2) now, before the upcoming RC?
>> 
TZ> I understand the risk to the release, but OTOH there's a significant risk
TZ> to our users from shipping with an insecure setting by default.
>> 
>> I think it's far too late for that. Eli?

EZ> Yes, I agree: far too late.  Changing that is likely to trigger
EZ> non-trivial problems, and we would like to make an RC in a few days.

Works for me, thanks for letting me know.

Ted

Re: GnuTLS/TLS proposals for after the release

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> 1) Proposal: after the 25.1 release, opening a secure network connection
> without `gnutls-available-p' should be an annoying warning. The
> alternative (tls.el) is less secure and IMHO should be discouraged.

I agree.

And I think the FSF distribution page for the prebuilt binaries on all
platforms should link to binaries that come with a complete set of
libraries needed to run Emacs in a secure manner.  (Mostly relevant for
the Windows distribution.)

> 2) I am concerned that SSLv3 is explicitly in the tls.el defaults. See
> http://disablessl3.com/ for why, no need to write up all the reasons
> here. I propose to cut those lines out.

That's fine with me, but if it's deprecated, then it probably doesn't
matter much.  :-)

> I propose a single variable, `gnutls-settings' which can be set per host
> regex or globally, and which can contain an alist or plist specifying
> each of the settings above as a string/string list or as a function.
> Basically a unified view of all GnuTLS-related connectivity settings
> instead of scattering them over several variables. I think in Customize
> that will look nicer and more friendly, plus the code will be simplified.

Yes, this sounds nice.  The only slightly worrying thing from a user
perspective is that we'd then have two layers of settings/exceptions per
host -- one from `gnutls-settings', and one from the Network Security
Manager.  This may confuse some users, but the extra power
`gnutls-settings' would give us might outweigh that slight problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: GnuTLS/TLS proposals for after the release

[Stefan Monnier]

> And I think the FSF distribution page for the prebuilt binaries on all
> platforms should link to binaries that come with a complete set of
> libraries needed to run Emacs in a secure manner.  (Mostly relevant for
> the Windows distribution.)

Another step in the same direction is to make ./configure fail if
libgnutls is not found.


        Stefan

Compressing ELPA (was: GnuTLS/TLS proposals for after the release)

[Stefan Monnier]

> Another step in the same direction is to make ./configure fail if
> libgnutls is not found.

Along the same lines, it'd be good to require the presence of
a decompressor, so that we can start compressing the ELPA archives.
Distributing files as .el or .tar is a waste of disk space and
network bandwidth.

I know in theory we could have the web server de-compress the files on
the fly if/when the client doesn't support compression, but somehow
I wasn't able to make this work
(http://stackoverflow.com/questions/26895894/get-apache-to-auto-decompress-a-file-but-only-if-needed).


        Stefan

Re: Compressing ELPA

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

SM> Distributing files as .el or .tar is a waste of disk space and network
SM> bandwidth.

We're just talking about kilobytes of waste, right?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Compressing ELPA

[Rostislav Svoboda]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

> SM> Distributing files as .el or .tar is a waste of disk space and network
> SM> bandwidth.
>
> We're just talking about kilobytes of waste, right?

I have a habit of upgrading my packages on everyday basis.
In my case - it's not about wasting disk space nor network bandwidth.
The (total upgrade) time is the valuable resource I'm lacking.

[-- Attachment #2: Type: text/html, Size: 456 bytes --]

Re: Compressing ELPA

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Tue, Aug 2, 2016 at 6:04 PM, Rostislav Svoboda <
rostislav.svoboda@gmail.com> wrote:

> > SM> Distributing files as .el or .tar is a waste of disk space and
> network
> > SM> bandwidth.
>

​If you do change the way this works for ELPA, please also change it for
package-x.el, i.e. the default way of uploading/distributing packages.  It
would ease maintainer burdens if there was a single, consistent way of
preparing packages for distribution regardless of the archive to be used.

Bob

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

Re: Compressing ELPA

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 820 bytes --]

On 2016-07-20 09:00, Stefan Monnier wrote:
> I know in theory we could have the web server de-compress the files on
> the fly if/when the client doesn't support compression, but somehow
> I wasn't able to make this work
> (http://stackoverflow.com/questions/26895894/get-apache-to-auto-decompress-a-file-but-only-if-needed).

Couldn't you do it the other way around? That is, could the files be stored uncompressed on the server, and could the compression be taken care of by the server itself, when requests arrive? (Isn't that the standard way to do things?)

Looking at headers, it seems that on my machine package.el already sends (via url) the right header:
  Accept-encoding: gzip

And yet the server returns a plain file (that is, I'm not seeing Content-Encoding: gzip) in the response.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Compressing ELPA

[Stefan Monnier]

>> I know in theory we could have the web server de-compress the files on
>> the fly if/when the client doesn't support compression, but somehow
>> I wasn't able to make this work
>> (http://stackoverflow.com/questions/26895894/get-apache-to-auto-decompress-a-file-but-only-if-needed).

> Couldn't you do it the other way around? That is, could the files be stored
> uncompressed on the server, and could the compression be taken care of by
> the server itself, when requests arrive?

It would be the next best thing (storing the files uncompressed is
silly), yes.

> (Isn't that the standard way to do things?)

For tarballs, I highly doubt it.  It's often faster to pack and unpack
a compressed tarball than an uncompressed one (because (de)compression
is faster than disk access), so there's really no advantage to ever
manipulate an uncompressed tarball, in the usual case.

In any case, any help configugin the webserver to get something like
that would be welcome.


        Stefan

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Wed, 20 Jul 2016 08:52:54 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> And I think the FSF distribution page for the prebuilt binaries on all
>> platforms should link to binaries that come with a complete set of
>> libraries needed to run Emacs in a secure manner.  (Mostly relevant for
>> the Windows distribution.)

SM> Another step in the same direction is to make ./configure fail if
SM> libgnutls is not found.

That's a one-line change IIRC, so it just needs the OK from John or Eli
(since it's a pretty major change). I am strongly in favor, of course.

Ted

Re: GnuTLS/TLS proposals for after the release

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On 07/20/2016 03:14 PM, Ted Zlatanov wrote:
> SM> Another step in the same direction is to make ./configure fail if
> SM> libgnutls is not found.
>
> That's a one-line change IIRC, so it just needs the OK from John or Eli
> (since it's a pretty major change).

It's not that big a deal to treat libgnutls like other key libraries. 
Namely, 'configure' fails if the library is missing, unless you 
specifically say you don't want the library by configuring with the 
--with-gnutls=no option. Something like the attached patch, say.


[-- Attachment #2: 0001-Require-libgnutls-unless-with-gnutls-no.patch --]
[-- Type: text/x-patch, Size: 1677 bytes --]

From 5f508198cd31afd08c3a50af6c7fb38ed65992cc Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 20 Jul 2016 16:18:34 +0200
Subject: [PATCH] Require libgnutls unless --with-gnutls=no

* configure.ac: Report an error if the gnutls library is missing,
unless --with-gnutls=no is specified.
---
 configure.ac | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index c94ecb6..cca555c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3568,9 +3568,9 @@ AC_DEFUN
 AC_SUBST(LIBGIF)
 
 dnl Check for required libraries.
+MISSING=
+WITH_NO=
 if test "${HAVE_X11}" = "yes"; then
-  MISSING=""
-  WITH_NO=""
   test "${with_xpm}" != "no" && test "${HAVE_XPM}" != "yes" &&
     MISSING="libXpm" && WITH_NO="--with-xpm=no"
   test "${with_jpeg}" != "no" && test "${HAVE_JPEG}" != "yes" &&
@@ -3581,15 +3581,16 @@ AC_DEFUN
     MISSING="$MISSING libgif/libungif" && WITH_NO="$WITH_NO --with-gif=no"
   test "${with_tiff}" != "no" && test "${HAVE_TIFF}" != "yes" &&
     MISSING="$MISSING libtiff" && WITH_NO="$WITH_NO --with-tiff=no"
-
-  if test "X${MISSING}" != X; then
-    AC_MSG_ERROR([The following required libraries were not found:
+fi
+test "${with_gnutls}" != "no" && test "${HAVE_GNUTLS}" != "yes" &&
+  MISSING="$MISSING gnutls" && WITH_NO="$WITH_NO --with-gnutls=no"
+if test "X${MISSING}" != X; then
+  AC_MSG_ERROR([The following required libraries were not found:
     $MISSING
 Maybe some development libraries/packages are missing?
 If you don't want to link with them give
     $WITH_NO
 as options to configure])
-  fi
 fi
 
 ### Use -lgpm if available, unless '--with-gpm=no'.
-- 
2.5.5

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Wed, 20 Jul 2016 16:21:37 +0200 Paul Eggert <eggert@cs.ucla.edu> wrote: 

PE> On 07/20/2016 03:14 PM, Ted Zlatanov wrote:
SM> Another step in the same direction is to make ./configure fail if
SM> libgnutls is not found.
>> 
>> That's a one-line change IIRC, so it just needs the OK from John or Eli
>> (since it's a pretty major change).

PE> It's not that big a deal to treat libgnutls like other key libraries. Namely,
PE> 'configure' fails if the library is missing, unless you specifically say you
PE> don't want the library by configuring with the --with-gnutls=no option.
PE> Something like the attached patch, say.

Hi Paul. The patch looks OK to me. I'm not sure why you introduce
MISSING and WITH_NO at the top level, but I don't know autoconf well. If
you push it, I can document the change.

Thanks
Ted

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Mon, 25 Jul 2016 08:48:19 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> Hi Paul. The patch looks OK to me. I'm not sure why you introduce
TZ> MISSING and WITH_NO at the top level, but I don't know autoconf well. If
TZ> you push it, I can document the change.

Never mind, I see you did both. Sorry for the noise.

Ted

Re: GnuTLS/TLS proposals for after the release

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Wed, 20 Jul 2016 09:14:39 -0400
> 
> SM> Another step in the same direction is to make ./configure fail if
> SM> libgnutls is not found.
> 
> That's a one-line change IIRC, so it just needs the OK from John or Eli
> (since it's a pretty major change). I am strongly in favor, of course.

How probable is it to find libgnutls on a garden-variety Posix
platform these days?

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Thu, 21 Jul 2016 17:52:46 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Wed, 20 Jul 2016 09:14:39 -0400
>> 
SM> Another step in the same direction is to make ./configure fail if
SM> libgnutls is not found.
>> 
>> That's a one-line change IIRC, so it just needs the OK from John or Eli
>> (since it's a pretty major change). I am strongly in favor, of course.

EZ> How probable is it to find libgnutls on a garden-variety Posix
EZ> platform these days?

Very. It can be installed, even if it's not pre-installed, easily on all
the major distributions AFAIK.

Ted

Re: GnuTLS/TLS proposals for after the release

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 21 Jul 2016 11:22:53 -0400
> 
> EZ> How probable is it to find libgnutls on a garden-variety Posix
> EZ> platform these days?
> 
> Very. It can be installed, even if it's not pre-installed, easily on all
> the major distributions AFAIK.

I asked about the pre-installed part.  If libgnutls is already
sufficiently widely available, then requiring it will not annoy users.

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Thu, 21 Jul 2016 19:00:47 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 21 Jul 2016 11:22:53 -0400
>> 
EZ> How probable is it to find libgnutls on a garden-variety Posix
EZ> platform these days?
>> 
>> Very. It can be installed, even if it's not pre-installed, easily on all
>> the major distributions AFAIK.

EZ> I asked about the pre-installed part.  If libgnutls is already
EZ> sufficiently widely available, then requiring it will not annoy users.

It's both very likely to be installed and extremely likely to be easily
installable.

Ted

Re: GnuTLS/TLS proposals for after the release

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It's both very likely to be installed and extremely likely to be easily
> installable.

Well, the -devel package for gnutls isn't extremely likely to be
installed on a typical GNU/Linux box, but, then again, that goes for
most -devel packages.

Put it's just an "apt install" away.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: GnuTLS/TLS proposals for after the release

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 21 Jul 2016 19:25:38 +0200
> 
> Well, the -devel package for gnutls isn't extremely likely to be
> installed on a typical GNU/Linux box, but, then again, that goes for
> most -devel packages.
> 
> Put it's just an "apt install" away.

The suggestion is not only for GNU/Linux, is it?  If not, then "apt
install" and friends are not necessarily relevant.  That's why I asked
about Posix platforms, not about GNU/Linux.

Re: GnuTLS/TLS proposals for after the release

[Ted Zlatanov]

On Thu, 21 Jul 2016 21:46:32 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Thu, 21 Jul 2016 19:25:38 +0200
>> 
>> Well, the -devel package for gnutls isn't extremely likely to be
>> installed on a typical GNU/Linux box, but, then again, that goes for
>> most -devel packages.
>> 
>> Put it's just an "apt install" away.

EZ> The suggestion is not only for GNU/Linux, is it?  If not, then "apt
EZ> install" and friends are not necessarily relevant.  That's why I asked
EZ> about Posix platforms, not about GNU/Linux.

My answer was about POSIX platforms, to the best of my knowledge, today
in 2016. As far as it's relevant to the original request of requiring
GnuTLS, I'll also note that you will still be able to compile without
it. Only the default is being flipped.

Ted

Re: GnuTLS/TLS proposals for after the release

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 22 Jul 2016 10:38:21 -0400
> 
> EZ> The suggestion is not only for GNU/Linux, is it?  If not, then "apt
> EZ> install" and friends are not necessarily relevant.  That's why I asked
> EZ> about Posix platforms, not about GNU/Linux.
> 
> My answer was about POSIX platforms, to the best of my knowledge, today
> in 2016.

I'd like to hear from more people who know about those platforms.
Paul, for example.

Re: GnuTLS/TLS proposals for after the release

[Paul Eggert]

On 07/22/2016 05:23 PM, Eli Zaretskii wrote:
> I'd like to hear from more people who know about those platforms.
> Paul, for example.

I regularly build Emacs on old Solaris systems that lack libraries that 
we require for typical builds (e.g., libgif). I haven't checked whether 
these systems also lack libgnutls, and don't much care whether they do. 
If they lack it, I'll configure --with-gnutls=no; if not, not. So I'm in 
favor of the change that I proposed. Emacs will still need to work even 
if libgnutls is absent, so I'm not sure what practical effect this will 
have on Emacs development in the short run. But it should encourage more 
packagers to make sure Emacs is linked with libgnutls.

Re: GnuTLS/TLS proposals for after the release

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 23 Jul 2016 09:44:28 +0200
> 
> On 07/22/2016 05:23 PM, Eli Zaretskii wrote:
> > I'd like to hear from more people who know about those platforms.
> > Paul, for example.
> 
> I regularly build Emacs on old Solaris systems that lack libraries that 
> we require for typical builds (e.g., libgif). I haven't checked whether 
> these systems also lack libgnutls, and don't much care whether they do. 
> If they lack it, I'll configure --with-gnutls=no; if not, not. So I'm in 
> favor of the change that I proposed. Emacs will still need to work even 
> if libgnutls is absent, so I'm not sure what practical effect this will 
> have on Emacs development in the short run. But it should encourage more 
> packagers to make sure Emacs is linked with libgnutls.

Thanks.  This matches my thinking.  So I don't object to the proposed
change (on master, of course; and please mention that in NEWS).

Re: GnuTLS/TLS proposals for after the release

[Stefan Monnier]

>> Very. It can be installed, even if it's not pre-installed, easily on all
>> the major distributions AFAIK.
> I asked about the pre-installed part.  If libgnutls is already
> sufficiently widely available, then requiring it will not annoy users.

I think having both the library and its include files installed is just
as unlikely as for the other libraries we require (jpeg/gif/png).


        Stefan

Re: GnuTLS/TLS proposals for after the release

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 22 Jul 2016 10:38:50 -0400
> 
> >> Very. It can be installed, even if it's not pre-installed, easily on all
> >> the major distributions AFAIK.
> > I asked about the pre-installed part.  If libgnutls is already
> > sufficiently widely available, then requiring it will not annoy users.
> 
> I think having both the library and its include files installed is just
> as unlikely as for the other libraries we require (jpeg/gif/png).

If that is true, then there's no problem to have libgnutls handled the
same as the image libraries: require them, or --without-gnutls, for
the configure script to succeed.