From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? Date: Sat, 25 Apr 2020 12:15:47 +1000 Message-ID: References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <97DA7804-F647-4A1D-B8E0-AFFE7A324C64@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001326f705a41410ab" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="65060"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , ndame , Stefan Monnier , Emacs developers To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 25 04:16:56 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSANC-000GkG-1M for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 04:16:54 +0200 Original-Received: from localhost ([::1]:56604 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSANB-0004zU-0w for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Apr 2020 22:16:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56290) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSAMO-0004QY-35 for emacs-devel@gnu.org; Fri, 24 Apr 2020 22:16:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSAMM-0003U2-Qp for emacs-devel@gnu.org; Fri, 24 Apr 2020 22:16:03 -0400 Original-Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:39516) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSAMM-0003Nh-BK for emacs-devel@gnu.org; Fri, 24 Apr 2020 22:16:02 -0400 Original-Received: by mail-ot1-x336.google.com with SMTP id m13so15983006otf.6 for ; Fri, 24 Apr 2020 19:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ee6aLznArWIkfRlmht57i/oKOwkJoVWE9nGz3fpofc8=; b=XEvX4p9TmjNxlR/5SaLWGUB9xjsIs4d42BTLPgmXrr+xqmPXmffY3Ax8wd9nVBMlX3 rvsUr3Sq99ZxvQ0sYzbEyu/ACxrg5He8tkgpc0SyH30aN9akk1TuP1IwU2sW7CkAv3hM EATgRq16HyoK1zcwBqB7LTD2YTjEkuiYmrFvaejc5R9QX7tDcc5pSiTHEay8+vY9LELY zRabfah+7XCaSzFVqUtGJ35zSJvKr1TzCsJ3FOuteeerEpxQrDVyLJLIcztCDwHMpP5K 78jFpysmVDo+bptsQqy4tR3TyxUEOy84F+WSTJ4xjENqs9FV45USr3UfDYA1o+X2dpDd TLVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ee6aLznArWIkfRlmht57i/oKOwkJoVWE9nGz3fpofc8=; b=LDDjIFIR/1zeDnnmRXbInNB1Lt7QSTdUwrqLCCJXgVpHzQ/5Govih5LlNqOYCTLm64 oQ3BP4JnvJw97d8Bo1EqdCITttdoZx3/+nFt0ik8MUiJv9l6CSGPWoGjZw8Tf2nhSbfD msRAxEZhh7SDeFCK8FhaPDI0xhqn5+Zf5UP+Hg/YU6Lf3YX4O01AoBNO0nxLVmrx5/ya hCt5VU/q6MVfP0wbwZDhv1lmsrWA+zw7Nyw3VHXmQ+sxKSRTWFRgPmu4VXI3p35DL5CA NrYpSnV5xcKZH9ZkcDvFyYHyyzt9UIAKuHXbYbSavdRj6xuAz9hOKKQz8nFPWgmZPOWl t8DQ== X-Gm-Message-State: AGi0PuaCcMDvIJU4X5JF6STko+FY5aOSVsMuJ+lORzvEG8nvZxanaanS W30kKp3jXemRAfB/e7ElqDuzZ+76Nkmpd9EEAKk= X-Google-Smtp-Source: APiQypIR852xbxaxTZJlvCFezn4WVhfOk97Fzw6YqIniZeb4Mfg9NmVIt0FOtlqxgw/dfdYtKxkzAvx+rcX9jLFg/IM= X-Received: by 2002:a9d:810:: with SMTP id 16mr9912254oty.56.1587780959542; Fri, 24 Apr 2020 19:15:59 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::336; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x336.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::336 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247731 Archived-At: --0000000000001326f705a41410ab Content-Type: text/plain; charset="UTF-8" On Fri, 24 Apr 2020 at 18:56, Andrea Corallo wrote: > Tim Cross 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 --0000000000001326f705a41410ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
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.=C2=A0 We are not talking about a big
volume of binaries hard to verify that are continuously pushed by
developers.=C2=A0 With the current volume of commits we have on ELPA the ey= es
of other developers on elpa-diffs are sufficient.


That model sounds good, but simply fai= ls in reality. This has long been a claim of the open source movement - bec= ause the code is available, it is thoroughly reviewed and therefore a lot m= ore 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. R= eviewing of software is complex and time consuming. Those wanting to inuect= malicious content are clever and do so in ways that are extremely difficul= t to detect. There has already been 1 reply which indicates the volume of c= ommits is quite large, which makes the claim that all commits are scrutiniz= ed somewhat questionable. =C2=A0
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<= br> not sure is backuped by specific examples of the past happen in the ELPA re= po.


The fact it may ot have occurred does = not mean it won't. If plans to increase popularity and number of packag= es are successful, it is likely the associated risks will also increase. Pa= st experience is a very poor indicator when it comes to security - I was ne= ver burgled, until I was.
=C2=A0
Lastly wanted to mention that yeah... as a last resource 'git revert= 9;
exists :)

The problem with this approac= h is the damage has already been done. How bad that damage is depends on yo= ur own op sec, but it could be substantial.

I= don't disagree with empowering developers and giving them more respons= ibility. Having good security and enabling developers to have more responsi= bility are not mutually exclusive. You can have both and despite popular op= inion, it does not have to come with high levels of inconvenience or mainte= nance overhead.

A good security model needs t= o fulfill 3 requirements

1. People only have acces= s to what they need. The current model fails with this requirement as devel= opers have access to modifying code they are not responsible for.
2. Simple, reliable and robust. The system needs to be easy to use and und= erstand. 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, peop= le will find a means to work around it and often in ways which severely com= promise security. The current model is very convenient, but due to 1), is n= ot very secure.
3. It needs to be auditable. Things will go w= rong and when they do, you need to be able to identify what has happened an= d 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 acce= ss etc.

Having been involved in helping compa= nies 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 ser= ver, firewall etc. Individuals are frequently unaware they have been compro= mised. Developers often make mistakes, like accidentally committing test co= de which contains sensitive data, committing a private key or config file c= ontaining 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 a= nd security. There are several models you could adopt which would restrict = developers to only have access to the code they are responsible for which d= o not impose high levels of inconvenience or maintenance overhead. The impo= rtant 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 ensur= e such issues are addressed. =C2=A0

Tim
--
Tim Cross

--0000000000001326f705a41410ab--