GNU bug report logs -
#31313
26.1; gnutls.c: [0] (Emacs) Received alert: Handshake failed
Previous Next
Reported by: Eric Hanchrow <eric.hanchrow <at> gmail.com>
Date: Sun, 29 Apr 2018 20:00:02 UTC
Severity: normal
Tags: unreproducible
Found in version 26.1
Done: Eli Zaretskii <eliz <at> gnu.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 31313 in the body.
You can then email your comments to 31313 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Sun, 29 Apr 2018 20:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eric Hanchrow <eric.hanchrow <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 29 Apr 2018 20:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Put this into /tmp/repro.el
(setq package-archives
'(("gnu" . "https://elpa.gnu.org/packages/")
("melpa" . "https://melpa.org/packages/")
("elpy" . "https://jorgenschaefer.github.io/packages/"))
)
(package-list-packages)
Then run "emacs -Q --load /tmp/repro.el". You'll see
gnutls.c: [0] (Emacs) Received alert: Handshake failed
in the echo area; the *Packages* buffer's mode line will say Package
Menu:Loading for ever, and after typing U you will see "Waiting for
refresh to finish...". Basically packages are now unusable.
This used to work until perhaps a few days or weeks ago; as far as I
know nothing has changed.
In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu)
of 2018-04-29 built on ip-10-0-0-79
Repository revision: c18ec6afc0ee7fa2ad5831fbd3a51ca4df3c35b7
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Importing package-keyring.gpg...done
Setting ‘package-selected-packages’ temporarily since "emacs -q" would
overwrite customizations
gnutls.c: [0] (Emacs) Received alert: Handshake failed
Mark set
Mark saved where search started
Waiting for refresh to finish...
Quit
current-kill: Kill ring is empty
user-error: Previous command was not a yank
Configured using:
'configure --without-x'
Configured features:
JPEG SOUND NOTIFY LIBSELINUX GNUTLS LIBXML2 ZLIB THREADS
Important settings:
value of $LC_ALL: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Package Menu
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired dired-loaddefs format-spec
rfc822 mml mml-sec epa derived gnus-util rmail tool-bar rmail-loaddefs
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader sendmail
regexp-opt mail-utils misearch multi-isearch cus-edit cus-start cus-load
wid-edit network-stream starttls url-http tls gnutls mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc puny
url-cache url-auth url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap epg finder-inf
package easymenu epg-config url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache url-vars seq
byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib term/xterm
xterm time-date elec-pair mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select mouse jit-lock font-lock syntax
facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded 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 inotify multi-tty
make-network-process emacs)
Memory information:
((conses 16 888576 36741)
(symbols 48 35517 1)
(miscs 40 48 110)
(strings 32 110311 4947)
(string-bytes 1 2359526)
(vectors 16 24138)
(vector-slots 8 598779 29348)
(floats 8 58 371)
(intervals 56 107939 1833)
(buffers 992 15)
(heap 1024 53709 8512))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Sun, 29 Apr 2018 20:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 31313 <at> debbugs.gnu.org (full text, mbox):
tags 31313 + unreproducible
quit
Eric Hanchrow <eric.hanchrow <at> gmail.com> writes:
> Put this into /tmp/repro.el
>
> (setq package-archives
> '(("gnu" . "https://elpa.gnu.org/packages/")
> ("melpa" . "https://melpa.org/packages/")
> ("elpy" . "https://jorgenschaefer.github.io/packages/"))
> )
> (package-list-packages)
>
> Then run "emacs -Q --load /tmp/repro.el". You'll see
>
> gnutls.c: [0] (Emacs) Received alert: Handshake failed
>
> in the echo area; the *Packages* buffer's mode line will say Package
> Menu:Loading for ever, and after typing U you will see "Waiting for
> refresh to finish...". Basically packages are now unusable.
>
> This used to work until perhaps a few days or weeks ago; as far as I
> know nothing has changed.
I can't reproduce this. I get the packages listed in *Packages*, and
the following in *Messages*:
Importing package-keyring.gpg...done
Setting ‘package-selected-packages’ temporarily since "emacs -q" would overwrite customizations
Package refresh done
4 packages can be upgraded; type ‘U’ to mark them for upgrading.
Added tag(s) unreproducible.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 29 Apr 2018 20:39:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Sun, 29 Apr 2018 21:02:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 31313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[forwarding to list, please use "Reply All" to keep 31313 <at> debbugs.gnu.org on Cc]
[Message part 2 (message/rfc822, inline)]
Is there any more information that I could supply that would help in
debugging?
[Message part 3 (text/plain, inline)]
I think setting gnutls-log-level could be helpful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Sun, 29 Apr 2018 22:33:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 31313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[forwarding to list, please use "Reply All" to keep 31313 <at> debbugs.gnu.org on Cc]
[Message part 2 (message/rfc822, inline)]
I did that, and got the attached log.
[Message part 3 (text/plain, inline)]
Hmm, not really sure what to make of it. I've attached my results as
well, for comparison.
[bug-31313-tls-messages.txt.gz (application/gzip, attachment)]
[bug-31313-tls-messages-ok.txt.gz (application/gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Mon, 30 Apr 2018 02:35:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 31313 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Sun, 29 Apr 2018 19:59:19 +0000
>
> This used to work until perhaps a few days or weeks ago; as far as I
> know nothing has changed.
>
>
> In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu)
> of 2018-04-29 built on ip-10-0-0-79
> Repository revision: c18ec6afc0ee7fa2ad5831fbd3a51ca4df3c35b7
Is this Emacs 26.1 RC1, or is it something else? You are saying it
worked until a few days ago, but it isn't clear whether your Emacs
changed since then. And there's no commit with the above SHA1 in the
Emacs repository, AFAICT. So I'm unsure what codebase you are using
and how to interpret the fact that it used to work not long ago.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Mon, 30 Apr 2018 05:27:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 31313 <at> debbugs.gnu.org (full text, mbox):
On April 30, 2018 5:34:28 AM GMT+03:00, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Sun, 29 Apr 2018 19:59:19 +0000
> >
> > This used to work until perhaps a few days or weeks ago; as far as I
> > know nothing has changed.
> >
> >
> > In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu)
> > of 2018-04-29 built on ip-10-0-0-79
> > Repository revision: c18ec6afc0ee7fa2ad5831fbd3a51ca4df3c35b7
>
> Is this Emacs 26.1 RC1, or is it something else? You are saying it
> worked until a few days ago, but it isn't clear whether your Emacs
> changed since then. And there's no commit with the above SHA1 in the
> Emacs repository, AFAICT. So I'm unsure what codebase you are using
> and how to interpret the fact that it used to work not long ago.
And what is your GnuTLS version? Did you by chance have it updated lately?
Also, what does (gnutls-available-p) return?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Mon, 30 Apr 2018 14:27:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 31313 <at> debbugs.gnu.org (full text, mbox):
[Please keep the bug address on the CC list.]
> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Mon, 30 Apr 2018 02:38:37 +0000
>
> Sorry, that commit is 71be806d01c4e135f067bc842a9d684e594b4f35 plus some
> private tweaks to .gdbinit.
> On Sun, Apr 29, 2018 at 7:34 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > > Date: Sun, 29 Apr 2018 19:59:19 +0000
> > >
> > > This used to work until perhaps a few days or weeks ago; as far as I
> > > know nothing has changed.
> > >
> > >
> > > In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu)
> > > of 2018-04-29 built on ip-10-0-0-79
> > > Repository revision: c18ec6afc0ee7fa2ad5831fbd3a51ca4df3c35b7
>
> > Is this Emacs 26.1 RC1, or is it something else? You are saying it
> > worked until a few days ago, but it isn't clear whether your Emacs
> > changed since then. And there's no commit with the above SHA1 in the
> > Emacs repository, AFAICT. So I'm unsure what codebase you are using
> > and how to interpret the fact that it used to work not long ago.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Wed, 02 May 2018 02:48:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 31313 <at> debbugs.gnu.org (full text, mbox):
`gnutls-cli --version` reports 2.12.23, and the executable is a year old.
(gnutls-available-p) returns (gnutls).
On Sun, Apr 29, 2018 at 10:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> On April 30, 2018 5:34:28 AM GMT+03:00, Eli Zaretskii <eliz <at> gnu.org>
wrote:
> > > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > > Date: Sun, 29 Apr 2018 19:59:19 +0000
> > >
> > > This used to work until perhaps a few days or weeks ago; as far as I
> > > know nothing has changed.
> > >
> > >
> > > In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu)
> > > of 2018-04-29 built on ip-10-0-0-79
> > > Repository revision: c18ec6afc0ee7fa2ad5831fbd3a51ca4df3c35b7
> >
> > Is this Emacs 26.1 RC1, or is it something else? You are saying it
> > worked until a few days ago, but it isn't clear whether your Emacs
> > changed since then. And there's no commit with the above SHA1 in the
> > Emacs repository, AFAICT. So I'm unsure what codebase you are using
> > and how to interpret the fact that it used to work not long ago.
> And what is your GnuTLS version? Did you by chance have it updated
lately?
> Also, what does (gnutls-available-p) return?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Wed, 02 May 2018 14:54:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 31313 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Wed, 02 May 2018 02:47:42 +0000
> Cc: 31313 <at> debbugs.gnu.org
>
> `gnutls-cli --version` reports 2.12.23, and the executable is a year old.
> (gnutls-available-p) returns (gnutls).
That's why your log is so different from Noam's.
Is it possible for you to build Emacs with a newer GnuTLS? Version
3.x is highly recommended.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Thu, 03 May 2018 03:26:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 31313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I tried gnutls-cli 3.5.18 and it works -- here's the *Messages* buffer
On Wed, May 2, 2018 at 7:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Wed, 02 May 2018 02:47:42 +0000
> > Cc: 31313 <at> debbugs.gnu.org
> >
> > `gnutls-cli --version` reports 2.12.23, and the executable is a year
old.
> > (gnutls-available-p) returns (gnutls).
> That's why your log is so different from Noam's.
> Is it possible for you to build Emacs with a newer GnuTLS? Version
> 3.x is highly recommended.
[messages (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Thu, 03 May 2018 17:45:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 31313 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Thu, 03 May 2018 03:24:52 +0000
> Cc: 31313 <at> debbugs.gnu.org
>
> I tried gnutls-cli 3.5.18 and it works -- here's the *Messages* buffer
So do we need to investigate this problem further, or can we deduce
that the problem is solved by a newer GnuTLS?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31313
; Package
emacs
.
(Fri, 04 May 2018 22:50:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 31313 <at> debbugs.gnu.org (full text, mbox):
The latter, as far as I'm concerned.
On Thu, May 3, 2018 at 10:44 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > Date: Thu, 03 May 2018 03:24:52 +0000
> > Cc: 31313 <at> debbugs.gnu.org
> >
> > I tried gnutls-cli 3.5.18 and it works -- here's the *Messages* buffer
> So do we need to investigate this problem further, or can we deduce
> that the problem is solved by a newer GnuTLS?
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 05 May 2018 06:40:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eric Hanchrow <eric.hanchrow <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 05 May 2018 06:40:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 31313-done <at> debbugs.gnu.org (full text, mbox):
> From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> Date: Fri, 04 May 2018 22:49:37 +0000
> Cc: 31313 <at> debbugs.gnu.org
>
> The latter, as far as I'm concerned.
Thanks, closing.
> On Thu, May 3, 2018 at 10:44 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > > From: Eric Hanchrow <eric.hanchrow <at> gmail.com>
> > > Date: Thu, 03 May 2018 03:24:52 +0000
> > > Cc: 31313 <at> debbugs.gnu.org
> > >
> > > I tried gnutls-cli 3.5.18 and it works -- here's the *Messages* buffer
>
> > So do we need to investigate this problem further, or can we deduce
> > that the problem is solved by a newer GnuTLS?
>
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 02 Jun 2018 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 75 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.