GNU bug report logs - #16253
24.3.50; Irrelevant warnings from gnutls

Previous Next

Package: emacs;

Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>

Date: Wed, 25 Dec 2013 09:16:02 UTC

Severity: minor

Tags: fixed

Merged with 18148, 25396

Found in versions 24.3.50, 24.3.92, 24.5

Fixed in versions 25.1, 26.1

Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16253 in the body.
You can then email your comments to 16253 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Wed, 25 Dec 2013 09:16:03 GMT) Full text and rfc822 format available.
Acknowledgement sent to Lars Ingebrigtsen <larsi <at> gnus.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 25 Dec 2013 09:16:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Irrelevant warnings from gnutls
Date: Wed, 25 Dec 2013 10:09:21 +0100

When a TLS server shuts down the connection to Emacs (for instance, when
timing out a https connection), Emacs gives this ominous warning:

gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.

Normal network connections don't give any warnings, so TLS connections
shouldn't, either.



In GNU Emacs 24.3.50.5 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.2)
 of 2013-12-25 on building.gnus.org
Bzr revision: 115738 cyd <at> gnu.org-20131225030511-ru56hhc243pxja04
Windowing system distributor `Fedora Project', version 11.0.11402000
Important settings:
  value of $LANG: en_GB.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Messages

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-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
  buffer-read-only: t
  line-number-mode: t

Recent input:
e e z e SPC i s SPC o v e r SPC t o SPC i <backspace> 
b e SPC i n s t a l l e d . C-c C-c d q g . <return> 
d q s <down-mouse-1> <mouse-movement> <mouse-1> g . 
<return> d q <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <return> <return> 
q <up> <up> <up> <up> <up> <up> <up> l <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <return> 1 0 <return> <return> n n SPC n n SPC 
n n SPC n n n n <down-mouse-1> <mouse-movement> <mouse-1> 
H-o H-o M-x C-g C-x b b l C-g M-x l a r s - e r <tab> 
<return> <down-mouse-1> <mouse-movement> <mouse-1> 
/ n i c k SPC / n i c k SPC l m i n <return> H-o H-o 
H-o H-o H-o C-x v = C-x o C-x 1 C-x b * G <return> 
g <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <return> <return> q l l <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <up> <up> <up> <return> 1 0 <return> 
<return> h n n n SPC SPC SPC SPC SPC SPC <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <up> <up> <return> 
<next> <next> q n n n n P <down> <down> <down> <down> 
<down> <return> SPC SPC SPC SPC q n n n C-g <up> <return> 
1 0 <return> SPC H-o C-x b * s <backspace> M <return> 
C-x b <return> T s k SPC t s k <return> C-x b <return> 
<up> <up> C-SPC C-e M-w M-> M-x r e p o <tab> r <tab> 
<return>

Recent messages:
Reading active file from archive via nnfolder...done
Reading active file via nndraft...done
Checking new news...done
Contacting host: news.ycombinator.com:443
Contacting host: bits.blogs.nytimes.com:80
Quit getting the articles to read
Quit
gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.
Mark set [2 times]
Making completion list...

Load-path shadows:
/home/larsi/mgnus/lisp/hex-util hides /home/larsi/src/emacs/trunk/lisp/hex-util
/home/larsi/mgnus/lisp/md4 hides /home/larsi/src/emacs/trunk/lisp/md4
/home/larsi/mgnus/lisp/format-spec hides /home/larsi/src/emacs/trunk/lisp/format-spec
/home/larsi/mgnus/lisp/password-cache hides /home/larsi/src/emacs/trunk/lisp/password-cache
/home/larsi/mgnus/lisp/color hides /home/larsi/src/emacs/trunk/lisp/color
/home/larsi/mgnus/lisp/dns-mode hides /home/larsi/src/emacs/trunk/lisp/textmodes/dns-mode
/home/larsi/mgnus/lisp/sasl-digest hides /home/larsi/src/emacs/trunk/lisp/net/sasl-digest
/home/larsi/mgnus/lisp/hmac-md5 hides /home/larsi/src/emacs/trunk/lisp/net/hmac-md5
/home/larsi/mgnus/lisp/sasl-ntlm hides /home/larsi/src/emacs/trunk/lisp/net/sasl-ntlm
/home/larsi/mgnus/lisp/dns hides /home/larsi/src/emacs/trunk/lisp/net/dns
/home/larsi/mgnus/lisp/hmac-def hides /home/larsi/src/emacs/trunk/lisp/net/hmac-def
/home/larsi/mgnus/lisp/sasl hides /home/larsi/src/emacs/trunk/lisp/net/sasl
/home/larsi/mgnus/lisp/sasl-cram hides /home/larsi/src/emacs/trunk/lisp/net/sasl-cram
/home/larsi/mgnus/lisp/ntlm hides /home/larsi/src/emacs/trunk/lisp/net/ntlm
/home/larsi/mgnus/lisp/tls hides /home/larsi/src/emacs/trunk/lisp/net/tls
/home/larsi/mgnus/lisp/dig hides /home/larsi/src/emacs/trunk/lisp/net/dig
/home/larsi/mgnus/lisp/netrc hides /home/larsi/src/emacs/trunk/lisp/net/netrc
/home/larsi/mgnus/lisp/uudecode hides /home/larsi/src/emacs/trunk/lisp/mail/uudecode
/home/larsi/mgnus/lisp/hashcash hides /home/larsi/src/emacs/trunk/lisp/mail/hashcash
/home/larsi/mgnus/lisp/binhex hides /home/larsi/src/emacs/trunk/lisp/mail/binhex
/home/larsi/mgnus/lisp/gnus-sieve hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sieve
/home/larsi/mgnus/lisp/gnus hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus
/home/larsi/mgnus/lisp/nnmh hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmh
/home/larsi/mgnus/lisp/nndir hides /home/larsi/src/emacs/trunk/lisp/gnus/nndir
/home/larsi/mgnus/lisp/gnus-kill hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-kill
/home/larsi/mgnus/lisp/deuglify hides /home/larsi/src/emacs/trunk/lisp/gnus/deuglify
/home/larsi/mgnus/lisp/mm-archive hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-archive
/home/larsi/mgnus/lisp/gnus-gravatar hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-gravatar
/home/larsi/mgnus/lisp/mm-decode hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-decode
/home/larsi/mgnus/lisp/yenc hides /home/larsi/src/emacs/trunk/lisp/gnus/yenc
/home/larsi/mgnus/lisp/mm-extern hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-extern
/home/larsi/mgnus/lisp/qp hides /home/larsi/src/emacs/trunk/lisp/gnus/qp
/home/larsi/mgnus/lisp/gnus-diary hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-diary
/home/larsi/mgnus/lisp/gnus-fun hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-fun
/home/larsi/mgnus/lisp/gnus-vm hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-vm
/home/larsi/mgnus/lisp/registry hides /home/larsi/src/emacs/trunk/lisp/gnus/registry
/home/larsi/mgnus/lisp/nnrss hides /home/larsi/src/emacs/trunk/lisp/gnus/nnrss
/home/larsi/mgnus/lisp/rfc2231 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2231
/home/larsi/mgnus/lisp/mml-sec hides /home/larsi/src/emacs/trunk/lisp/gnus/mml-sec
/home/larsi/mgnus/lisp/gssapi hides /home/larsi/src/emacs/trunk/lisp/gnus/gssapi
/home/larsi/mgnus/lisp/gnus-bookmark hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-bookmark
/home/larsi/mgnus/lisp/nnagent hides /home/larsi/src/emacs/trunk/lisp/gnus/nnagent
/home/larsi/mgnus/lisp/gnus-topic hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-topic
/home/larsi/mgnus/lisp/gnus-bcklg hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-bcklg
/home/larsi/mgnus/lisp/gnus-uu hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-uu
/home/larsi/mgnus/lisp/nnbabyl hides /home/larsi/src/emacs/trunk/lisp/gnus/nnbabyl
/home/larsi/mgnus/lisp/gnus-ml hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-ml
/home/larsi/mgnus/lisp/nnmbox hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmbox
/home/larsi/mgnus/lisp/nnvirtual hides /home/larsi/src/emacs/trunk/lisp/gnus/nnvirtual
/home/larsi/mgnus/lisp/rfc1843 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc1843
/home/larsi/mgnus/lisp/sieve-mode hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve-mode
/home/larsi/mgnus/lisp/nnregistry hides /home/larsi/src/emacs/trunk/lisp/gnus/nnregistry
/home/larsi/mgnus/lisp/gravatar hides /home/larsi/src/emacs/trunk/lisp/gnus/gravatar
/home/larsi/mgnus/lisp/score-mode hides /home/larsi/src/emacs/trunk/lisp/gnus/score-mode
/home/larsi/mgnus/lisp/gnus-notifications hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-notifications
/home/larsi/mgnus/lisp/rtree hides /home/larsi/src/emacs/trunk/lisp/gnus/rtree
/home/larsi/mgnus/lisp/gnus-mh hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-mh
/home/larsi/mgnus/lisp/mail-parse hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-parse
/home/larsi/mgnus/lisp/mm-uu hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-uu
/home/larsi/mgnus/lisp/nnmairix hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmairix
/home/larsi/mgnus/lisp/gnus-agent hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-agent
/home/larsi/mgnus/lisp/message hides /home/larsi/src/emacs/trunk/lisp/gnus/message
/home/larsi/mgnus/lisp/gnus-async hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-async
/home/larsi/mgnus/lisp/spam-report hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-report
/home/larsi/mgnus/lisp/mm-encode hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-encode
/home/larsi/mgnus/lisp/smime hides /home/larsi/src/emacs/trunk/lisp/gnus/smime
/home/larsi/mgnus/lisp/mm-url hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-url
/home/larsi/mgnus/lisp/smiley hides /home/larsi/src/emacs/trunk/lisp/gnus/smiley
/home/larsi/mgnus/lisp/plstore hides /home/larsi/src/emacs/trunk/lisp/gnus/plstore
/home/larsi/mgnus/lisp/nngateway hides /home/larsi/src/emacs/trunk/lisp/gnus/nngateway
/home/larsi/mgnus/lisp/gnus-picon hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-picon
/home/larsi/mgnus/lisp/gnus-range hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-range
/home/larsi/mgnus/lisp/mailcap hides /home/larsi/src/emacs/trunk/lisp/gnus/mailcap
/home/larsi/mgnus/lisp/gnus-sync hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sync
/home/larsi/mgnus/lisp/sieve hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve
/home/larsi/mgnus/lisp/nntp hides /home/larsi/src/emacs/trunk/lisp/gnus/nntp
/home/larsi/mgnus/lisp/gnus-logic hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-logic
/home/larsi/mgnus/lisp/rfc2047 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2047
/home/larsi/mgnus/lisp/mml2015 hides /home/larsi/src/emacs/trunk/lisp/gnus/mml2015
/home/larsi/mgnus/lisp/gnus-html hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-html
/home/larsi/mgnus/lisp/gnus-undo hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-undo
/home/larsi/mgnus/lisp/utf7 hides /home/larsi/src/emacs/trunk/lisp/gnus/utf7
/home/larsi/mgnus/lisp/gmm-utils hides /home/larsi/src/emacs/trunk/lisp/gnus/gmm-utils
/home/larsi/mgnus/lisp/gnus-icalendar hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-icalendar
/home/larsi/mgnus/lisp/gnus-salt hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-salt
/home/larsi/mgnus/lisp/mml-smime hides /home/larsi/src/emacs/trunk/lisp/gnus/mml-smime
/home/larsi/mgnus/lisp/mm-view hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-view
/home/larsi/mgnus/lisp/gnus-demon hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-demon
/home/larsi/mgnus/lisp/gnus-cus hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cus
/home/larsi/mgnus/lisp/nnmaildir hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmaildir
/home/larsi/mgnus/lisp/gnus-art hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-art
/home/larsi/mgnus/lisp/sieve-manage hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve-manage
/home/larsi/mgnus/lisp/gnus-group hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-group
/home/larsi/mgnus/lisp/gnus-msg hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-msg
/home/larsi/mgnus/lisp/spam-stat hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-stat
/home/larsi/mgnus/lisp/mml hides /home/larsi/src/emacs/trunk/lisp/gnus/mml
/home/larsi/mgnus/lisp/rfc2104 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2104
/home/larsi/mgnus/lisp/gnus-registry hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-registry
/home/larsi/mgnus/lisp/nnheader hides /home/larsi/src/emacs/trunk/lisp/gnus/nnheader
/home/larsi/mgnus/lisp/compface hides /home/larsi/src/emacs/trunk/lisp/gnus/compface
/home/larsi/mgnus/lisp/nnnil hides /home/larsi/src/emacs/trunk/lisp/gnus/nnnil
/home/larsi/mgnus/lisp/mml1991 hides /home/larsi/src/emacs/trunk/lisp/gnus/mml1991
/home/larsi/mgnus/lisp/mail-prsvr hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-prsvr
/home/larsi/mgnus/lisp/ecomplete hides /home/larsi/src/emacs/trunk/lisp/gnus/ecomplete
/home/larsi/mgnus/lisp/gnus-win hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-win
/home/larsi/mgnus/lisp/nneething hides /home/larsi/src/emacs/trunk/lisp/gnus/nneething
/home/larsi/mgnus/lisp/nndoc hides /home/larsi/src/emacs/trunk/lisp/gnus/nndoc
/home/larsi/mgnus/lisp/gnus-srvr hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-srvr
/home/larsi/mgnus/lisp/nnoo hides /home/larsi/src/emacs/trunk/lisp/gnus/nnoo
/home/larsi/mgnus/lisp/spam hides /home/larsi/src/emacs/trunk/lisp/gnus/spam
/home/larsi/mgnus/lisp/nnfolder hides /home/larsi/src/emacs/trunk/lisp/gnus/nnfolder
/home/larsi/mgnus/lisp/messcompat hides /home/larsi/src/emacs/trunk/lisp/gnus/messcompat
/home/larsi/mgnus/lisp/html2text hides /home/larsi/src/emacs/trunk/lisp/gnus/html2text
/home/larsi/mgnus/lisp/starttls hides /home/larsi/src/emacs/trunk/lisp/gnus/starttls
/home/larsi/mgnus/lisp/auth-source hides /home/larsi/src/emacs/trunk/lisp/gnus/auth-source
/home/larsi/mgnus/lisp/canlock hides /home/larsi/src/emacs/trunk/lisp/gnus/canlock
/home/larsi/mgnus/lisp/pop3 hides /home/larsi/src/emacs/trunk/lisp/gnus/pop3
/home/larsi/mgnus/lisp/gnus-score hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-score
/home/larsi/mgnus/lisp/mm-util hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-util
/home/larsi/mgnus/lisp/gnus-sum hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sum
/home/larsi/mgnus/lisp/nndiary hides /home/larsi/src/emacs/trunk/lisp/gnus/nndiary
/home/larsi/mgnus/lisp/gnus-start hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-start
/home/larsi/mgnus/lisp/gnus-int hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-int
/home/larsi/mgnus/lisp/rfc2045 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2045
/home/larsi/mgnus/lisp/gnus-cache hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cache
/home/larsi/mgnus/lisp/nnweb hides /home/larsi/src/emacs/trunk/lisp/gnus/nnweb
/home/larsi/mgnus/lisp/mail-source hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-source
/home/larsi/mgnus/lisp/gnus-eform hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-eform
/home/larsi/mgnus/lisp/gnus-mlspl hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-mlspl
/home/larsi/mgnus/lisp/gnus-util hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-util
/home/larsi/mgnus/lisp/mm-partial hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-partial
/home/larsi/mgnus/lisp/nnimap hides /home/larsi/src/emacs/trunk/lisp/gnus/nnimap
/home/larsi/mgnus/lisp/.dir-locals hides /home/larsi/src/emacs/trunk/lisp/gnus/.dir-locals
/home/larsi/mgnus/lisp/nnir hides /home/larsi/src/emacs/trunk/lisp/gnus/nnir
/home/larsi/mgnus/lisp/gnus-spec hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-spec
/home/larsi/mgnus/lisp/legacy-gnus-agent hides /home/larsi/src/emacs/trunk/lisp/gnus/legacy-gnus-agent
/home/larsi/mgnus/lisp/gnus-cite hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cite
/home/larsi/mgnus/lisp/gnus-dup hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-dup
/home/larsi/mgnus/lisp/spam-wash hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-wash
/home/larsi/mgnus/lisp/ietf-drums hides /home/larsi/src/emacs/trunk/lisp/gnus/ietf-drums
/home/larsi/mgnus/lisp/nnml hides /home/larsi/src/emacs/trunk/lisp/gnus/nnml
/home/larsi/mgnus/lisp/nnmail hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmail
/home/larsi/mgnus/lisp/nndraft hides /home/larsi/src/emacs/trunk/lisp/gnus/nndraft
/home/larsi/mgnus/lisp/nnspool hides /home/larsi/src/emacs/trunk/lisp/gnus/nnspool
/home/larsi/mgnus/lisp/gnus-setup hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-setup
/home/larsi/mgnus/lisp/gnus-ems hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-ems
/home/larsi/mgnus/lisp/gnus-draft hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-draft
/home/larsi/mgnus/lisp/flow-fill hides /home/larsi/src/emacs/trunk/lisp/gnus/flow-fill
/home/larsi/mgnus/lisp/mm-bodies hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-bodies
/home/larsi/mgnus/lisp/gnus-delay hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-delay
/home/larsi/mgnus/lisp/gnus-dired hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-dired
/home/larsi/mgnus/lisp/time-date hides /home/larsi/src/emacs/trunk/lisp/calendar/time-date
/home/larsi/mgnus/lisp/parse-time hides /home/larsi/src/emacs/trunk/lisp/calendar/parse-time

Features:
(shadow emacsbug shr-color color timezone erc-list erc-menu erc-join
erc-ring erc-networks erc-pcomplete pcomplete comint erc-track erc-match
erc-button erc-fill erc-stamp erc-netsplit erc-goodies erc erc-backend
erc-compat crm debbugs-gnu debbugs soap-client warnings nndoc
url-handlers thingatpt mailalias smtpmail sendmail ecomplete
bug-reference vc-annotate whitespace diff-mode easy-mmode vc
vc-dispatcher etags ring edebug misearch multi-isearch vc-bzr pp
descr-text help-mode url-file url-dired sgml-mode eww qp url-http url-gw
url-auth url-queue shr gnus-html browse-url xml url-cache flow-fill
mm-archive mule-util sort smiley ansi-color gnus-cite gnus-async
gnus-dup gnus-ml gmane spam-gmane dns mm-url disp-table gnus-fun
gnus-mdrtn gnus-topic nndraft nnmh utf-7 nnimap utf7 nnfolder parse-time
netrc gnutls network-stream starttls tls nnir spam-report spam spam-stat
gnus-uu yenc gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig
nntp gnus-cache gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
gnus-start gnus-spec gnus-int gnus-range message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win
gnus-load gnus gnus-ems gnus-compat url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core
password-cache url-vars mailcap nnheader gnus-util mail-utils mm-util
help-fns mail-prsvr wid-edit package ido flyspell ispell dired cl-macs
gv add-log mail-extr jka-compr cl cl-loaddefs cl-lib time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-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 nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Tue, 07 Jan 2014 23:46:02 GMT) Full text and rfc822 format available.

Message #8 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Tue, 07 Jan 2014 18:47:12 -0500

On Wed, 25 Dec 2013 10:09:21 +0100 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> When a TLS server shuts down the connection to Emacs (for instance, when
LI> timing out a https connection), Emacs gives this ominous warning:

LI> gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.

LI> Normal network connections don't give any warnings, so TLS connections
LI> shouldn't, either.

I added this:

#ifdef HAVE_GNUTLS3
/* Function to log a simple audit message.  */
static void
gnutls_audit_log_function (gnutls_session_t session, const char* string)
{
  if (global_gnutls_log_level >= 1)
    {
      message ("gnutls.c: [audit] %s", string);
    }
}
#endif
...
#ifdef HAVE_GNUTLS3
      fn_gnutls_global_set_audit_log_function (gnutls_audit_log_function);
#endif

...so if this is an auditing message, you should see the "[audit]"
prefix.  Since you don't, either you're on GnuTLS 2.x (unlikely) or
GnuTLS is saying it's a very high priority message that shouldn't be
filtered out.  I could add special handling for this specific message
but is that the right thing to do?

Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Sat, 18 Jan 2014 17:31:02 GMT) Full text and rfc822 format available.

Message #11 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Sat, 18 Jan 2014 09:29:15 -0800

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

> ...so if this is an auditing message, you should see the "[audit]"
> prefix.  Since you don't, either you're on GnuTLS 2.x (unlikely) or
> GnuTLS is saying it's a very high priority message that shouldn't be
> filtered out. 

Let's see:

[larsi <at> building src]$ ldd emacs | grep tls
	libgnutls.so.28 => /lib64/libgnutls.so.28 (0x0000003f64e00000)

That's gnutls 2.8, I guess?  This is on a laptop running Fedora 19.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Sat, 18 Jan 2014 17:59:02 GMT) Full text and rfc822 format available.

Message #14 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Sat, 18 Jan 2014 19:57:47 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 18 Jan 2014 09:29:15 -0800
> 
> [larsi <at> building src]$ ldd emacs | grep tls
> 	libgnutls.so.28 => /lib64/libgnutls.so.28 (0x0000003f64e00000)
> 
> That's gnutls 2.8, I guess?

No, it should be gnutls 3.x, probably 3.0.x.  28 = 32 - 4 is the API
version.
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Sat, 18 Jan 2014 18:08:01 GMT) Full text and rfc822 format available.

Message #17 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Sat, 18 Jan 2014 10:06:45 -0800

Speaking of irrelevant messages.  I just got this:

gnutls.c: [0] (Emacs) fatal error: An unexpected TLS handshake packet was received.
gnutls.el: (err=[-19] An unexpected TLS handshake packet was received.) boot: (:priority NORMAL :hostname i.chzbgr.com :loglevel 0 :min-prime-bits 256 :trustfiles (/etc/pki/tls/certs/ca-bundle.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :callbacks nil)

Errors like this are to be expected (the server just closes the
connection for some reason or other).  The URL library should deal with
this without bothering the user with these warnings...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 20 Jan 2014 16:10:01 GMT) Full text and rfc822 format available.

Message #20 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Mon, 20 Jan 2014 11:11:29 -0500

On Sat, 18 Jan 2014 10:06:45 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Speaking of irrelevant messages.  I just got this:
LI> gnutls.c: [0] (Emacs) fatal error: An unexpected TLS handshake packet was received.
LI> gnutls.el: (err=[-19] An unexpected TLS handshake packet was
LI> received.) boot: (:priority NORMAL :hostname i.chzbgr.com :loglevel 0
LI> :min-prime-bits 256 :trustfiles (/etc/pki/tls/certs/ca-bundle.crt)
LI> :crlfiles nil :keylist nil :verify-flags nil :verify-error nil
LI> :callbacks nil)

LI> Errors like this are to be expected (the server just closes the
LI> connection for some reason or other).  The URL library should deal with
LI> this without bothering the user with these warnings...

The URL library can't trap these.  GnuTLS considers them highest
priority, so blocking them out would block most useful log information.
I'm not sure what to do without breaking things or complicating the
configuration significantly.

Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 20 Jan 2014 16:11:02 GMT) Full text and rfc822 format available.

Message #23 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Mon, 20 Jan 2014 11:11:47 -0500

On Sat, 18 Jan 2014 19:57:47 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote: 

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Sat, 18 Jan 2014 09:29:15 -0800
>> 
>> [larsi <at> building src]$ ldd emacs | grep tls
>> libgnutls.so.28 => /lib64/libgnutls.so.28 (0x0000003f64e00000)
>> 
>> That's gnutls 2.8, I guess?

EZ> No, it should be gnutls 3.x, probably 3.0.x.  28 = 32 - 4 is the API
EZ> version.

I'm not sure, but my earlier comment stands :)

Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 20 Jan 2014 20:21:02 GMT) Full text and rfc822 format available.

Message #26 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Mon, 20 Jan 2014 12:19:52 -0800

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

> The URL library can't trap these.  GnuTLS considers them highest
> priority, so blocking them out would block most useful log information.

Useful to whom?  It's probably useful when developing applications that
talk TLS, but it's not useful to the user who's just trying to read a
web page.

If you're reading a page, and you're loading a picture that fails, Emacs
should display a "failed download" image, not spew TLS-level errors to
the user.  The user isn't interested.

So I think that, basically, no TLS errors should be displayed to the
user.  At least I haven't seen one yet that's been useful to me as a
user.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 10 Feb 2014 02:35:02 GMT) Full text and rfc822 format available.

Message #29 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Sun, 09 Feb 2014 21:34:06 -0500

On Mon, 20 Jan 2014 12:19:52 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> The URL library can't trap these.  GnuTLS considers them highest
>> priority, so blocking them out would block most useful log information.

LI> Useful to whom?  It's probably useful when developing applications that
LI> talk TLS, but it's not useful to the user who's just trying to read a
LI> web page.

LI> If you're reading a page, and you're loading a picture that fails, Emacs
LI> should display a "failed download" image, not spew TLS-level errors to
LI> the user.  The user isn't interested.

LI> So I think that, basically, no TLS errors should be displayed to the
LI> user.  At least I haven't seen one yet that's been useful to me as a
LI> user.

OK.  I will log them to a special " *TLS errors*" buffer.  That's a good
balance.

Doing that from C is not obvious, compared to the standard `message'
function.  Any hints?  Should I just call `Fget-buffer-create' and
call functions to append to the returned buffer Lisp_Object, or is there
a magical equivalent?

Also, I think we should add that buffer, plus the version of GnuTLS and
the priority string, to bug reports.  WDYT?

Thanks
Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 10 Feb 2014 02:40:03 GMT) Full text and rfc822 format available.

Message #32 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: n.mavrogiannopoulos <at> gmail.com, winkler <at> gnu.org
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org
Subject: Re: bug#11267: 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by
 the server is not acceptable (not long enough).
Date: Sun, 09 Feb 2014 21:39:28 -0500

On Fri, 18 May 2012 04:38:01 -0700 (PDT) n.mavrogiannopoulos <at> gmail.com wrote: 

nm> On Tuesday, May 15, 2012 10:24:56 AM UTC+2, Ted Zlatanov wrote:
>> On Sun, 13 May 2012 21:04:24 +0200 Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote: 
>> 
LMI> "Roland Winkler" <winkler <at> gnu.org> writes:
>> >> Also, it would be good (though I don't know whether a generic answer
>> >> is possible) to give some guidance on "reasonable" values for
>> >> `gnutls-min-prime-bits' as compared to cases where it would be
>> >> better to contact the sysadmin of the server requesting a change in
>> >> the setup of the server.
>> 
LMI> Yeah.  And I think `gnutls-min-prime-bits' should default to whatever
LMI> that "reasonable" is, because there's apparently quite a few servers out
LMI> there that has less bits than whatever the GnuTLS default is.  Which
LMI> isn't a very good user experience.
>> 
>> I'm OK with lowering it to 256.

nm> Note that Diffie-Hellman group of 256-bits means that the communication can be
nm> decrypted by someone that stored the session. The default minimum
nm> accepted value in gnutls is already weak according to [0] (727 bits)
nm> but a good balance between security and compatibility. (other
nm> implementations like NSS have similar limits).

nm> If you need to support weaker servers you could warn your users of the consequences.

nm> [0]. http://www.keylength.com/en/3/

Hi Nikos,

We've continued the discussion in bug#15057 (about the min prime bits)
and bug#16253 (about the logging).  I've copied all three bug trackers
on this e-mail.  I hope that helps connect them for searches and when we
close them.

Roland, if you are satisfied with the direction taken in those bugs, we
can probably close this one.

Thanks
Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 10 Feb 2014 03:03:02 GMT) Full text and rfc822 format available.

Message #35 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Sun, 09 Feb 2014 19:01:16 -0800

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

> OK.  I will log them to a special " *TLS errors*" buffer.  That's a good
> balance.

Yeah, that would be good.  And perhaps limit the size of the buffer.

> Doing that from C is not obvious, compared to the standard `message'
> function.  Any hints?  Should I just call `Fget-buffer-create' and
> call functions to append to the returned buffer Lisp_Object, or is there
> a magical equivalent?

I just had a look at message_dolog (which puts data into the *Messages*
buffer).  It didn't look pretty...  Is all that really necessary?

> Also, I think we should add that buffer, plus the version of GnuTLS and
> the priority string, to bug reports.  WDYT?

For all Emacs bug reports?  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 10 Feb 2014 03:07:02 GMT) Full text and rfc822 format available.

Message #38 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, n.mavrogiannopoulos <at> gmail.com,
 11267 <at> debbugs.gnu.org
Subject: Re: bug#11267: 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by
 the server is not acceptable (not long enough).
Date: Sun, 9 Feb 2014 21:06:37 -0600

On Sun Feb 9 2014 Ted Zlatanov wrote:
> Roland, if you are satisfied with the direction taken in those
> bugs, we can probably close this one.

I am still a bit confused concerning a "reasonable minimal value"
for gnutls-min-prime-bits.  Is 256 a value that I can feel
comfortable about?

Since this was made the default, I did not see again any error
messages.  But I cannot judge whether this means "all is OK".

Part of the problem is certainly that most users do not even know
that there is such a customizable user variable.  So one can only
hope that the default *is* reasonable.
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 10 Feb 2014 10:43:01 GMT) Full text and rfc822 format available.

Message #41 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Mon, 10 Feb 2014 05:42:32 -0500

On Sun, 09 Feb 2014 19:01:16 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> OK.  I will log them to a special " *TLS errors*" buffer.  That's a good
>> balance.

LI> Yeah, that would be good.  And perhaps limit the size of the buffer.

It rarely gets annoyingly big, but OK...  50K messages?

>> Doing that from C is not obvious, compared to the standard `message'
>> function.  Any hints?  Should I just call `Fget-buffer-create' and
>> call functions to append to the returned buffer Lisp_Object, or is there
>> a magical equivalent?

LI> I just had a look at message_dolog (which puts data into the *Messages*
LI> buffer).  It didn't look pretty...  Is all that really necessary?

Not for my usage, definitely.  I can call the usual ELisp functions, I
just want to know if there's a convenient C shortcut.

>> Also, I think we should add that buffer, plus the version of GnuTLS and
>> the priority string, to bug reports.  WDYT?

LI> For all Emacs bug reports?  Hm...

Yes, if GnuTLS is enabled.  We already sent the messages (from
*Messages*) and the default is not very verbose.

Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 10 Feb 2014 10:53:03 GMT) Full text and rfc822 format available.

Message #44 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 Roland Winkler <winkler <at> gnu.org>, 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 11267 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough).
Date: Mon, 10 Feb 2014 05:52:23 -0500

On Mon, 10 Feb 2014 09:28:09 +0100 Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com> wrote: 

NM> On Mon, Feb 10, 2014 at 4:06 AM, Roland Winkler <winkler <at> gnu.org> wrote:

>> I am still a bit confused concerning a "reasonable minimal value"
>> for gnutls-min-prime-bits.  Is 256 a value that I can feel
>> comfortable about?

NM> No. 256-bit DH is a bit harder than rot13 as encryption. I'd suggest
NM> not to set the minimum acceptable size and let gnutls decide instead.
NM> For broken servers that use very small sizes, you could disable the
NM> DHE ciphersuites as described in the previous mails.

On Sun, 09 Feb 2014 18:58:34 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> See http://thread.gmane.org/gmane.network.gnutls.general/3181/focus=3299
>> 
>> Try, first of all, appending `!DHE-RSA:!DHE-DSS' to your GnuTLS priority
>> string to disable DHE.  ECDHE will not have the minimum bits message,
>> ever, IIUC.

LI> But aren't there lots of (or some) servers that only supports DHE and
LI> not ECDHE?

There's no way to know until you connect, that's the heart of the
problem.  So IIUC you'd have to either be potentially insecure all the
time (DHE enabled) or potentially fail connecting to some servers.

I think the latter is the better option as a default, as long as we make
it clear (not in a *GnuTLS log* buffer but with `message' so it shows up
in the echo region and in STDERR in batch mode) that

* the connection was rejected because the remote requires a lower level
of security

* how to try allowing the less-secure connection (perhaps a simple
command to automate this, or even a clickable button, would be nicer
than asking the user to `customize-variable').  The original discussion
sort of settled on magically reopening the connection with less security
but I think that might be a disservice to the users.

* why it's smarter to ask the server admin to upgrade their TLS
implementation

Fitting all of that in a short readable message might be a challenge,
hence the button suggestion, but that's not ideal either.

Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Tue, 11 Feb 2014 05:12:03 GMT) Full text and rfc822 format available.

Message #47 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough).
Date: Mon, 10 Feb 2014 21:09:25 -0800

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

> LI> But aren't there lots of (or some) servers that only supports DHE and
> LI> not ECDHE?
>
> There's no way to know until you connect, that's the heart of the
> problem.  So IIUC you'd have to either be potentially insecure all the
> time (DHE enabled) or potentially fail connecting to some servers.

I thought TLS worked like this:

1) You connect to a server.
2) A server says what encryption methods it supports
3) You choose one, and start talking in that method.

So things like browsers have a pre-defined list of methods, in
descending order of what they consider "more safe", so that ECDHE is
used if available, etc.

> I think the latter is the better option as a default, as long as we make
> it clear (not in a *GnuTLS log* buffer but with `message' so it shows up
> in the echo region and in STDERR in batch mode) that
>
> * the connection was rejected because the remote requires a lower level
> of security

I've basically never ever seen Firefox say "you can't talk to this
server, because the TLS is too weak".  Neither should Emacs.

(Emacs, being Emacs, might offer as an option a way to restrict all TLS
connections to a smaller set of algorithms/levels, but that should not
be the default.)

> * how to try allowing the less-secure connection (perhaps a simple
> command to automate this, or even a clickable button, would be nicer
> than asking the user to `customize-variable').  The original discussion
> sort of settled on magically reopening the connection with less security
> but I think that might be a disservice to the users.

We would always try to get the most secure TLS connection possible, so I
don't quite understand "reconnect"...

> * why it's smarter to ask the server admin to upgrade their TLS
> implementation
>
> Fitting all of that in a short readable message might be a challenge,
> hence the button suggestion, but that's not ideal either.

If the user has explicitly said "don't talk unless it has teh haxors
leet mode", then that's not necessary, I would have thought.

But I might be misunderstanding the problem completely.  >"?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Tue, 11 Feb 2014 10:36:03 GMT) Full text and rfc822 format available.

Message #50 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#15057: 24.3.50; TLS error with reasonably high
 gnutls-min-prime-bits, bug#11267: 24.0.95; gnutls.c: [0] (Emacs) fatal error:
 The Diffie-Hellman prime sent by the server is not acceptable (not long
 enough).
Date: Tue, 11 Feb 2014 11:35:27 +0100

On Tue, Feb 11, 2014 at 6:09 AM, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> LI> But aren't there lots of (or some) servers that only supports DHE and
>> LI> not ECDHE?
>> There's no way to know until you connect, that's the heart of the
>> problem.  So IIUC you'd have to either be potentially insecure all the
>> time (DHE enabled) or potentially fail connecting to some servers.
> I thought TLS worked like this:
> 1) You connect to a server.
> 2) A server says what encryption methods it supports
> 3) You choose one, and start talking in that method.

(let's suppose that the chosen method is DHE)

4) The server presents its DHE parameters and you realize that they
are not acceptable.
5) Cannot do anything except abort the session, disable support for
DHE and go to (1).

>> I think the latter is the better option as a default, as long as we make
>> it clear (not in a *GnuTLS log* buffer but with `message' so it shows up
>> in the echo region and in STDERR in batch mode) that
>> * the connection was rejected because the remote requires a lower level
>> of security
> I've basically never ever seen Firefox say "you can't talk to this
> server, because the TLS is too weak".  Neither should Emacs.

Firefox in the past would happily connect to a server offering weak parameters.
This is changing now:
https://bugzilla.mozilla.org/show_bug.cgi?id=587234

So instead of emacs replicating what the insecure versions of firefox
did, it could provide security by default.

regards,
Nikos
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Tue, 11 Feb 2014 14:23:03 GMT) Full text and rfc822 format available.

Message #53 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 Roland Winkler <winkler <at> gnu.org>, 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 11267 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#11267: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough).
Date: Tue, 11 Feb 2014 09:21:58 -0500

On Mon, 10 Feb 2014 21:09:25 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> (Emacs, being Emacs, might offer as an option a way to restrict all TLS
LI> connections to a smaller set of algorithms/levels, but that should not
LI> be the default.)

I think it should, as long as we make it easy to drop down the security,
as I described:

>> * how to try allowing the less-secure connection (perhaps a simple
>> command to automate this, or even a clickable button, would be nicer
>> than asking the user to `customize-variable').  The original discussion
>> sort of settled on magically reopening the connection with less security
>> but I think that might be a disservice to the users.

LI> We would always try to get the most secure TLS connection possible, so I
LI> don't quite understand "reconnect"...

So my proposal is simply to provide two buttons "allow host X to connect
with lower DHE security [temporarily] [permanently]" and when the button
is clicked, customize `gnutls-algorithm-priority' to allow DHE to that
specific host.

`gnutls-negotiate' has to be changed slightly and the connection
rejection from insecure hosts will need to be handled in gnutls.c and
gnutls.el.

I think that's as seamless as we can make it, especially noting that
`gnutls-min-prime-bits' is deprecated since GnuTLS 3.1.7 (see
http://www.gnutls.org/manual/gnutls.html#index-gnutls_005fdh_005fset_005fprime_005fbits).

If we provide that simple UI, plus some help messaging, I think we can
disable DHE by default.  Based on Nikos' explanation, it seems to be the
best way forward.

Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Tue, 11 Feb 2014 22:50:04 GMT) Full text and rfc822 format available.

Message #56 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#11267: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough).
Date: Tue, 11 Feb 2014 16:49:06 -0600

On Tue Feb 11 2014 Ted Zlatanov wrote:
> So my proposal is simply to provide two buttons "allow host X to
> connect with lower DHE security [temporarily] [permanently]" and
> when the button is clicked, customize `gnutls-algorithm-priority'
> to allow DHE to that specific host.
> 
> `gnutls-negotiate' has to be changed slightly and the connection
> rejection from insecure hosts will need to be handled in gnutls.c
> and gnutls.el.
> 
> I think that's as seamless as we can make it, especially noting
> that `gnutls-min-prime-bits' is deprecated since GnuTLS 3.1.7 (see
> http://www.gnutls.org/manual/gnutls.html#index-gnutls_005fdh_005fset_005fprime_005fbits).
> 
> If we provide that simple UI, plus some help messaging, I think we
> can disable DHE by default.  Based on Nikos' explanation, it seems
> to be the best way forward.

Whatever customizability will be provided (permanently or
temporarily on the fly), I'd find it most important to have
documentation that allows the user to put the choices into
perspective. -- Is this feasible?  Certainly, we cannot expect that
the average user who is offered a pop-up menu with choices "allow
host X to connect with lower DHE security [temporarily]
[permanently]" that he can readily understand its implications and
put it into perspective. (DHE security lower than what?  Lower by
how much?  How insecure is that?)

(According to Murphy's law, this selection will probably pop up most
often, when the user is not in the mood to read long info pages...)

Roland
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Tue, 11 Feb 2014 23:55:03 GMT) Full text and rfc822 format available.

Message #59 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#11267: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough).
Date: Tue, 11 Feb 2014 18:54:49 -0500

On Tue, 11 Feb 2014 16:49:06 -0600 "Roland Winkler" <winkler <at> gnu.org> wrote: 

RW> On Tue Feb 11 2014 Ted Zlatanov wrote:
>> So my proposal is simply to provide two buttons "allow host X to
>> connect with lower DHE security [temporarily] [permanently]" and
>> when the button is clicked, customize `gnutls-algorithm-priority'
>> to allow DHE to that specific host.
>> 
>> `gnutls-negotiate' has to be changed slightly and the connection
>> rejection from insecure hosts will need to be handled in gnutls.c
>> and gnutls.el.
>> 
>> I think that's as seamless as we can make it, especially noting
>> that `gnutls-min-prime-bits' is deprecated since GnuTLS 3.1.7 (see
>> http://www.gnutls.org/manual/gnutls.html#index-gnutls_005fdh_005fset_005fprime_005fbits).
>> 
>> If we provide that simple UI, plus some help messaging, I think we
>> can disable DHE by default.  Based on Nikos' explanation, it seems
>> to be the best way forward.

RW> Whatever customizability will be provided (permanently or
RW> temporarily on the fly), I'd find it most important to have
RW> documentation that allows the user to put the choices into
RW> perspective. -- Is this feasible?  Certainly, we cannot expect that
RW> the average user who is offered a pop-up menu with choices "allow
RW> host X to connect with lower DHE security [temporarily]
RW> [permanently]" that he can readily understand its implications and
RW> put it into perspective. (DHE security lower than what?  Lower by
RW> how much?  How insecure is that?)

I'm sure we can come up with more helpful messaging.  Does it have
to fit in 78 chars?  Can we use buttons?  If so, it could be like this,
going over 78 but not too much:

!! remote host X requires lower security [OK once] [OK always] [Cancel] [?]

With the ? taking the user to more details: a help message or even the
relevant section of gnutls.texi

If we can use a multi-line message it becomes easier, certainly.

The buttons could instead be a simple (y,Y,n,?) prompt.  But that could
be confusing to the inexperienced users we're trying to help.

I need some guidance :)  I don't know if this has been implemented in
another part of Emacs or other packages.

Thanks
Ted
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Wed, 12 Feb 2014 04:31:03 GMT) Full text and rfc822 format available.

Message #62 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#11267: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough).
Date: Tue, 11 Feb 2014 20:29:09 -0800

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

> If we provide that simple UI, plus some help messaging, I think we can
> disable DHE by default.  Based on Nikos' explanation, it seems to be the
> best way forward.

But why would we disable DHE?  Prefer ECDHE over DHE, certainly, but I
don't understand disabling...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Wed, 12 Feb 2014 04:33:03 GMT) Full text and rfc822 format available.

Message #65 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#11267: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough).
Date: Tue, 11 Feb 2014 20:30:58 -0800

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

> I'm sure we can come up with more helpful messaging.  Does it have
> to fit in 78 chars?  Can we use buttons?  If so, it could be like this,
> going over 78 but not too much:
>
> !! remote host X requires lower security [OK once] [OK always] [Cancel] [?]

Yeah, that would be nice.  And, remember, somebody (ahem) also has to
write code to handle invalid certificates.  It could be done the same way.

And if the user types "OK always" for this (and for invalid
certificates), it should be stored using the customize functions.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Wed, 12 Feb 2014 17:12:03 GMT) Full text and rfc822 format available.

Message #68 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 Roland Winkler <winkler <at> gnu.org>, 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 11267 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits, bug#11267:
 24.0.95;
 gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server
 is not acceptable (not long enough)
Date: Wed, 12 Feb 2014 12:11:41 -0500

(I love how mangled the subject line became)

On Tue, 11 Feb 2014 20:30:58 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> I'm sure we can come up with more helpful messaging.  Does it have
>> to fit in 78 chars?  Can we use buttons?  If so, it could be like this,
>> going over 78 but not too much:
>> 
>> !! remote host X requires lower security [OK once] [OK always] [Cancel] [?]

LI> Yeah, that would be nice.  And, remember, somebody (ahem) also has to
LI> write code to handle invalid certificates.  It could be done the
LI> same way.

Yes, it's a similar UI.  After 24.4.  Is that available as a debbugs
tag, "target-version=24.5" or something?

LI> And if the user types "OK always" for this (and for invalid
LI> certificates), it should be stored using the customize functions.

Right.  I feel Customize is the right place to put certificate
exceptions.  The user can set their custom.el file to be
GnuPG-encrypted if they are concerned.

>> If we provide that simple UI, plus some help messaging, I think we can
>> disable DHE by default.  Based on Nikos' explanation, it seems to be the
>> best way forward.

LI> But why would we disable DHE?  Prefer ECDHE over DHE, certainly, but I
LI> don't understand disabling...

Nikos advocates (and I agree) that it's prudent to add
"!DHE-RSA:!DHE-DSS" to the default priority string.  We can make it easy
for the user to remove that exclusion or make a specific exception as
we've discussed.

Ted
Forcibly Merged 16253 18148. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Wed, 30 Jul 2014 00:01:02 GMT) Full text and rfc822 format available.
Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#16253; Package emacs. (Mon, 08 Dec 2014 19:59:01 GMT) Full text and rfc822 format available.

Message #73 received at 16253 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: 16253 <at> debbugs.gnu.org
Subject: Re: bug#16253: 24.3.50; Irrelevant warnings from gnutls
Date: Mon, 08 Dec 2014 20:58:16 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.
>
> Normal network connections don't give any warnings, so TLS connections
> shouldn't, either.

I've now moved the fatal GnuTLS errors to level 1, so nothing is
messaged by default.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed. Request was from Lars Magne Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 08 Dec 2014 19:59:02 GMT) Full text and rfc822 format available.
bug marked as fixed in version 25.1, send any further explanations to 16253 <at> debbugs.gnu.org and Lars Ingebrigtsen <larsi <at> gnus.org> Request was from Lars Magne Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 08 Dec 2014 19:59:02 GMT) Full text and rfc822 format available.
bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 06 Jan 2015 12:24:06 GMT) Full text and rfc822 format available.
bug unarchived. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 10 Jan 2017 17:57:02 GMT) Full text and rfc822 format available.
Forcibly Merged 16253 18148 25396. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 10 Jan 2017 17:57:02 GMT) Full text and rfc822 format available.
bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 08 Feb 2017 12:24:03 GMT) Full text and rfc822 format available.
This bug report was last modified 8 years and 189 days ago.

Previous Next

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