emacs-devel
[Top][All Lists]
Advanced

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

Re: security-patches package


From: Phillip Lord
Subject: Re: security-patches package
Date: Thu, 21 Sep 2017 21:01:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> On Fri, 15 Sep 2017 08:32:16 -0400 Stefan Monnier <address@hidden> wrote: 
>
> SM> having a "security-patches" package might make sense.
>>> I would love to see that as well, especially if it was well tested in a
>>> CI system against various versions of Emacs.
>>> What needs to happen so the experience is seamless?
>
> SM> Step one is to create this package in elpa.git, putting the fix for the
> SM> enriched.el bug.
>
> A package is pretty easy but I have a few questions before putting that
> out:
>
> * how do we prevent accidental or malicious commits to this package?
>   Could it maybe live in a special "GNU ELPA security updates" archive
>   separate from elpa.git?

I think this is not important. It wouldn't have any special privilege;
i.e. the malicious user could do the same nasty things in any package.
Accidental commits could just be controlled by constraining the
*release* -- that is commits would be normal, but they wouldn't go live.


> * should it be signed+released in a special way? How do we test it?

Testing is hard, unless we produce a "alpha" version of ELPA (try saying
that when drunk).

> * what version of Emacs will begin to check for this package?

Emacs 26, more or less by definition.

> * Can we do push notifications somehow or are we limited to polling?

Polling. Worse polling at the users request, because ELPA doesn't also
update.

Changing ELPA to auto-update the archive would be a good thing to do, I
think.

> * should there be a special mailing list for internal discussions?
>
> * how do we make the experience seamless (on startup, during a
>   long-running session, unattended, for a whole site)?
>
> In a related vein, I mentioned a while ago that it would be really nice
> to see the changes (from what's installed) to all the code in a package
> before upgrading it. I think for security updates that would be
> especially useful.

That would be cute, for non-security also. Give people a reason to
update.

Phil



reply via email to

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