Tim Cross <address@hidden> 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.