[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Gitlab update, 2FA now mandatory
From: David Jarvie <djarvie () kde ! org>
Date: 2022-10-25 12:38:08
Message-ID: FCFFB2AE-AAC1-423B-A53B-04B0CD6C24B5 () kde ! org
[Download RAW message or body]
On 25 October 2022 11:19:36 BST, Dan Leinir Turthra Jensen <admin@leinir.dk> wrote:
> On Tuesday, 25 October 2022 11:11:46 BST Carl Schwan wrote:
> > Le dimanche 23 octobre 2022 Ã 5:55 PM, Christoph Cullmann (cullmann.io)
> <christoph@cullmann.io> a écrit :
> > > On 2022-10-23 08:32, Ben Cooksley wrote:
> > > > Hi all,
> > > >
> > > > This afternoon I updated invent.kde.org [1] to the latest version of
> > > > Gitlab, 15.5.
> > > > Release notes for this can be found at
> > > > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/
> > > >
> > > > There isn't much notable feature wise in this release, however there
> > > > have been some bug fixes surrounding the "Rebase without Pipeline"
> > > > functionality that was introduced in an earlier update.
> > > >
> > > > As part of securing Invent against recently detected suspicious
> > > > activity I have also enabled Mandatory 2FA, which Gitlab will ask you
> > > > to configure next time you access it. This can be done using either a
> > > > Webauthn token (such as a Yubikey) or TOTP (using the app of choice on
> > > > your phone)
> > > >
> > > > Should you lose access to your 2FA device you can obtain a recovery
> > > > token to log back in via SSH, see
> > > > https://docs.gitlab.com/ee/user/profile/account/two_factor_authenticatio
> > > > n.html#generate-new-recovery-codes-using-ssh for more details on this.
> > > >
> > > > Please let us know if there are any queries on the above.
> > >
> > > Hi,
> > >
> > > whereas I can see the security benefit, this raises the hurdle for one
> > > time contributors again a lot.
> > >
> > > Before you already had to register to get your merge request,
> > > now you need to setup this too (or at least soon it is mandatory).
> > >
> > > I am not sure this is such a good thing.
> > >
> > > I see a point that one wants to avoid that e.g. somebody steals my
> > > account that has enough rights to delete all branches in the Kate
> > > repository via the web frontend.
> > >
> > > Could the 2FA stuff perhaps be limited to people with developer role or
> > > such?
> >
> > Yes this would be ideal. We don't need to require 2fa for people who just
> > started contributing or want to give some feedback on a MR/ticket.
> >
> > This should be possible with the following features:
> > https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2
> > fa-for-all-users-in-a-group
> >
> > We can just require 2fa for developers because with great powers come great
> > responsibilities.
> >
> > Cheers,
> > Carl
>
> i concur - after spending so long trying to attract casual contributors,
> putting up a huge barrier like this is just not helpful. So, 2FA for people
> who area able to actually mess stuff up, absolutely, we have responsibility
> here and that's fine, but for casual contributors, that is precisely the sort
> of thing that just outright makes people go "lol no" and go away again, and is
> that really something we can afford?
> I absolutely applaud the attempt at increasing out trustworthiness as a
> community, and 2FA for people who can actually push things certainly helps us
> get to that, but i also can't help but notice that the particular choice of
> making it a blanket community involvement requirement, that is, in this
> particular case, was made with a somewhat narrow focus, so... just thought i'd
> lend my voice to the "Yeah, please don't make our hard won casual contributors
> go away before they even get here".
>
I agree. Anybody without a real commitment to KDE would be likely to be put off by \
this requirement.
I also concur with Frederik, that there are people who have no previous exposure to \
this form of 2FA. The only form of 2FA which I have previously encountered is by text \
to my mobile phone. I had no idea that apps for this purpose existed. Because I \
develop KDE software, I have the motivation to find out how to set up 2FA for invent. \
But if I was a casual user, there is no way that I'd be prepared to spend the time \
and effort investigating how to do it. It's far too big a hurdle for somebody such as \
me who's not already committed to the project.
--
David Jarvie
KAlarm author, KDE developer
[Attachment #3 (text/html)]
<!DOCTYPE html><html><body>On 25 October 2022 11:19:36 BST, Dan Leinir Turthra Jensen \
<admin@leinir.dk> wrote:<br>> On Tuesday, 25 October 2022 11:11:46 BST Carl \
Schwan wrote:<br>> > Le dimanche 23 octobre 2022 Ã 5:55 PM, Christoph Cullmann \
(cullmann.io) <br>> <christoph@cullmann.io> a écrit :<br>> > > On \
2022-10-23 08:32, Ben Cooksley wrote:<br>> > > > Hi all,<br>> > \
> > <br>> > > > This afternoon I updated invent.kde.org [1] to the \
latest version of<br>> > > > Gitlab, 15.5.<br>> > > > Release \
notes for this can be found at<br>> > > > <a \
href="https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/">https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/</a><br>> \
> > > <br>> > > > There isn't much notable feature wise in this \
release, however there<br>> > > > have been some bug fixes surrounding \
the "Rebase without Pipeline"<br>> > > > functionality that was \
introduced in an earlier update.<br>> > > > <br>> > > > As \
part of securing Invent against recently detected suspicious<br>> > > > \
activity I have also enabled Mandatory 2FA, which Gitlab will ask you<br>> > \
> > to configure next time you access it. This can be done using either \
a<br>> > > > Webauthn token (such as a Yubikey) or TOTP (using the app of \
choice on<br>> > > > your phone)<br>> > > > <br>> > \
> > Should you lose access to your 2FA device you can obtain a recovery<br>> \
> > > token to log back in via SSH, see<br>> > > > <a \
href="https://docs.gitlab.com/ee/user/profile/account/two_factor_authenticatio">https://docs.gitlab.com/ee/user/profile/account/two_factor_authenticatio</a><br>> \
> > > n.html#generate-new-recovery-codes-using-ssh for more details on \
this.<br>> > > > <br>> > > > Please let us know if there are \
any queries on the above.<br>> > > <br>> > > Hi,<br>> > > \
<br>> > > whereas I can see the security benefit, this raises the hurdle for \
one<br>> > > time contributors again a lot.<br>> > > <br>> > \
> Before you already had to register to get your merge request,<br>> > > \
now you need to setup this too (or at least soon it is mandatory).<br>> > > \
<br>> > > I am not sure this is such a good thing.<br>> > > \
<br>> > > I see a point that one wants to avoid that e.g. somebody steals \
my<br>> > > account that has enough rights to delete all branches in the \
Kate<br>> > > repository via the web frontend.<br>> > > <br>> \
> > Could the 2FA stuff perhaps be limited to people with developer role \
or<br>> > > such?<br>> > <br>> > Yes this would be ideal. We \
don't need to require 2fa for people who just<br>> > started contributing or \
want to give some feedback on a MR/ticket.<br>> > <br>> > This should be \
possible with the following features:<br>> > <a \
href="https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2">ht \
tps://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2</a><br>> \
> fa-for-all-users-in-a-group<br>> > <br>> > We can just require 2fa \
for developers because with great powers come great<br>> > \
responsibilities.<br>> > <br>> > Cheers,<br>> > Carl<br>> \
<br>> i concur - after spending so long trying to attract casual contributors, \
<br>> putting up a huge barrier like this is just not helpful. So, 2FA for people \
<br>> who area able to actually mess stuff up, absolutely, we have responsibility \
<br>> here and that's fine, but for casual contributors, that is precisely the \
sort <br>> of thing that just outright makes people go "lol no" and go away again, \
and is <br>> that really something we can afford?<br>> I absolutely applaud \
the attempt at increasing out trustworthiness as a <br>> community, and 2FA for \
people who can actually push things certainly helps us <br>> get to that, but i \
also can't help but notice that the particular choice of <br>> making it a blanket \
community involvement requirement, that is, in this <br>> particular case, was \
made with a somewhat narrow focus, so... just thought i'd <br>> lend my voice to \
the "Yeah, please don't make our hard won casual contributors <br>> go away before \
they even get here".<br>> <br><br>I agree. Anybody without a real commitment to \
KDE would be likely to be put off by this requirement.<br><br>I also concur with \
Frederik, that there are people who have no previous exposure to this form of 2FA. \
The only form of 2FA which I have previously encountered is by text to my mobile \
phone. I had no idea that apps for this purpose existed. Because I develop KDE \
software, I have the motivation to find out how to set up 2FA for invent. But if I \
was a casual user, there is no way that I'd be prepared to spend the time and effort \
investigating how to do it. It's far too big a hurdle for somebody such as me who's \
not already committed to the project.<div style='white-space: pre-wrap'>--<br>David \
Jarvie<br>KAlarm author, KDE developer<br></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic