Re: removing permissions for long unused accounts, take 2

[Jim Meyering]

On Thu, Mar 9, 2023 at 8:49 AM Paul Smith  wrote:
>
> On Thu, 2023-03-09 at 15:54 +0100, Bruno Haible wrote:
> > If you have a checkout of GNU gnulib, in order to successfully do a
> > "git pull" again, you will have to change the .git/config file,
>
> Is it better to suggest Git's CLI interface for this, than edit the
> file?
>
> For example
>
>   git remote set-url $(git remote) https://git.savannah.gnu.org/git/gnulib.git
>
> ?
>
> I personally prefer git.sv.gnu.org but I don't like to type :)

I've preferred the .sv.-abbreviated names for a long time, but
recently they've caused trouble with mismatched certificates, so I've
been switching to the fully-spelled-out host names.

Re: removing permissions for long unused accounts, take 2

[Paul Smith]

On Thu, 2023-03-09 at 15:54 +0100, Bruno Haible wrote:
> If you have a checkout of GNU gnulib, in order to successfully do a
> "git pull" again, you will have to change the .git/config file,

Is it better to suggest Git's CLI interface for this, than edit the
file?

For example

  git remote set-url $(git remote) https://git.savannah.gnu.org/git/gnulib.git

?

I personally prefer git.sv.gnu.org but I don't like to type :)

Re: removing permissions for long unused accounts, take 2

[Bruno Haible]

Continuing the thread from July 2022
.

Paul Eggert wrote:
> Since Gnulib is partially downstream from glibc I suggest also retaining 
> people who have committed to glibc in the last four years. We want to 
> encourage collaboration with Glibc, which is an essential low-level part 
> of the GNU toolchain (and if they can commit there they can do even more 
> damage anyway). On those grounds I suggest keeping Dmitry V. Levin 
> and Siddhesh Poyarekar, and not bothering to notify them.

OK. I did so.

So, the committers that I removed today are:

  Assaf Gordon
  Andreas Gruenbacher
  Bruce Korb
  Ludovic Courtès
  Derek Robert Price
  Eli Zaretskii
  Gary V. Vaughan
  Gerd Moellmann
  Dmitry Selyutin
  Sergey Poznyakoff
  James Youngman
  Joel E. Denny
  Kamil Dudka
  Stefan Monnier
  Richard M. Stallman
  Ralf Wildenhues
  Stefano Lattarini
  Daiki Ueno
  Jeff Bailey

The mail I sent (loosely based on what Simon suggested) is as follows:

===
Subject: your write access to GNU gnulib

Hi,

I'm writing to you as an admin of the GNU gnulib project on savannah.
You have write access to the GNU gnulib repository, but haven't made
use of it in more than one year. We miss your contributions!

To improve robustness against supply-chain attacks, and thus increase
our trustworthiness, we believe write permissions should be restricted
to those who use it regulary.  We are therefore withdrawing your write
permissions to the GNU gnulib repository.

If you have a checkout of GNU gnulib, in order to successfully do a
"git pull" again, you will have to change the .git/config file,
replacing
url = ssh://@git.savannah.gnu.org/srv/git/gnulib
or
url = @git.savannah.gnu.org:/srv/git/gnulib.git
with
url = git://git.savannah.gnu.org/gnulib.git
or
url = https://git.savannah.gnu.org/git/gnulib.git

Nonetheless, we would continue to appreciate contributions of yours!
Whenever you contribute again, it will be a easy and smooth process
for us to re-establish your write permissions.

Best regards,

 Bruno
 (for the GNU gnulib savannah admins)

Re: removing permissions for long unused accounts, take 2

[Eric Blake]

On Wed, Jul 13, 2022 at 11:54:03AM +0200, Simon Josefsson via Gnulib discussion 
list wrote:
> Bruno Haible  writes:
> 
> > Therefore I would now like to actually do it.
> 
> Thanks for working on this, it is important!
> 
> Maybe I am getting old, but one year seems like a fairly short period of
> time.  The list would be shortened with the following names if we used
> two years:
> 
> Daiki Ueno
> Dmitry V. Levin
> Eric Blake
> Siddhesh Poyarekar
> 
> So not radically different actually.  It would be bad if this excercise
> lead to less contributions.
> 
> How about using the one-year time frame, but give the person 6 months of
> time after an email notifying them about this situation to make another
> contribution and thus stay as committer?

Looks like it has been a while since I pushed something into gnulib,
but with this sort of 6-month notice, I'd definitely find reason for
something ;)

Meanwhile, I'm on board with the idea of pruning the list of write
access to frequent contributors (even if I temporarily fail to meet
that standard).  It doesn't seem onerous to re-establish permissions
if my situation changes to make it easier for me to contribute more
direct patches again.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: removing permissions for long unused accounts, take 2

[Paul Eggert]

Since Gnulib is partially downstream from glibc I suggest also retaining 
people who have committed to glibc in the last four years. We want to 
encourage collaboration with Glibc, which is an essential low-level part 
of the GNU toolchain (and if they can commit there they can do even more 
damage anyway). On those grounds I suggest keeping Dmitry V. Levin 
and Siddhesh Poyarekar, and not bothering to notify them.

Re: removing permissions for long unused accounts, take 2

[Simon Josefsson via Gnulib discussion list]

Bruno Haible  writes:

> Therefore I would now like to actually do it.

Thanks for working on this, it is important!

Maybe I am getting old, but one year seems like a fairly short period of
time.  The list would be shortened with the following names if we used
two years:

Daiki Ueno
Dmitry V. Levin
Eric Blake
Siddhesh Poyarekar

So not radically different actually.  It would be bad if this excercise
lead to less contributions.

How about using the one-year time frame, but give the person 6 months of
time after an email notifying them about this situation to make another
contribution and thus stay as committer?

> So, the list of people (to notify per mail and to remove from the
> membership list on savannah) are the following:

It would be nice to explain the reason for doing this, so nobody takes
offence.  If I lost write permission to a project without a clear
justification that clearly doing so was for the benefit of the project,
I could feel that it was personal and feel offended.  It could be brief,
just a paragraph or two.  It could be part of the GNU maintainers
manual, to recommend once every year prune the list of people who have
write access to a project if they didn't use it.  Maybe an email would
be a way to get people back into contributing?  Having clear policies
helps everyone and usually reduces friction.  How about this:

  Hi.  We have seen that you haven't used your write access to the
  gnulib project within one year, and we miss you!  To improve
  robustness against supply-chain attacks, and thus increase our
  trustworthyness, we believe write permissions should be restricted to
  those that use it regulary.  This is more of a request that you come
  back than a good bye!  If the write permission has not been used by
  you within 6 months, we will remove it -- but as a previous
  contributor, re-establishing write permissions should be a smooth
  process whenever you are ready to contribute again!

/Simon


signature.asc
Description: PGP signature

Re: removing permissions for long unused accounts, take 2

[Jim Meyering]

On Tue, Jul 12, 2022 at 10:18 PM Bruno Haible  wrote:
> Hi,
>
> I started this topic in 2021, in [1]: a proposal to remove write
> permissions from accounts who haven't pushed in a long while.
> There was agreement [2] that contributors who had not directly pushed
> a commit in a year could be revoked the write permission.
>
> The discussion ended with the question who of the gnulib savannah
> admins wanted to do it.
>
> What has changed since then:
>
>   * The log4j incident in December 2021 and a couple of similar
> incidents in the npm world have brought to everyone's attention
> that software supply chain is critical.
> As a reaction, the Linux Foundation has created a sub-foundation [3],
> GitHub will make 2FA mandatory by the end of 2023 [4], and similar
> moves are underway in the Ruby and Python communities [5].
>
> In GNU, Gnulib is probably, together with the Autotools, one of the
> most critical elements of the software supply chain. If a trojan/malware
> commit gets into Gnulib, we would have big trouble.
>
> Also:
>
>   * Since July 2021, I am co-maintainer of Gnulib, and one of the gnulib
> savannah admins.
>
> Therefore I would now like to actually do it.
...
> OK to proceed?

Thanks for taking this on. Fine with me.

Re: removing permissions for long unused accounts, take 2

[Dmitry Selyutin]

Hi Bruno,

On Wed, Jul 13, 2022 at 8:18 AM Bruno Haible  wrote:
>
>  Dmitry Selyutin
> OK to proceed?

I'm fine with revoking my write permissions. I still have plans to
check on Python gnulib, but, if I will do it, it's simple to restore
the permissions. Until then, let's follow the principle of least
privilege.

P.S. By the way, it's amazing to be in one list with such people, even
though we're talking of those who must have their permissions revoked.
:-)

-- 
Best regards,
Dmitry Selyutin

removing permissions for long unused accounts, take 2

[Bruno Haible]

Hi,

I started this topic in 2021, in [1]: a proposal to remove write
permissions from accounts who haven't pushed in a long while.
There was agreement [2] that contributors who had not directly pushed
a commit in a year could be revoked the write permission.

The discussion ended with the question who of the gnulib savannah
admins wanted to do it.

What has changed since then:

  * The log4j incident in December 2021 and a couple of similar
incidents in the npm world have brought to everyone's attention
that software supply chain is critical.
As a reaction, the Linux Foundation has created a sub-foundation [3],
GitHub will make 2FA mandatory by the end of 2023 [4], and similar
moves are underway in the Ruby and Python communities [5].

In GNU, Gnulib is probably, together with the Autotools, one of the
most critical elements of the software supply chain. If a trojan/malware
commit gets into Gnulib, we would have big trouble.

Also:

  * Since July 2021, I am co-maintainer of Gnulib, and one of the gnulib
savannah admins.

Therefore I would now like to actually do it.

Dmitry's recipe [6] gives the following result:

$ git log --pretty=fuller --since='1 year' | git shortlog -c -s
 1  Akim Demaille
 1  Ben Pfaff
 4  Bernhard Voelker
   262  Bruno Haible
 5  Jim Meyering
31  Karl Berry
 2  Marc Nieper-Wißkirchen
   214  Paul Eggert
 5  Pádraig Brady
 1  Reuben Thomas
17  Simon Josefsson

Also, I wouldn't want to remove Eric Blake, since he's an admin too.

So, the list of people (to notify per mail and to remove from the
membership list on savannah) are the following:

  Assaf Gordon
  Andreas Gruenbacher
  Bruce Korb
  Ludovic Courtès
  Derek Robert Price
  Eli Zaretskii
  Gary V. Vaughan
  Gerd Moellmann
  Dmitry Selyutin
  Sergey Poznyakoff
  James Youngman
  Joel E. Denny
  Kamil Dudka
  Dmitry V. Levin
  Stefan Monnier
  Richard M. Stallman
  Ralf Wildenhues
  Siddhesh Poyarekar
  Stefano Lattarini
  Daiki Ueno
  Jeff Bailey

OK to proceed?

  Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00070.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00085.html
[3] 
https://www.linuxfoundation.org/blog/linux-foundation-defending-the-global-software-supply-chain-from-cyberattacks-in-2021/
[4] 
https://www.theverge.com/2022/5/4/23056799/github-contributors-2fa-two-factor-authentication-2023
[5] 
https://portswigger.net/daily-swig/pypi-repo-to-distribute-4-000-security-keys-to-maintainers-of-critical-projects-in-2fa-drive
[6] https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00087.html