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: ELPA security (was: Proposal to include obligatory PGP verification of packages from any repository) Date: Mon, 19 Oct 2020 15:00:48 -0400 Message-ID: References: <20201013052736.GE31408@protected.rcdrun.com> <20201016130235.06218dae@argon> <87eelvplvh.fsf@posteo.net> <10bdf4ea-e365-cc3d-ec03-4348946fadbe@yandex.ru> <20201019124335.GC19325@protected.rcdrun.com> <20201019182828.GB1842@odonien.localdomain> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9114"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Philip K." , rms@gnu.org, thibaut.verron@gmail.com, mve1@runbox.com, emacs-devel@gnu.org, Dmitry Gutov To: Jean Louis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 19 21:03:06 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 1kUaQz-0002GQ-R1 for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 21:03:05 +0200 Original-Received: from localhost ([::1]:56878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUaQy-000855-Rk for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 15:03:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUaOw-0006vs-8D for emacs-devel@gnu.org; Mon, 19 Oct 2020 15:00:59 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36995) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUaOs-0000f7-Em; Mon, 19 Oct 2020 15:00:57 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id ABA17100D3B; Mon, 19 Oct 2020 15:00:52 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8C2C610001F; Mon, 19 Oct 2020 15:00:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1603134050; bh=BZzZrVoJyUtpJBtyI2HPT4J8jkTkzfSWIScqu4xH+2M=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=YMXkJXkz/Tnbrti8tDr7pn4iG00DSFOzpJK6+gmPzt5xrinIYwL/bufWHbUuKoejv ikdyyej2mDp9IURqmF+7A9vOwsi9iPlY40i5KBIs8Xhg2SRer/F9pzH9anrj8lPHoW h2+CEaDzKC75uzlGaVN00BruQClosQCPWpgMejz+9zQlNZJwNbmEzrovIMedrRi3MY FUWzq7c6PFslutzXmG99pQUWfE9qAKUiN5F14J9r+ubzPDLFWkZLfEWaqcxPSihmfT SAg23crMFdKWJUsWP6YK+DI65Fy6ja5cMm0a4zv672/hotSScyVEu9rKeh9sWlaeRh XRQ6ooyhnC+VA== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8EC9C120188; Mon, 19 Oct 2020 15:00:49 -0400 (EDT) In-Reply-To: <20201019182828.GB1842@odonien.localdomain> (Vasilij Schneidermann's message of "Mon, 19 Oct 2020 20:28:28 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 13:18:36 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] 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:258142 Archived-At: > That aside, how does this quality assurance look like for GNU ELPA? > Is it users subscribing to a commit mailing list and looking out for > anything suspect? Kind of, tho there's no such statement of intent. There's a mailing-list where most(!) commits get sent, and some people subscribe to it, but there's no reason to assume that they subscribe to it specifically to review commits, let alone keeping an eye out for quality or security issues. I'm pretty sure several commits sent to the list aren't (re)viewed by anyone at all. I do subscribe to that mailing-list and perform a basic amount of reviewing, but it's more geared towards catching mishaps and helping contributors improve their code. It wouldn't take much effort for an attacker to make sure I don't look at his backdoor, I think. > Fewer releases overall? Definitely. > I doubt that code is audited for every release either and that > security issues are instead dealt with in a reactive instead of > proactive manner (meaning, as soon as one is known of, appropriate > measures such as a security release are taken). Definitely. The main source of "proactive" security is the fact that the code is fully visible to anyone who wants to look, and the presumed low benefits of introducing a backdoor in an ELisp package. > Another important aspect: Say that non-GNU ELPA manages to catch up > with MELPA in terms of package count, does the existing review system > still work? I think it'd largely end up similar to MELPA. > Will new measures be necessary to guarantee security (for example by > designing packages in terms of a more restrictive approach with > permissions, sandboxing and whatnot)? I strongly suspect that they > will be and merely mirroring MELPA packages won't suffice. The nature of ELisp makes sandboxing/permissions pretty difficult to implement, so I think we'll just hope for the best, like MELPA does. An alternative might be a system where we force/require some minimal amount of code review before publishing a package, which may work if the ELPA archive is popular enough that the annoyance of delayed releases motivates people to contribute to the review effort rather than to move to a more permissive archive. Stefan