unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: <tomas@tuxteam.de>
To: emacs-devel@gnu.org
Subject: Re: Fwd: Should package.el support notifying on package security updates?
Date: Sat, 13 Aug 2022 06:58:33 +0200	[thread overview]
Message-ID: <YvcveXullXqScmj3@tuxteam.de> (raw)
In-Reply-To: <86tu6h0x3d.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

On Sat, Aug 13, 2022 at 10:58:40AM +1000, Tim Cross wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >
> > 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).
> >
> >
> 
> 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. 

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?),

...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
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2022-08-13  4:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r12qm4q5.fsf@gmail.com>
2022-08-08  1:46 ` Fwd: Should package.el support notifying on package security updates? Gulshan Singh
2022-08-12  0:04   ` Matt Armstrong
2022-08-12  0:29     ` Tim Cross
2022-08-12 13:18       ` Stefan Kangas
2022-08-13  0:44         ` Tim Cross
2022-08-12 21:40       ` Stefan Monnier
2022-08-13  0:58         ` Tim Cross
2022-08-13  4:58           ` tomas [this message]
2022-08-13 14:00             ` Stefan Monnier
2022-08-14  3:23     ` Richard Stallman
2022-08-14  3:29       ` Gulshan Singh
2022-08-16  2:52         ` Richard Stallman
2022-08-25  3:32         ` Richard Stallman
2022-08-25  4:33           ` Tim Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YvcveXullXqScmj3@tuxteam.de \
    --to=tomas@tuxteam.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).