From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: scratch/package-security bcde5f8 2/2: Support expiration of metadata by package archives Date: Wed, 25 Nov 2020 21:44:22 -0500 Message-ID: References: <20201121234313.32698.75403@vcs0.savannah.gnu.org> <20201121234315.1991F209DE@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38847"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 26 03:45:28 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ki7Hj-0009zV-US for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Nov 2020 03:45:27 +0100 Original-Received: from localhost ([::1]:60494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki7Hj-0006xA-0B for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Nov 2020 21:45:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki7Gn-0006S1-UI for emacs-devel@gnu.org; Wed, 25 Nov 2020 21:44:30 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65368) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki7Gl-0006yQ-6J for emacs-devel@gnu.org; Wed, 25 Nov 2020 21:44:28 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B35D9440BF8; Wed, 25 Nov 2020 21:44:25 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D204D440775; Wed, 25 Nov 2020 21:44:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1606358663; bh=mRpiSjvZd2z7pvqHuXd4q2Oxr+9T9H64pKydQ25pO0o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=TGbguihQRufEPB1NKx3NhpQJFmMMk3wKusU7vSYp1lv3rNLXF/qSTWf+LR2oIwV3a usRCZ1WE1GPB/djzJok4CVfuRMNwmYasWTaZlNdjXWl54kraTzDu/pmxu33BqN8l6L oehX0MfwCYpdl8ub68F6Y/dnMnxbF5CP8mMG+9f1tqHnOQ4rQvjeB1rimHxjo5ONuy v4l/VqTlsCuOvAjojeJgAjN0DTBleMOXzZQnGbIIWY4cibOzHSPIOq0M0jTQ+AVAoJ 8efsrrKQ+GyXG6IX0jRRz3AonTyqjatf4b2pszJqAs3JJ7kgCVqXpelnxYL5HBsExd lpWG0cYYA2g6w== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 74EB41202BB; Wed, 25 Nov 2020 21:44:23 -0500 (EST) In-Reply-To: (Stefan Kangas's message of "Wed, 25 Nov 2020 21:24:23 -0500") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259819 Archived-At: >>> @@ -449,6 +458,7 @@ synchronously." >>> (define-error 'bad-size "Package size mismatch" 'package-error) >>> (define-error 'bad-signature "Failed to verify signature" 'package-error) >>> (define-error 'bad-checksum "Failed to verify checksum" 'package-error) >>> +(define-error 'bad-timestamp "Failed to verify timestamp" 'package-error) >> Hmm, these errors should all have a `package-` prefix. > Agreed. But I was worried that changing it would break some third-party > packages. I thought you just preferred to "go with the flow", which would make a lot of sense (i.e. keep the renaming for a separate patch). > Do we have a way to work around that? Not really, no. You could do (define-error 'bad-timestamp "Failed to verify timestamp" 'package-error) (define-error 'package-bad-timestamp "Failed to verify timestamp" 'bad-timestamp) so packages which catch `bad-timestamp` will also catch `package-bad-timestamp`, but then when package.el will presumably fail to catch the `bad-timestamp` raised by other packages. And we don't have a mechanism in place to mark an error like `bad-timestamp` as obsolete. > Or do you think this is not something we need to worry all that > much about? I wouldn't worry about it, indeed. >> It would be easier for the ELPA archives is to use a "validity duration" >> header, since it could then be constant. > FWIW, I feel like the current way is more human readable: I immediately > know the exact time and date when it will expire. That's fairly secondary to me. > Also, we don't need to have a number like "7" where it is not > immediately clear if it means hours, weeks or days, and we don't need to > write a parser for "7 days", "1 week", etc. but can just reuse existing > well-tested parsers. Ah... I assumed we could reuse existing code for that. If not, then it's definitely not worth the trouble. Stefan