From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#35739: Bad signature from GNU ELPA Date: Thu, 23 May 2019 00:06:19 -0400 Message-ID: References: <87mujog0ao.fsf@gmail.com> <835zqca15y.fsf@gnu.org> <83woir92vl.fsf@gnu.org> <83o93v83si.fsf@gnu.org> <83muje76wa.fsf@gnu.org> <83k1eh7rtj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="181675"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: rcopley@gmail.com, 35739@debbugs.gnu.org, npostavs@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 23 06:21:26 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTfEL-000l8G-RV for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 May 2019 06:21:26 +0200 Original-Received: from localhost ([127.0.0.1]:57350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTfEK-0004TQ-5z for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 May 2019 00:21:24 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTfEA-0004Bn-Jf for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 00:21:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hTf0Q-00011e-Dz for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 00:07:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58333) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hTf0Q-00011Z-BG for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 00:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hTf0Q-0002it-2t for bug-gnu-emacs@gnu.org; Thu, 23 May 2019 00:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 May 2019 04:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35739 X-GNU-PR-Package: emacs Original-Received: via spool by 35739-submit@debbugs.gnu.org id=B35739.155858439210414 (code B ref 35739); Thu, 23 May 2019 04:07:02 +0000 Original-Received: (at 35739) by debbugs.gnu.org; 23 May 2019 04:06:32 +0000 Original-Received: from localhost ([127.0.0.1]:43642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTezw-0002hu-5q for submit@debbugs.gnu.org; Thu, 23 May 2019 00:06:32 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTezt-0002hc-Td for 35739@debbugs.gnu.org; Thu, 23 May 2019 00:06:30 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D5BD11011A3; Thu, 23 May 2019 00:06:23 -0400 (EDT) Original-Received: from mail02.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B2688100A32; Thu, 23 May 2019 00:06:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1558584382; bh=kHjmJWYACFAMAusneqzNhwNzGG86KhKu7wSCjy/lvTM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=TKnluNUdi0RrA7QkXC5rXltAADorfRLngXyFlywxPo0N86QFxwwsKTPg3aEMUnUSN gytrLRrpYSrhDJI7TAJClKPHOiaB1CmotPi1y0xB80ue98KkQgs6WmCFEJDj+vFHCp IBZ7q+znGE693f3ljVpgd/7gg0CsMb7EMUUVsZJsRqKwV8Qr1S3DN/zZUzlvkpV8hT awCYrhVAMDP4h6M7bSjmLkPvJn2cZi7INCLbViGGDM8pAP9xBFKy5LnZ51bUgU36vC /rI8CaT7zU823xfTJh6+GzSnSvUHqF+a2Hx2P+pL4HenbZ5tD3iDUq01mZQqPeNCoY 3DQJbG8LNR3pA== Original-Received: from alfajor (unknown [216.154.3.168]) by mail02.iro.umontreal.ca (Postfix) with ESMTPSA id 2FB42120954; Thu, 23 May 2019 00:06:22 -0400 (EDT) In-Reply-To: <83k1eh7rtj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 May 2019 06:50:00 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159671 Archived-At: > Where is the decoding happening, then? According to what you write, > URL should just save the files as is, and then decoding should happen > when we access the resulting files after saving them. Is that what > happens after the changes? That's right. > Sorry for the typo: I meant list-packages. Does that display come > from the README files? It can come from various places, but the only case affected by my change is when it comes from the remote archive in which case it's indeed the *-readme.txt file that I do decode explicitly. > Other clients might need it in other ways. From what you explain, it > sounds like package.el doesn't need to decode at all when it > downloads, so it should disregard the 'charset' header and always > treat the stuff it gets as a raw byte stream. Is that correct? That's right. > If it is correct, then there's no need to make any changes in > url*.el routines. There is, because the routine that extracts the "raw bytes" is url-insert which (until my patch) also did the decoding according to the "charset" specified in the HTTP headers returned by the server (if present). IOW it didn't always return the raw bytes. Note that other clients will only be negatively affected by the change if: - the HTTP server has returned a "charset" in its headers. - they url-insert into a unibyte buffer. - they need the text to be decoded. The last two points should be mutually exclusive in sane situations, so I think the change is pretty safe. Or to put it another way, I think it's more likely to uncover or even fix a bug than to introduce one. Stefan