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.bugs Subject: bug#19479: Package manager vulnerable to replay attacks Date: Wed, 25 Nov 2020 21:30:44 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21706"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 19479@debbugs.gnu.org, Noam Postavsky To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 26 03:31:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ki73v-0005XU-Pv for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Nov 2020 03:31:11 +0100 Original-Received: from localhost ([::1]:58452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki73u-0005RT-AU for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 25 Nov 2020 21:31:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki73m-0005RI-Bh for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 21:31:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54305) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ki73m-0002aB-2n for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 21:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ki73l-0004Nb-VD for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2020 21:31:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Nov 2020 02:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19479 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 19479-submit@debbugs.gnu.org id=B19479.160635785516822 (code B ref 19479); Thu, 26 Nov 2020 02:31:01 +0000 Original-Received: (at 19479) by debbugs.gnu.org; 26 Nov 2020 02:30:55 +0000 Original-Received: from localhost ([127.0.0.1]:37618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ki73f-0004NG-C1 for submit@debbugs.gnu.org; Wed, 25 Nov 2020 21:30:55 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ki73d-0004N2-Jj for 19479@debbugs.gnu.org; Wed, 25 Nov 2020 21:30:54 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C7D7F80EDD; Wed, 25 Nov 2020 21:30:47 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 06E9D806C9; Wed, 25 Nov 2020 21:30:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1606357846; bh=oJJUhr4mqzZE88Geqr0bAhlOEskCXs5FvkGz7ouA6NU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dDmA25BnJ8TEMKJGJm8M1yhvNR74OZFnHcMZ/E84cGG7OYbMhQs1kCkvpMri+5aHq u/yjOvEDSXU0HyHelAxJZPQCeTRMEsPJ9NpcG1DAhcJYaat6miFNL3mQZR9JruhToQ xGqOIDvM2yY7cIGbMEUjUls1Guf06DGXF5ZeXohyRCoAKjMrrE5n1KqguCzsO5Erdd iMipZxqCvxu/nGrqrf+CkV/CtmQS1wnRhmfm7G5WbPfFiQ/c3EISV/mAh8kVNRYo5h 7qunAryqDGzHTxe/gaxkCuJq67JgKRWVs6HstP7IJ9XX7qcRLCdwTorpoqosoRag6K ytLTScrXmr7+w== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B73D4120304; Wed, 25 Nov 2020 21:30:45 -0500 (EST) In-Reply-To: (Stefan Kangas's message of "Wed, 25 Nov 2020 21:06:38 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194254 Archived-At: > While not perfect, with a secure hash function, collisions are hard > enough to find that we for our purposes (like the rest of the world) can > happily not worry about it. In comparison, it is immeasurably easier to > fake a version number than having to defeat a hash function. I think > this is a significant drawback of what you propose. I'm not sure what you mean by it being easier: since the tarballs are cryptographically signed, just like `archive-contents`, if `archive-contents` points to `foo-42.1.tar` and that tarball has a correct signature and its content says that it is indeed the package `foo-42.1`, then I'm not sure which easy attack would be applicable. AFAICT you'd have to find some old signed tarball which we accidentally built with an incorrect content? But presumably if we ever mess up a tarball like that (which is indeed possible), we'd then want to be careful not to "reuse" that version number, no? > We would need to add in a number of assumptions (e.g. packages are > individually signed, Which they already are. > we never accidentally sign an old package with a newer version number, > etc.), That's indeed the case as well. > to gain more confidence in a simple version > number check. I think it's comparable: the main failings wold require some error on our side in how we build and sign packages, and in most such cases I think we'd end up with holes with either scheme. > But we could of course also check that the version number is correct. > That sounds like a useful sanity check to do. Exactly. > PS. Note that if we add a checksum, there will no longer be any need to > sign individual packages for future versions of Emacs. We would > then only need to sign the metadata. I think we'd want to keep the signatures anyway, e.g. they can still be checked manually for old tarballs which aren't listed in `archive-contents` any more. And more generally they allow authenticating the origin of a package without having to look it up in `archive-contents`. Stefan