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: Copyright verification service Date: Tue, 26 May 2020 10:02:26 +1000 Message-ID: References: <87tv04fnt9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002f6b4805a681d02d" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="42779"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Bastien Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 26 02:03:30 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 1jdN46-000B3G-1y for ged-emacs-devel@m.gmane-mx.org; Tue, 26 May 2020 02:03:30 +0200 Original-Received: from localhost ([::1]:50362 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdN45-0000bi-0o for ged-emacs-devel@m.gmane-mx.org; Mon, 25 May 2020 20:03:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdN3I-0008RS-9Q for emacs-devel@gnu.org; Mon, 25 May 2020 20:02:40 -0400 Original-Received: from mail-oi1-x22d.google.com ([2607:f8b0:4864:20::22d]:33804) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdN3H-0002nA-4S; Mon, 25 May 2020 20:02:39 -0400 Original-Received: by mail-oi1-x22d.google.com with SMTP id w4so17274799oia.1; Mon, 25 May 2020 17:02:38 -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=bc9+gQAF0yaL+0/4JOrB8chKzoh4Mf+Pc2DKRGnt1xM=; b=WLHAeAUtcnto8iViUCUOJBOcvQF9pSEH12Py3TN3wusvBzUKo7WYLZI45HhgOGJ6Yy G+wpkXVKL3lL7EcaHjkVj6+PsXOZ+35RIJ2v1b8IzUlwwMMgtEZ9RdNhwoCbDIsWdUg2 hqkrSBTp7WCiKt53xijxbejf4nvWDZHDsq7s4Po8C0dmmZ1o8zHe5aC0muY0a8TX2XRz bAwO/N8Tb1wUwfOmIF/10wqRw9MvYF0cXM/fc9vWY7iwz4BFyU32XuOS1m/C6Vpb4joU hejj1UoWizpqHw6BWSBtE601YG9Os1we+7uukaDahuVjd8bqeO4+Rhcd/Oz9rmD8brZs 9BLA== 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=bc9+gQAF0yaL+0/4JOrB8chKzoh4Mf+Pc2DKRGnt1xM=; b=q1wvaImjvc8B3w0lWb9dN28MGai/g9lBqkoj8eWxKGMk3s0PyKVw4FI6Fu915QYE1T SMmLaIZuTLJEuPLclLnDr9dFUp0MaC6cBWW7dBTSQ5Z9x+ExkAgDzO/uQJ7u2Xu5eyyk BAol4voK7pU2qBlrKRFlHiXRlXcKQiZkA/xvcSgbUt0ZfTFt+0A4AWcJ2Z91M/zLnJwF hiBbdckQelF3KQjz4NxOu5lm8PThhez58JT4ndKunI5ljmhCxdVr4iDcDSTTNQzLSbad Sa1/U3VMbIu30dXgGlE3TvKNs0HopEDsWyG+2rsQf7nEjyyDEIHFxZnuXSjZEqdzEUE2 HgWg== X-Gm-Message-State: AOAM532mmdgAyuGPmJPKplhavPi5wR1YzFnuavr086QCsycMj4IXjEaD l2bURWOb7YKUVGCIyDpdk41QXim/3JGPxsYGG+X4fw== X-Google-Smtp-Source: ABdhPJxdkU2ZoKTjpM2rVr2FRf1cUSE0lkmIIotwHy0v1glXxOiEl1D1xiz/Ayx2x58bSCz/jMTFUD+KCgfMTEqBpjQ= X-Received: by 2002:a54:4f0a:: with SMTP id e10mr12286824oiy.146.1590451357312; Mon, 25 May 2020 17:02:37 -0700 (PDT) In-Reply-To: <87tv04fnt9.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::22d; envelope-from=theophilusx@gmail.com; helo=mail-oi1-x22d.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:251402 Archived-At: --0000000000002f6b4805a681d02d Content-Type: text/plain; charset="UTF-8" On Mon, 25 May 2020 at 17:58, Bastien wrote: > Hi Tim, > > I've toyed with this idea myself for a while. > > I don't know if it is a good idea for the GNU project in general, but > as someone who sometimes need to check the copyright status of some > contributors for Org/Emacs, the current setup is fine for me. > I'm thinking more along the lines that we are successful in establishing an ELPA repository which has a much higher number of packages than the current situation. If we can establish processes that are reasonably efficient and 'low pain', more developers are likely to be prepared to have their package in ELPA rather than MELPA. If this occurs, the current model of providing push rights to the GNU Emacs repository for package developers will not scale and there will be a higher level of maintenance burden placed on a smaller team of maintainers who do have those rights. > > Although, I don't think authentication would be optional as we should > by default assume that the list of signed contributors should be kept > private, shouldn't we? > My idea is that the list does stay private. You cannot see/retrieve the list. All you can do is submit an email address and it will come back with either yes or no (ture/false etc).. You wold need to know the email address before you can check copyright status. You cold add rate limiting to prevent the service being hit with millions of addresses (i.e. someone harvests all the email addresses from the mail list and then tries to determine who has copyright assignment etc). > > If the authentication system is mandatory then it raises the larger > question of maintaining a system that needs security monitoring, and > I'm pretty sure the current resources are too scarce for this... but > maybe not. > > I agree. It is a great pity there isn't a GNU identity provider. I actually think that would be a really good service in support of free software. If the FSF was able to establish a stable and reliable identity provider, all those sites which now offer login via google, facebook etc, could also offer a free open alternative. The big problem is, I don't believe the FSF has the resources or skills to do service provisioning. The requirements to provide a reliable service offering are different enough from development of software applications that a whole different group would likely be required. I do wonder if there might be an established organisation who can embrace FSF philosophy and who has the needed skill sets that would be able to provide such a service on behalf of the FSF. There are free and open implementations of identity provider software out there, but nobody is offering it as a service, effectively limiting users who do not want to use closed and potentially evil providers from benefiting from the advantages such services can offer. Either we have to use google, facebook, github etc service or we need to provide our personal info to multiple services for direct access. A free and open identity provider with strong privacy policy that embodies the FSF philosophy is a critical piece of the puzzle which is currently missing. The growth in service delivered technologies only makes this gap worse. > > -- regards, Tim -- Tim Cross --0000000000002f6b4805a681d02d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 25 May 2020 at 17:58, Bastien= <bzg@gnu.org> wrote:
Hi Tim,

I've toyed with this idea myself for a while.

I don't know if it is a good idea for the GNU project in general, but as someone who sometimes need to check the copyright status of some
contributors for Org/Emacs, the current setup is fine for me.

I'm thinking more along the lines that we are su= ccessful in establishing an ELPA repository which has a much higher number = of packages than the current situation. If we can establish processes that = are reasonably efficient and 'low pain', more developers are likely= to be prepared to have their package in ELPA rather than MELPA. If this oc= curs, the current model of providing push rights to the GNU Emacs repositor= y for package developers will not scale and there will be a higher level of= maintenance burden placed on a smaller team of maintainers who do have tho= se rights.=C2=A0=C2=A0

Although, I don't think authentication would be optional as we should by default assume that the list of signed contributors should be kept
private, shouldn't we?

My idea is t= hat the list does stay private. You cannot see/retrieve the list. All you c= an do is submit an email address and it will come back with either yes or n= o (ture/false etc).. You wold need to know the email address before you can= check copyright status. You cold add rate limiting to prevent the service = being hit with millions of addresses (i.e. someone harvests all the email a= ddresses from the mail list and then tries to determine who has copyright a= ssignment etc).=C2=A0 =C2=A0

If the authentication system is mandatory then it raises the larger
question of maintaining a system that needs security monitoring, and
I'm pretty sure the current resources are too scarce for this... but maybe not.


I agree. It is a great pity there isn&= #39;t a GNU identity provider. I actually think that would be a really good= service in support of free software. If the FSF was able to establish a st= able and reliable identity provider, all those sites which now offer login = via google, facebook etc, could also offer a free open alternative.=C2=A0

The big problem is, I don't believe the FSF has= the resources or skills to do service provisioning. The requirements to pr= ovide a reliable=C2=A0 service offering are different enough from developme= nt of software applications that a whole different group would likely be re= quired. I do wonder if there might be an established organisation who can e= mbrace FSF philosophy and who has the needed skill sets that would be able = to provide such a service on behalf of the FSF.=C2=A0 There are free and op= en implementations of identity provider software out there, but nobody is o= ffering it as a service, effectively limiting users who do not want to use = closed and potentially evil providers from benefiting from the advantages s= uch services can offer. Either we have to use google, facebook, github etc = service or we need to provide our personal info to multiple services for di= rect access. A free and open identity provider with strong privacy policy t= hat embodies the FSF philosophy is a critical piece of the puzzle which is = currently missing. The growth in service delivered technologies only makes = this gap worse.=C2=A0

=C2=A0

--
regards,
Tim

--
Tim Cross

--0000000000002f6b4805a681d02d--