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