From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Fwd: Should package.el support notifying on package security updates? Date: Fri, 12 Aug 2022 10:29:22 +1000 Message-ID: <86y1vul261.fsf@gmail.com> References: <87r12qm4q5.fsf@gmail.com> <87y1vus4xy.fsf@rfc20.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="30980"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.8; emacs 29.0.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 12 02:47:17 2022 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 1oMIpZ-0007pt-4W for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Aug 2022 02:47:17 +0200 Original-Received: from localhost ([::1]:49350 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMIpX-00058N-Ga for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Aug 2022 20:47:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51170) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMIoS-0004Or-0U for emacs-devel@gnu.org; Thu, 11 Aug 2022 20:46:08 -0400 Original-Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]:40529) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMIoQ-0005sS-5G for emacs-devel@gnu.org; Thu, 11 Aug 2022 20:46:07 -0400 Original-Received: by mail-pg1-x536.google.com with SMTP id 24so2067937pgr.7 for ; Thu, 11 Aug 2022 17:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:from:to:cc; bh=xJRQ04Chi4oX7tngHlgtaQsEOX7XUCYv+YMOXHHeh4c=; b=MzZkgw0edyCe3vdG/CQAplqkBgRESbg8/4/q63YGeUwL+bA+OymPVmlnbAsydscxew KM5v6kNTaYqPImiUGvpNoC9RMjxuZvMxX26N+jN4gXGDpaVtbCqRDg9rULStrjPi/4q/ BJElZBI/oX6nmEqFbQdbfkhrtF4GIPtOfjE68E/Odqi1txFQGqtVx/kUr484k8g6FKTy d4P48mNJ3reft43tlMgg7bDqh5u9Y2EEAdMcjXXOzHiT1wdEsHSuARoqK2+kkkXJg9NZ RJ3MgnPQENvgJeNTf5oUtnJvBrPQxPX+SR0lqPz0i+5JnpL7gDsNCF46joDq4mF0QIQg 9SrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:x-gm-message-state:from:to:cc; bh=xJRQ04Chi4oX7tngHlgtaQsEOX7XUCYv+YMOXHHeh4c=; b=EnJ7Yewa1dWy0fNV8cxV/pkQtpI4OZhYIGKmQp641w9b4LqdOukqdpZU04vMrhXxxb rUNVmYNQwV+pEKhwDO/bYPqpUP9xJQCjBOdP23XSGABCHUAjT/uq7EmkwIY+GD3oEwEN WltmIy6Gpn9vJ6ENoueG/2Yj/ZTO1LWIKTmiQKA+KzBAaVlh1MrpIik9BpY7aYI3as41 15HrbpcK/IvsCwyhDfPARYiE7lp6XB2AohAD4a5DPw/Hnu31s0aS0ypHCSwb5HJhYKpP a2YSUkj+Ddkycb06cd0g/wvd1VSdarpDXBiLtWO2yxngvhDvRp6E3b3kJnCz95yQey3U D2jg== X-Gm-Message-State: ACgBeo1RozO/4e544J0aPWytStFazqZY+PJTQ2jjoPPg7+DlWjY7OQTF B0uv9onvDmKc+g+yrxls7NesIupqiKr2qw== X-Google-Smtp-Source: AA6agR7Sx+ztwpMCLj1h9KEArE2adXXTwTY8F2Kqg3xFAbaruODnueEHUO7Q0uaiXPNzBvIFtEq7Pw== X-Received: by 2002:a63:464b:0:b0:419:78b4:dcf1 with SMTP id v11-20020a63464b000000b0041978b4dcf1mr1188339pgk.500.1660265164026; Thu, 11 Aug 2022 17:46:04 -0700 (PDT) Original-Received: from dingbat (2001-44b8-31f2-bb00-842a-7361-87c7-2662.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:842a:7361:87c7:2662]) by smtp.gmail.com with ESMTPSA id t7-20020a1709027fc700b0016d737bff00sm273418plb.220.2022.08.11.17.46.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Aug 2022 17:46:03 -0700 (PDT) In-reply-to: <87y1vus4xy.fsf@rfc20.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::536; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x536.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:293381 Archived-At: Matt Armstrong writes: > Gulshan Singh writes: > >> I recently reported a security issue for a package on MELPA, where >> even though I trusted the package author, if I used the package to >> process untrusted data that data code be crafted in a way to execute >> arbitrary code on my system. This led me to wonder if there was any >> mechanism for package.el to distinguish between regular updates and >> security updates, and I wasn't able to find any information on this. >> >> Has there been any past discussion on this? As an example, on Ubuntu you >> can see how many of the pending updates are security updates as opposed >> to regular updates, and you can configure the system to auto-update just >> the security updates. I feel like the package manager in emacs should >> have something similar, but maybe I'm missing something about why this >> functionality isn't included. > > I am not an authority on Emacs packages, but as far as I am aware, there > is no mechanism in place to track security vulnerabilities in Emacs > packages or any way to urgently present available fixes to users > (e.g. by suggesting a partiular package upgrade is urgent). > > One substantive discussion I found on package security issues in general > occurred on emacs-devel 9 years ago: > > Subject: security of the emacs package system, elpa, melpa and marmalade > Date: Mon, 23 Sep 2013 09:30:35 +0200 > https://lists.gnu.org/archive/html/emacs-devel/2013-09/threads.html > > Shortly after that discussion it looks like package.el was changed to > verify package signatures (at least optionally, based on the > availability of a gpg installation, which went through refinement over a > period of years). While I don't disagree with the underlying principal, I suspect it would likely add additional complexity which will end up being of little actaul benefit. This is for two reasons - There are actually very few security issues reported for Elisp packages. This doesn't mean there aren't any, only that they are discovered and reported very rarely. - It would require package maintainers to somehow flag that an update is a security update rather than just a standard update. As it is already somewhat challenging to get many package maintainers to include consistent change logs in their packages, I suspect then also asking them to distinguish security updates from normal updatges may be asking too much. I think the big difference with the Emacs package ecosystem from Ubuntu (and other GNU Linux distributions) is that there is no central authority managing package releases. With Ubuntu, there is a team who are responsible for the maintenance and release of all core Ubuntu packages. This brings a level of consistency which is difficult to achieve with Emacs where many packages are managed by individuals and separate groups (especially when it comes to MELPA). The breadth of packages included in a distribution also results in packages which have more frequent security issues discovered (possibly due to different size in user base, different type of application or inherently higher security risk). I suspect if we added the functionality to flag an update as a security update, it is something which happens so rarely, nobody will use it and when they do, nobody will recognise what it really meant. All that will really be achieved is a more complicated system, potentially adding more bugs (possibly even security issues!).