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: Fri, 24 Apr 2020 09:50:36 +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="000000000000f7a9f705a3fdeaae" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="5190"; 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 Fri Apr 24 01:52:01 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 1jRldQ-0001Cv-R2 for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Apr 2020 01:52:00 +0200 Original-Received: from localhost ([::1]:45432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRldP-0004kt-R7 for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Apr 2020 19:51:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53836) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRlcM-0004Bm-Fm for emacs-devel@gnu.org; Thu, 23 Apr 2020 19:50:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRlcJ-0007pH-2e for emacs-devel@gnu.org; Thu, 23 Apr 2020 19:50:52 -0400 Original-Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]:46542) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jRlcH-0007kG-OR for emacs-devel@gnu.org; Thu, 23 Apr 2020 19:50:50 -0400 Original-Received: by mail-ot1-x331.google.com with SMTP id z25so9339488otq.13 for ; Thu, 23 Apr 2020 16:50:48 -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=hGqID5zmQbEL6QmvMlxmHufPR+gZ7wwf11an8fZJdbA=; b=Jp3ULp2CH8Gt3IuXC9Kje34B4jzY8nVCaNqqwNV2V16s4bC/d0/DvRVOYQC82EdXma tMN2RXar03kJsa5pUmzSafYgI/JMZLS4DOiD8bovtHA2pKTfOMCh/OCKO4bcc+swzmcN b5ku4n1sGeWfnE+QExR62ngdpqP7LqviDuUm8dk2a2Fz/vyikvQ58vJUFX9pldIv9fQL kFTqNkFLeA/Eh+j5JaPENyOHfUhhe8QI9/rbzib9KyXOkayeqy4UacJk8MMs8vEJ9bmx Lii+lpCmzLVYIl4J7FCzt7oKnZmG4Z50QlmzMtdfNFCHvZE3Zb6dD1cg3xBQgAfjrtDf nOkw== 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=hGqID5zmQbEL6QmvMlxmHufPR+gZ7wwf11an8fZJdbA=; b=jQge1CKZlwlzV97FQ78EKMljf1ObCNNjsOLt/Hh1fMkILBld4967QjkoXMDyiMtcFQ Is15BvnKAAVx98GsVNPILxN2FKwYCVCCLUlSBrW1Pzd654TRxhPtqe1bNhTVoz732jhl +kSQHklEp27towNGDHuZEgeWxsHQR79U6pGmmP4kTVm2/rmR4o8lIAu6iHBdTaXoqdNa 0t8rA7xUGp7cDsOshtiaMxh+/gB13beqmz1Ucwc0K8xw5G+HHPgP7jgFilJKuW+ADgTR qZtj9JkRf0fFciARLHaiA8lVfBOm8Ptq0HNC3HvsrJIcn1JkITShmZ3riwvG2q7YqDgx N7qg== X-Gm-Message-State: AGi0PuZR7PXM7gVh81Czi88FWCWf9bD52re/Lp3uxpKtH+HZB2qHO3Ev usk2Nnb/jfFEU3zwC8ErvsaDBKHqBqqB8ptwpGI= X-Google-Smtp-Source: APiQypL3aOzydy7CFGiHBsXoNMx3DAltk4ElmJV2IaJM0bzBFQn7mH/3RRDbnK0fDIP9hRhU7CVn8g/K4jhEX2ggTy0= X-Received: by 2002:a9d:1786:: with SMTP id j6mr5310818otj.235.1587685847704; Thu, 23 Apr 2020 16:50:47 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::331; envelope-from=theophilusx@gmail.com; helo=mail-ot1-x331.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::331 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:247644 Archived-At: --000000000000f7a9f705a3fdeaae Content-Type: text/plain; charset="UTF-8" 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. The same thing has occurred with NPM and other 'public' repositories. It wasn't that people who had access did the wrong thing, but rather people who had access who failed to secure their systems adequately. You only need to do a search of places like github to see how often people accidentally commit sensitive data or look at the analysis of repositories that have been compromised to see how often this occured because passwords were poor, keys were not secured or sensitive data was accidentally posted to public forums. The only real solution is one where each package maintainer is isolated from write access to code/packages they are not authorised to maintain. The challenge is, such setups usually also result in higher levels of maintenance overheads and that can often be a challenge for an organisation which needs to walk a tight line wrt funding. To make matters worse, typically, it is almost impossible to have good security retro fitted to a solution this is something which needs to be designed into the architecture from the start. This means that to fix this problem would require a considerable amount of work and change. The change part is extremely difficult as most people simply don't like change (as is evident in many of the discussions about updating how we handle patches, pull requests, defaults, etc). On Fri, 24 Apr 2020 at 07:51, Andrea Corallo wrote: > Stefan Monnier writes: > > > That's right. There is a practical problem, OTOH, which is that > > write/push access to a GNU ELPA package currently means write access to > > all GNU ELPA packages as well as to Emacs's repository. > > > > For this reason, while some GNU ELPA package maintainers can "just push" > > as they see fit, as it should be, others haven't yet been granted this > > right. This is a problem which we should solve, indeed, for the benefit > > of those less-lucky package maintainers, as well as for the benefit of > > those Emacs maintainers who have to play the middle men, and more > > generally for the benefit of the GNU ELPA archive and hence Emacs users > > since the current situation tends to discourage submissions. > > > > Note that giving write access widely, as we do now, has advantages as > > well, in that it encourages package maintainers to participate in > > development of Emacs more generally. > > To me the fact that a number of package maintainers is without write > access sounds quite odd. > > If they are trusted to maintain a package they are supposed to have also > the skills to push correctly a git commit. > > Looking at other Free Software projects I'm involved I can testify that > trust pays off and I think they should get write access. My 2 cents. > > Andrea > > -- > akrl@sdf.org > > -- regards, Tim -- Tim Cross --000000000000f7a9f705a3fdeaae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think it is quite that simple.
=

Your not just trusting that person will do the right th= ing. You are also trusting that they also have good operational security. I= t is precisely this sort of trust model which resulted n a number of GNU/Li= nux distributions being compromised in the past. The same thing has occurre= d with NPM and other 'public' repositories. It wasn't that peop= le who had access did the wrong thing, but rather people who had access who= failed to secure their systems adequately.

Y= ou only need to do a search of places like github to see how often people a= ccidentally commit sensitive data or look at the analysis of repositories t= hat have been compromised to see how often this occured because passwords w= ere poor, keys were not secured or sensitive data was accidentally posted t= o public forums.

The only real solution is on= e where each package maintainer is isolated from write access to code/packa= ges they are not authorised to maintain. The challenge is, such setups usua= lly also result in higher levels of maintenance overheads and that can ofte= n be a challenge for an organisation which needs to walk a tight line wrt f= unding.

To make matters worse, typically, it is al= most impossible to have good security retro fitted to a solution this is so= mething which needs to be designed into the architecture from the start. Th= is means that to fix this problem would require a considerable amount of wo= rk and change. The change part is extremely difficult as most people simply= don't like change (as is evident in many of the discussions about upda= ting how we handle patches, pull requests, defaults, etc).
<= br>
On Fri,= 24 Apr 2020 at 07:51, Andrea Corallo <a= krl@sdf.org> wrote:
Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That's right.=C2=A0 There is a practical problem, OTOH, which is t= hat
> write/push access to a GNU ELPA package currently means write access t= o
> all GNU ELPA packages as well as to Emacs's repository.
>
> For this reason, while some GNU ELPA package maintainers can "jus= t push"
> as they see fit, as it should be, others haven't yet been granted = this
> right.=C2=A0 This is a problem which we should solve, indeed, for the = benefit
> of those less-lucky package maintainers, as well as for the benefit of=
> those Emacs maintainers who have to play the middle men, and more
> generally for the benefit of the GNU ELPA archive and hence Emacs user= s
> since the current situation tends to discourage submissions.
>
> Note that giving write access widely, as we do now, has advantages as<= br> > well, in that it encourages package maintainers to participate in
> development of Emacs more generally.

To me the fact that a number of package maintainers is without write
access sounds quite odd.

If they are trusted to maintain a package they are supposed to have also the skills to push correctly a git commit.

Looking at other Free Software projects I'm involved I can testify that=
trust pays off and I think they should get write access.=C2=A0 My 2 cents.<= br>
=C2=A0 Andrea

--
akrl@sdf.org



--
regards,

Tim=

--
Tim Cross

--000000000000f7a9f705a3fdeaae--