emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ELPA security (was: Proposal to include obligatory PGP verification of p


From: Stefan Monnier
Subject: ELPA security (was: Proposal to include obligatory PGP verification of packages from any repository)
Date: Mon, 19 Oct 2020 15:00:48 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]