[debbugs-tracker] bug#28780: closed (25.3; Bad signature from GNU ELPA whe coding-system-for-read is utf-8)

[GNU bug Tracking System]

Your message dated Tue, 10 Oct 2017 22:26:56 +0300
with message-id <address@hidden>
and subject line Re: bug#28780: 25.3; Bad signature from GNU ELPA whe 
coding-system-for-read is utf-8
has caused the debbugs.gnu.org bug report #28780,
regarding 25.3; Bad signature from GNU ELPA whe coding-system-for-read is utf-8
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
28780: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28780
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: 25.3; Bad signature from GNU ELPA whe coding-system-for-read is utf-8 Date: Tue, 10 Oct 2017 16:09:57 +0000

When installing a package (e.g. auctex), an error message appears:

Failed to verify signature auctex-11.91.0.tar.sig:

Bad signature from 474F05837FBDEF9B GNU ELPA Signing Agent <address@hidden>

Command output:

gpg: [don't know]: indeterminate length for invalid packet type 14

gpg: Signature made Tue 25 Jul 2017 11:10:02 PM CEST using DSA key ID 7FBDEF9B

gpg: BAD signature from "GNU ELPA Signing Agent <address@hidden>" [unknown]

This only happens if the following line in my .emacs:

(setq-default coding-system-for-read 'utf-8)

Steps to reproduce:

1. Run emacs -Q

2. Execute `(setq-default coding-system-for-read 'utf-8)` (e.g. go to

scratch, type this command, type C-x C-e).

3. M-x package-install auctex

4. Error message appears.

If step #2 is skipped, installation happens without an error.

In fact, this or similar problem seems to be quite common, but often

cannot be reproduced.

1. emacs bug#22971

2. https://emacs.stackexchange.com/questions/10046

3. https://github.com/jacksonrayhamilton/tern-context-coloring/issues/4

4. https://github.com/ananthakumaran/tide/issues/51

5. https://github.com/syl20bnr/spacemacs/issues/3669

6. https://www.reddit.com/r/emacs/comments/6t21lb/

7. https://www.linux.org.ru/forum/security/13718006 (In Russian)

...

In GNU Emacs 25.3.2 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)

 of 2017-09-12 built on lcy01-32

Windowing system distributor 'The X.Org Foundation', version 11.0.11804000

System Description: Ubuntu 16.04.3 LTS

Configured using:

 'configure --build=x86_64-linux-gnu --prefix=/usr

 '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'

 '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var

 --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu'

 '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode

 --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib

 --program-suffix=25 --with-modules --with-x=yes --with-x-toolkit=gtk3

 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat

 -Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:

XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS

NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:

  value of $LC_MONETARY: en_US.UTF-8

  value of $LC_NUMERIC: en_US.UTF-8

  value of $LC_TIME: en_US.UTF-8

  value of $LANG: en_US.UTF-8

  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:

  tooltip-mode: t

  global-eldoc-mode: t

  electric-indent-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 messages:

For information about GNU Emacs and the GNU system, type C-h C-a.

Making completion list... [4 times]

Load-path shadows:

None found.

Features:

(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml

mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies

mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail

rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu

cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util

tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type

mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt

fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register

page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock

font-lock syntax facemenu font-core 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 charscript case-table epa-hook

jka-cmpr-hook help simple abbrev 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 dbusbind inotify dynamic-setting

system-font-setting font-render-setting move-toolbar gtk x-toolkit x

multi-tty make-network-process emacs)

Memory information:

((conses 16 89919 7124)

 (symbols 48 19970 0)

 (miscs 40 701 121)

 (strings 32 15204 4512)

 (string-bytes 1 450810)

 (vectors 16 12462)

 (vector-slots 8 445519 6009)

 (floats 8 167 30)

 (intervals 56 242 1)

 (buffers 976 19)

 (heap 1024 38793 1016))

--

Iakov Davydov

Postdoc, Department of Computational Biology and Department of Ecology and Evolution, University of Lausanne

Swiss Institute of Bioinformatics

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#28780: 25.3; Bad signature from GNU ELPA whe coding-system-for-read is utf-8
>
>
>
>
> Date: 
>
> Tue, 10 Oct 2017 22:26:56 +0300
>
>
>
>
> > From: Iakov Davydov <address@hidden>
> > Date: Tue, 10 Oct 2017 18:55:05 +0000
> > Cc: address@hidden
> > 
> > After carefully reading the documentation for coding-system-for-read, I think 
> > you are right. It shouldn't be used
> > like that.
> > 
> > However the snipped including this command to "unicodify" emacs is mentioned 
> > in many places including
> > some answers on stackoverflow.
>
> That's why you should always treat answers on stackoverflow with a
> grain of salt (a.k.a. "suspicion").
>
> > I think you the bug can be closed, thank you.
>
> Done.
>
> >  > 2. https://emacs.stackexchange.com/questions/10046
> >  > 7. https://www.linux.org.ru/forum/security/13718006 (In Russian)
> > 
> >  I see no clear evidence that these reports are due to setting
> >  coding-system-for-read.
> > 
> > At least cases #2 and #7 have a very the similar error message (and the same 
> > package in one case).
>
> Yes, the messages are very similar.  But there's no data to point in
> the direction of coding-system-for-read being set.
>
> Thanks.
>
>
> --- End Message ---