bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[nyc4bos]

It appears that the variable `starttls-use-gnutls' is no longer
honored with builtin GnuTLS support

I start Emacs (-Q) and set the following variables:

(setq starttls-program "openssl")
(setq tls-program '("openssl s_client -connect %h:%p -no_ssl2
-ign_eof"))
(setq starttls-use-gnutls nil)
(setq gnutls-log-level 1)

I then try to run a popular Emacs program that uses the network, Gnus.

First, I setup my Gnus variables and startup Gnus.

I then see in the *Messages* buffer:

gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL
gnutls.c: [1] (Emacs) setting the priority string

which I means that Emacs is using the builtin GnuTLS support.

I rechecked the value of `starttls-use-gnutls':

starttls-use-gnutls is a variable defined in `starttls.el'.
Its value is nil

How do I get Gnus (and presumably other Emacs networked programs) to
not use GnuTLS when `starttls-use-gnutls' is nil?

[Presumably, I can make the GnuTLS DLLs unavailable temporarily to
achive this, but setting the variable `starttls-use-gnutls' to nil
used to accomplish this, i.e. this is a regression.]

Thanks.


In GNU Emacs 24.0.95.1 (i386-mingw-nt5.1.2600)
 of 2012-04-02 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: cp949
  default enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<send-emacs-bug-report>

Recent messages:
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL
gnutls.c: [1] (Emacs) setting the priority string

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win
w32-vars tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[Glenn Morris]

nyc4bos@aol.com wrote:

> How do I get Gnus (and presumably other Emacs networked programs) to
> not use GnuTLS when `starttls-use-gnutls' is nil?

etc/NEWS

  *** SMTPmail now uses encrypted connections (via STARTTLS) by default
  if the mail server supports them.  This uses either built-in GnuTLS
  support, or the starttls.el library.  Customize `smtpmail-stream-type'
  to change this.

> [Presumably, I can make the GnuTLS DLLs unavailable temporarily to
> achive this, but setting the variable `starttls-use-gnutls' to nil
> used to accomplish this, i.e. this is a regression.]

No previous release of Emacs has had built-in GnuTLS support.

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[nyc4bos]

Glenn Morris <rgm@gnu.org> writes:

> nyc4bos@aol.com wrote:
>
>> How do I get Gnus (and presumably other Emacs networked programs) to
>> not use GnuTLS when `starttls-use-gnutls' is nil?
>
> etc/NEWS
>
>   *** SMTPmail now uses encrypted connections (via STARTTLS) by default
>   if the mail server supports them.  This uses either built-in GnuTLS
>   support, or the starttls.el library.  Customize `smtpmail-stream-type'
>   to change this.

As my test of an Emacs networked-using package like Gnus, I set my Gnus
variables to ONLY use NNTP, not SMTP (nor any other mail-related
protocols like IMAP)

My Gnus variable are:

(setq gnus-select-method '(nntp "news" 
				(nntp-address "news.gmane.org")

Here is the *Message* buffer demostrating the results:

gnutls.c: [1] (Emacs) GnuTLS library loaded: libgnutls-28.dll
gnutls.c: [1] (Emacs) allocating credentials
gnutls.c: [1] (Emacs) gnutls callbacks
gnutls.c: [1] (Emacs) gnutls_init
gnutls.c: [1] (Emacs) got non-default priority string: NORMAL
gnutls.c: [1] (Emacs) setting the priority string
news.gmane.org certificate could not be verified.
gnutls.c: [1] (Emacs) certificate signer was not found: news.gmane.org
gnutls.c: [1] (Emacs) certificate validation failed: news.gmane.org


news.gmane.org is the newserver (NNTP).

Thus the setting of `smtpmail-stream-type' doesn't apply.

It applies only when SENDING mail (SMTP) when smtpmail.el is loaded
and used.

At least, I don't believe it is loaded/used until I compose a mail or
news message and (perhaps) message.el or something else loads smtpmail.el.

I don't believe customizing `smtpmail-stream-type` helps me in this
situation (not using built-in GnuTLS) unless I'm sending mail or news.

>
>> [Presumably, I can make the GnuTLS DLLs unavailable temporarily to
>> achive this, but setting the variable `starttls-use-gnutls' to nil
>> used to accomplish this, i.e. this is a regression.]
>
> No previous release of Emacs has had built-in GnuTLS support.

That's true, but setting `starttls-use-gnutls' to nil prevented
(external) GnuTLS (gnutls-cli) from being used in released versions
of Emacs.

Therefore, I believe that this is a regression with regards to Emacs 23.x
since GnuTLS (whether built-in or external) is being used when
'starttls-use-gnutls' is nil.

I believe the value of `starttls-program' (openssl, for one exmple of
a user setting this value) should be used instead, regardless of
built-in GnuTLS being compiled in (and its required DLLs being
available), as it used to be in Emacs 23.x.

Thanks.

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[Glenn Morris]

You could always try redefining gnutls-available-p to return nil, eg:

(defalias 'gnutls-available-p 'ignore)


I confess I don't really understand what you are trying to do, or why it
matters if the internal support is used.

Hopefully someone else can help.

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> You could always try redefining gnutls-available-p to return nil, eg:
>
> (defalias 'gnutls-available-p 'ignore)

Yes.  In any case, this is neither a regression, nor a bug.  The
variable in question controls what external program is used; not whether
to use an external program or not.  So I'm closing this bug report.

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

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[nyc4bos]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>> You could always try redefining gnutls-available-p to return nil, eg:
>>
>> (defalias 'gnutls-available-p 'ignore)
>
> Yes.  In any case, this is neither a regression, nor a bug.  The
> variable in question controls what external program is used; not whether
> to use an external program or not.  So I'm closing this bug report.

The variable, `starttls-use-gnutls' docstring says:

"*Whether to use GnuTLS instead of the `starttls' command."

So if I'm understanding the docstring right, if it is nil, whatever is
the `starttls' command should be used, NOT GnuTLS.

[The defcustom really says:

(defcustom starttls-use-gnutls (not (executable-find starttls-program)))]

This appears to me to be a regression since setting `starttls-use-gnustls'
to nil still uses GnuTLS (when `starttls-program' is accessible), unlike
Emacs 23.4.

At a minimum, this is a documentation bug with regard to Emacs 24.

Can you explain to me why should a user now jump through more hoops
to use another program such as OpenSSL, in order to use TLS?

Setting `starttls-use-gnutls' to nil works just fine in Emacs 23.4

Thanks.

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[Lars Magne Ingebrigtsen]

nyc4bos@aol.com writes:

> Can you explain to me why should a user now jump through more hoops
> to use another program such as OpenSSL, in order to use TLS?

`starttls-use-gnutls' controls what starttls.el does when starttls.el is
being used.  starttls.el is not being used, by default, any more.  So
this isn't a regression.

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

bug#11205: 24.0.95; starttls-use-gnutls no longer being honored

[nyc4bos]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> nyc4bos@aol.com writes:
>
>> Can you explain to me why should a user now jump through more hoops
>> to use another program such as OpenSSL, in order to use TLS?
>
> `starttls-use-gnutls' controls what starttls.el does when starttls.el is
> being used.  starttls.el is not being used, by default, any more.  So
> this isn't a regression.

The regression is that you can't prevent GnuTLS from being used
and use OpenSSL if GnuTLS us installed.

OK, I'll open up another bug report and not mention
`starttls-use-gnutls' so that this can be fixed.