GNU bug report logs - #13374
24.?; open-gnutls-stream insecurity

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#13374: closed (24.?; open-gnutls-stream insecurity)
Date: Wed, 18 Dec 2013 22:50:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 18 Dec 2013 17:50:39 -0500
with message-id <87r499ixj4.fsf <at> flea.lifelogs.com>
and subject line Re: bug#13374: 24.?; open-gnutls-stream insecurity
has caused the debbugs.gnu.org bug report #13374,
regarding 24.?; open-gnutls-stream insecurity
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
13374: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13374
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Oleksii Shevchuk <alxchk <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.?; open-gnutls-stream insecurity
Date: Mon, 07 Jan 2013 12:20:45 +0200

Hi list!

open-gnutls-stream wrapper doesn't pass :verify-hostname-error t
:verify-error t to gnutls-negotiate. So MitM is possible when you use
gnus and other packages. 

Even with :verify-hostname-error t :verify-error t gnutls-negotiate
doesn't produce error with selfsigned CA certificate, when :type
'gnutls-x509pki passed.

I use next in my .gnus:

(defun open-gnutls-stream (name buffer host service)
  (gnutls-negotiate :process (open-network-stream name buffer host service)
                    :hostname host
                    :verify-hostname-error t :verify-error t))

Works for me.

// ----

In GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, X toolkit)
 of 2013-01-06 on BlackICE
Bzr revision: cyd <at> gnu.org-20130106025857-h1wkwx5cwvekj4l1
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Gentoo Base System release 2.2

Configured using:
 `configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --libdir=/usr/lib64
 --disable-dependency-tracking --program-suffix=-emacs-24-vcs
 --program-transform-name=s/emacs-[0-9].*/emacs-24-vcs/
 --infodir=/usr/share/info/emacs-24-vcs
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --with-crt-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../lib64
 --with-gameuser=games --without-compress-info --without-hesiod
 --without-kerberos --without-kerberos5 --with-gpm --with-dbus
 --with-gnutls --with-xml2 --without-selinux --with-wide-int
 --with-sound --with-x --without-ns --without-gconf --with-gsettings
 --without-toolkit-scroll-bars --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xpm --without-imagemagick --with-xft
 --without-libotf --without-m17n-flt --with-x-toolkit=lucid
 --without-xaw3d GENTOO_PACKAGE=app-editors/emacs-vcs-24.3.9999
 EBZR_BRANCH=trunk EBZR_REVNO=111428'

Important settings:
  value of $LC_ALL: ru_RU.UTF-8
  value of $LANG: russian
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

[Message part 3 (message/rfc822, inline)]

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Oleksii Shevchuk <alxchk <at> gmail.com>,
 Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 13374-done <at> debbugs.gnu.org
Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity
Date: Wed, 18 Dec 2013 17:50:39 -0500

On Tue, 08 Jan 2013 12:06:08 -0500 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote: 

>>> It should default to nil (in other words, we'll ship 24.3 with the same
>>> insecure behavior it has right now).  But we can recommend to the users
>>> to turn it on, and see how well it works in practice, and write the
>>> necessary prompts and customization logic that Lars outlined.
>> I think we should just leave things as is for 24.3, since it's too close
>> to release, and fix this properly for 24.5.

SM> I tend to agree, although, if the patch is sufficiently trivial, it
SM> could be accepted (e.g. define a new custom var, with nil default value
SM> and splice it somewhere in the code where nil makes no difference).

>> Instituting an option like that (which will have to be abandoned
>> later) as a stop-gap I feel isn't all that helpful.

SM> If the option will have to be abandoned, then it's indeed a loser, but
SM> I thought the idea is that this option will stay and the added code in
SM> 24.4 will "simply" be handling errors more cleverly and prompting the
SM> user to update this option on-the-fly.

This is done for the upcoming release.  Marking this as done.

Ted

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.