From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: Re: Fwd: Should package.el support notifying on package security updates? Date: Sat, 13 Aug 2022 06:58:33 +0200 Message-ID: References: <87r12qm4q5.fsf@gmail.com> <87y1vus4xy.fsf@rfc20.org> <86y1vul261.fsf@gmail.com> <86tu6h0x3d.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hrUvX+nefBO0UT75" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38133"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 13 06:59:47 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 1oMjFT-0009lZ-6a for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Aug 2022 06:59:47 +0200 Original-Received: from localhost ([::1]:51640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMjFR-00054I-Vi for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Aug 2022 00:59:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33530) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMjEM-00042e-0K for emacs-devel@gnu.org; Sat, 13 Aug 2022 00:58:38 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:47668) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMjEJ-00081K-Ok for emacs-devel@gnu.org; Sat, 13 Aug 2022 00:58:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=85nIM9hEQ+xwQKJoHlmKRRGgqQdThGGF8AVQZ/WMdek=; b=SAdBe5jQDaXmJVukvQM8r3P/Ez kJivuREA9sivlO0QiQNJ7p5VTXE70d2HMk2Hzxh9hNlxERpy9mGcBR0YyjknlvTHW7ug8SgkN5TZH w/V0e7r5z7emCRkw+rqMAti5VxEITr7QrHk5U4dUPf8FQylROPGaEQEQsmiDu2A5Ho3/XpCMR1n4p emvbP5/6imUkkN+DWv4uxi6OrHnOwhL5SCXJ0GmSWmFI2exXUlFwnl4TEBvRC4L3x1n4P8Kv7Pb1E fNd6g0L8aaRwvdM497lX1HOIWsnddcatNr1acsZ9fbCV4zNSsojb7a9d9IX4ViGcyINI2iDh9wHBR R9IULX3w==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1oMjEH-0001Wj-38 for emacs-devel@gnu.org; Sat, 13 Aug 2022 06:58:33 +0200 Content-Disposition: inline In-Reply-To: <86tu6h0x3d.fsf@gmail.com> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de 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, 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:293402 Archived-At: --hrUvX+nefBO0UT75 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 13, 2022 at 10:58:40AM +1000, Tim Cross wrote: >=20 > Stefan Monnier writes: >=20 > > > > I'm not sure it would be a big problem. But I'm not sure it would be an > > improvement either. Especially because I suspect it might give the > > false impression that the code of ELisp packages is somewhat > > security-conscious, whereas in my experience, the vast majority of Emacs > > packages isn't (they may end up secure by accident, of course). > > > > >=20 > That is an extremely important point. Very few people even gives this a > thought when installing packages - especially packages from MELPA and > other external repositories. Having 'security' would imply for some that > there is a formal security process for reviewing, tracking and reporting > security issues. We don't have any of this and advertising some updates > as security fixes could well create a false sense of security.=20 Actually, in the context of Linux (the kernel), this question is a longstanding discussion and regular fodder for flame wars. While the core Linux developers (most prominently Linus Torvalds, but also Greg Kroah-Hartmann) adamantly stick to the standpoint that any issue is a potential security issue, so it doesn't make much sense to arbitrarily flag some issues as security relevant. Actually. they say, it is counterproductive. There is, of course the opposite position (there are flame wars, after all). What the latter don't want to see is, that there actually are three categories: (a) a proven security issue (there is a known exploit); (b) the grey zone (we don't know); (c) for sure not security relevant -- can you even prove such a thing?), =2E..and most of the issues are in (b). Besides, there won't be a universal set of criteria everyone will agree upon. It takes a significant amount of work to extract an issue out of category (b) (aka "dunno") into either (a) or (c) I think people advocating for such a flagging should somehow try to dig up the resources for that. Regular developers are more than busy fixing known issues, finding new ones, or not making mistakes in the first place. So the advocates of having this kind of flagging should be the ones responsible for digging up new resources, IMO. Cheers --=20 t --hrUvX+nefBO0UT75 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYvcvcgAKCRAFyCz1etHa RmxDAJ9BBgepXr7pZVIEwHdRLQKBOqUMogCdFEem9wpsCGTUfYltbKgWvzAixoQ= =V6Lv -----END PGP SIGNATURE----- --hrUvX+nefBO0UT75--