Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross <theophilusx@gmail.com>]

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

On Fri, 24 Apr 2020 at 18:56, Andrea Corallo <akrl@sdf.org> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > I don't think it is quite that simple.
> >
> > Your not just trusting that person will do the right thing. You are
> > also trusting that they also have good operational security. It is
> > precisely this sort of trust model which resulted n a number of GNU/
> > Linux distributions being compromised in the past.
>
> IMO the comparison does not stand.  We are not talking about a big
> volume of binaries hard to verify that are continuously pushed by
> developers.  With the current volume of commits we have on ELPA the eyes
> of other developers on elpa-diffs are sufficient.
>
>
That model sounds good, but simply fails in reality. This has long been a
claim of the open source movement - because the code is available, it is
thoroughly reviewed and therefore a lot more secure. Sounds good, but as
has been shown in other projects (consider openSSL for example), this is
not the case. While having access to the code is extremely important,
relying on ad hoc review is a very weak control. Reviewing of software is
complex and time consuming. Those wanting to inuect malicious content are
clever and do so in ways that are extremely difficult to detect. There has
already been 1 reply which indicates the volume of commits is quite large,
which makes the claim that all commits are scrutinized somewhat
questionable.

> I believe giving a little more responsibilities to developers is also a
> fundamental stimulus to involve them more.
>
> This need for security is most likely not to be beneficial and BTW I'm
> not sure is backuped by specific examples of the past happen in the ELPA
> repo.
>
>
The fact it may ot have occurred does not mean it won't. If plans to
increase popularity and number of packages are successful, it is likely the
associated risks will also increase. Past experience is a very poor
indicator when it comes to security - I was never burgled, until I was.


> Lastly wanted to mention that yeah... as a last resource 'git revert'
> exists :)
>

The problem with this approach is the damage has already been done. How bad
that damage is depends on your own op sec, but it could be substantial.

I don't disagree with empowering developers and giving them more
responsibility. Having good security and enabling developers to have more
responsibility are not mutually exclusive. You can have both and despite
popular opinion, it does not have to come with high levels of inconvenience
or maintenance overhead.

A good security model needs to fulfill 3 requirements

1. People only have access to what they need. The current model fails with
this requirement as developers have access to modifying code they are not
responsible for.
2. Simple, reliable and robust. The system needs to be easy to use and
understand. If it is too complicated, it cannot be easily verified or
modified to fit evolving requirements. If it is too hard to use or
unreliable, people will find a means to work around it and often in ways
which severely compromise security. The current model is very convenient,
but due to 1), is not very secure.
3. It needs to be auditable. Things will go wrong and when they do, you
need to be able to identify what has happened and when. Git logs are pretty
useful in this area. However, I don't know what the process is for adding
access, verifying accounts or reviewing access etc.

Having been involved in helping companies recover from security breaches, I
cannot stress enough how much time, resources and effort it takes. Too
often, such breaches are caused by poor security practices of individuals
rather than a lack of security at the server, firewall etc. Individuals are
frequently unaware they have been compromised. Developers often make
mistakes, like accidentally committing test code which contains sensitive
data, committing a private key or config file containing access tokens etc.
A simple revert will not remove such sensitive data. and requires you
realise the error has occurred.

The key point is there is no reason you can't have convenience and
security. There are several models you could adopt which would restrict
developers to only have access to the code they are responsible for which
do not impose high levels of inconvenience or maintenance overhead. The
important thing is to make this a core requirement and not an after thought
as trying to do this retrospectively is always harder and less successful.
If there is to be a real effort to increase the number of packages
considered to be part of GNU Emacs and included in ELPA, then now is the
time to ensure such issues are addressed.

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 5844 bytes --]