From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id jojfHzBjwF8dOQAA0tVLHw (envelope-from ) for ; Fri, 27 Nov 2020 02:23:44 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id qJoQGzBjwF9UDAAAbx9fmQ (envelope-from ) for ; Fri, 27 Nov 2020 02:23:44 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BF9BB94023A for ; Fri, 27 Nov 2020 02:23:43 +0000 (UTC) Received: from localhost ([::1]:41556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiTQE-0005cQ-OJ for larch@yhetil.org; Thu, 26 Nov 2020 21:23:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiTPX-0005bx-EX for emacs-orgmode@gnu.org; Thu, 26 Nov 2020 21:22:59 -0500 Received: from static.rcdrun.com ([95.85.24.50]:59743) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiTPV-0007jJ-CX for emacs-orgmode@gnu.org; Thu, 26 Nov 2020 21:22:59 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C000B.000000005FC062FE.00002AFB; Fri, 27 Nov 2020 02:22:53 +0000 Date: Fri, 27 Nov 2020 05:19:43 +0300 From: Jean Louis To: Tim Cross Subject: Re: Security issues in Emacs packages Message-ID: References: <875z5s62x3.fsf@gmail.com> <3505547.1606393642@apollo2.minshall.org> <87wny74v5w.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87wny74v5w.fsf@gmail.com> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg Minshall , emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.21 X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-TUID: esay7sCVhQt0 * Tim Cross [2020-11-27 01:21]: > > Greg Minshall writes: > > > Tim, > > > >> It could, but to get that level of assurance, you not only have to > >> verify the signature is valid (something which is automated if > >> enabled), you also need to verify that both packages have the exact > >> same signature, which is pretty much a manual process. So in addition > >> to telling you the version number, George would also need to > >> communicate the signature and that would need to be compared to the > >> signature you have in the package you downloaded to know that the > >> packages are in fact the same (you cannot rely on version numbers for > >> any real verification). > > > > if MELPA's release procedure prevented two separate releases of version > > 1.2.3 of package xYandZ from being released, wouldn't that obviate the > > requirement for George to give me signatures? that was my thought as to > > why a signed (MELPA, version number, package name) would be enough. > > (i've no idea if MELPA's procedures would actually conform to my > > "requirement".) > > > > Possibly, but I'm not sure it does/can. From my limited understanding, > the version number is determined by the git tag (for stable packages - I > think the date is used for unstable). This is as it should be as it > should be the package maintainer who controls the version number, not > the packaging service (especially for maintainers who use semantic > versioning where the version number actually conveys information about > the package). Before some days or weeks we discussed this in a different thread, not this mailing list. I think emacs-devel. Authors are by convention writing their version numbers in their packages aligned to the Emacs Lisp manual section on Packaging. MELPA is injecting their version they are taking from git as commit number. Thus MELPA does not use author's version number. It should be obvious from package-list-packages that same version of the package in GNU ELPA does not have same version number in MELPA, that is confusion created for no good reason but to minimize programming efforts at MELPA. > At the end of the day, this is essentially a supply chain problem. To > really have confidence, you need confidence in the whole supply chain, > not just the distribution centre. Either way it could be good and depends what does the distribution center do. If they are auditing packages and making sure of security or are they just packaging without any audit. Maybe distribution center verifies all PGP signatures and we may trust such center, maybe not. The OpenBSD software audits packages. It cannot ever be fully secure but for base system one can rest assured that developers have put a lot of effort in making it secure. Trust with users is then created based on the relation and background of the OS distribution. > Personally, I wish both GNU and Melpa had adopted a push mechanism for > package release. Something similar to npmjs.com where the package > author/maintainer would submit a signed package (publish) to the > repository. This would make it producers of the package code we trust, > not the distribution center (repository). I wish that too.