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: Wed, 22 May 2019 15:40:46 -0400 Message-ID: References: <87mujog0ao.fsf@gmail.com> <835zqca15y.fsf@gnu.org> <83woir92vl.fsf@gnu.org> <83o93v83si.fsf@gnu.org> <83muje76wa.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="93739"; 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 Wed May 22 21:41:14 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 1hTX6w-000OEP-EW for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 May 2019 21:41:14 +0200 Original-Received: from localhost ([127.0.0.1]:50434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTX6v-0003s8-2A for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 May 2019 15:41:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTX6o-0003pS-4Q for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 15:41:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hTX6m-0003LO-55 for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 15:41:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57673) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hTX6k-0003KG-5a for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 15:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hTX6j-00051B-Sd for bug-gnu-emacs@gnu.org; Wed, 22 May 2019 15:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 May 2019 19:41:01 +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.155855405719273 (code B ref 35739); Wed, 22 May 2019 19:41:01 +0000 Original-Received: (at 35739) by debbugs.gnu.org; 22 May 2019 19:40:57 +0000 Original-Received: from localhost ([127.0.0.1]:42984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTX6f-00050m-5F for submit@debbugs.gnu.org; Wed, 22 May 2019 15:40:57 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61197) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hTX6d-00050U-1K for 35739@debbugs.gnu.org; Wed, 22 May 2019 15:40:55 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A246B81164; Wed, 22 May 2019 15:40:49 -0400 (EDT) Original-Received: from mail02.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 64FDD80B93; Wed, 22 May 2019 15:40:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1558554047; bh=I2HiumJKRiZ2/dNVluA6efig8pJ/1F+xsIg4XZHDlIg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=aBKBRc0NdYkPiqiw0lWEutI6fhmvfGOMWlkx+rJmTwCBvAO0oRSbVFEzQIkTV9ats Z1eNxx/YgjWM9R5HPR/Z2HJz4dQrv9CulmAHeayGfhK5Hc9Gh5hfMccQDqOl21M1Qj P0P5Bs+OKtheyT7zYDP38LlFc5Xg9/C9HTJkoHfdpW3/qj+b1j8Z/kD2Fsr02nkJAz XIhR/h0s6D05/F8uSiBONF1NrE53qYsUFg2RZJem8vYwoKPIUpADAMXNSUKWOphwwS L6igWY1HgRCmJrJ6R1hhTquVx/A99ks6e73YLpNJqYfcxVyDedc7ByU+fUgOHbos82 j/7zx5K+GFBXw== Original-Received: from alfajor (unknown [216.154.3.168]) by mail02.iro.umontreal.ca (Postfix) with ESMTPSA id 20EE612015D; Wed, 22 May 2019 15:40:47 -0400 (EDT) In-Reply-To: <83muje76wa.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 May 2019 20:09:41 +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:159657 Archived-At: >> It solves the problem by refraining from decoding until we know >> positively that it needs to happen. > You refrain from decoding what? The files we download. > E.g., Lisp files must be in UTF-8, right? At first we don't care: we gets files (tarballs, GPG signatures, Elisp files, ...) and while some of them may need decoding later on, not all do. And for purposes of signature checking, for some of those files we need to get the exact original sequence of bytes, which is easier to get if we only decode *after* signature checking rather than before. For this reason we don't want to let URL do the decoding for us. It's true that for "simple packages" made of a single .el file, after signature checking we should maybe decode them as utf-8. The main thing we do with those is to save them as files and for that we don't need decoding. I haven't checked whether we do anything else significant with those undecoded .el buffers, so maybe I missed an explicit decode somewhere in there. > And what about the descriptions we show in lisp-packages? Not sure what you mean by that (I already mentioned the *-readme.txt files which we do decode explicitly now). > Or maybe I don't really understand why we need to decode _anything_, > since we just download a .tar archive, right? There's more than just tarballs. >> Yes, this part should definitely not be in emacs-26. > I'm actually asking why it should be on master. It seemed like a simple way to provide this new functionality. The functionality is needed at least by package.el, and I see no reason why it should be the only client of URL that needs this functionality. >> the change in url-insert only affects the case where the HTTP >> headers returned by the server specify a particular "charset", which >> is not the case when downloading .tar and .el files from >> elpa.gnu.org AFAICT > Why not? For tarballs, since it's not a text/* format, it wouldn't make much sense to specify a charset. For Elisp files, it might just be a happy accident of the configuration of the HTTP server, but my impression is that nowadays it's considered a bad idea to rely on the HTTP headers to tell you about the encoding (instead, the data contents should specify its own encoding), so it's only useful for text/plain files. > isn't that dangerous? Dangerous? definitely not. All it means is that if you try to view something like https://elpa.gnu.org/packages/xclip-1.8.el in your browser there's a possibility that it will not display the non-ASCII characters properly. Of course, most browsers I know won't display the file at all anyway (they ask you where to save it instead because they don't know what else to do with text/x-emacs-lisp). Stefan