emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#13374: closed (24.?; open-gnutls-stream insecurity


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#13374: closed (24.?; open-gnutls-stream insecurity)
Date: Wed, 18 Dec 2013 22:50:02 +0000

Your message dated Wed, 18 Dec 2013 17:50:39 -0500
with message-id <address@hidden>
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
address@hidden)


-- 
13374: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13374
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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: address@hidden
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




--- End Message ---
--- Begin Message --- Subject: Re: bug#13374: 24.?; open-gnutls-stream insecurity Date: Wed, 18 Dec 2013 17:50:39 -0500 User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)
On Tue, 08 Jan 2013 12:06:08 -0500 Stefan Monnier <address@hidden> 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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]