Re: Gitlab update, 2FA now mandatory

2022-10-31 Thread Dan Leinir Turthra Jensen
On Friday, 28 October 2022 21:57:16 GMT Ben Cooksley wrote:
> Hi all,
> 
> Following some additional analysis of the situation I've now adjusted the
> policy surrounding enforced use of 2FA.
> 
> Going forward it will only be enforced on people who are one of the
> following:
> - KDE Developers
> - KDE e.V. Members (including the Board)
> - KDE e.V. Staff (whether they be contractors or employees)
> 
> In addition, 2FA may be enforced on any person who has access to a system
> that contains sensitive information, including but not limited to
> stats.kde.org, metrics.kde.org and collaborate.kde.org, or who has
> additional privileges on those systems outside of those granted to users by
> default. It may also be enforced if a person becomes involved in a project
> in a meaningful way (ie. a long term contributor) that does not result in
> them obtaining a developer account or access to sensitive information.
> 
> Cheers,
> Ben

  As one of those who shouted about this, just wanted to also say thanks for 
taking our concerns into account and sorting it like this - so, thanks! :D

-- 
..dan / leinir..
http://leinir.dk/




Re: Gitlab update, 2FA now mandatory

2022-10-29 Thread Christoph Cullmann (cullmann.io)

On 2022-10-28 22:57, Ben Cooksley wrote:

Hi all,

Following some additional analysis of the situation I've now adjusted
the policy surrounding enforced use of 2FA.

Going forward it will only be enforced on people who are one of the
following:
- KDE Developers
- KDE e.V. Members (including the Board)
- KDE e.V. Staff (whether they be contractors or employees)

In addition, 2FA may be enforced on any person who has access to a
system that contains sensitive information, including but not limited
to stats.kde.org [1], metrics.kde.org [2] and collaborate.kde.org [3],
or who has additional privileges on those systems outside of those
granted to users by default. It may also be enforced if a person
becomes involved in a project in a meaningful way (ie. a long term
contributor) that does not result in them obtaining a developer
account or access to sensitive information.


Hi,

thanks a lot, this seems to be a very sensible solution for me.

That will still allow people to easily comment in things and make first 
time contributions without any extra hassle.


Greetings
Christoph



Cheers,
Ben

Links:
--
[1] http://stats.kde.org
[2] http://metrics.kde.org
[3] http://collaborate.kde.org


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-28 Thread Ben Cooksley
Hi all,

Following some additional analysis of the situation I've now adjusted the
policy surrounding enforced use of 2FA.

Going forward it will only be enforced on people who are one of the
following:
- KDE Developers
- KDE e.V. Members (including the Board)
- KDE e.V. Staff (whether they be contractors or employees)

In addition, 2FA may be enforced on any person who has access to a system
that contains sensitive information, including but not limited to
stats.kde.org, metrics.kde.org and collaborate.kde.org, or who has
additional privileges on those systems outside of those granted to users by
default. It may also be enforced if a person becomes involved in a project
in a meaningful way (ie. a long term contributor) that does not result in
them obtaining a developer account or access to sensitive information.

Cheers,
Ben


Re: Gitlab update, 2FA now mandatory

2022-10-27 Thread Christoph Cullmann (cullmann.io)

On 2022-10-25 20:53, Albert Astals Cid wrote:

> > 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?


From personal experience I agree, i was going to report a VLC issue, 
their
gitlab also uses mandatory 2FA and I was very close to just giving up, 
and

that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account 
holders.


Cheers,
  Albert

  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".


Hi,

could we have this? Only mandatory 2FA for accounts with more rights?

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-26 Thread Jack

On 2022.10.26 16:33, Tobias Leupold wrote:

Am Montag, 24. Oktober 2022, 01:16:30 CEST schrieb Jack:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> >
> > This afternoon I updated invent.kde.org 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_authentication.
> > html#generate-new-recovery-codes-using-ssh for more details on  
this.

> >
> > Please let us know if there are any queries on the above.
> >
> > Thanks,
> > Ben
>
> Sorry to be dense, but without a webauthn token device, it seems  
I'm at
> a total block if I don't have a phone (or don't have it with me.)   
Is

> that correct, or is there some fine manual I need to read?

Just to take this up again, possibly for the more conservative folks  
here:


I never had anything to do with Two-Factor-Authentication until now.  
But

actually, it's not so complicated as it seems to be at first glance.

After having messed with it a bit, I found out that one doesn't have  
to use a
phone to scan QR codes and such. The one-time-password used for  
GitLab 2FA is
only derived from the "secret" (or "key", as GitLab calls it) and the  
moment

in time where it should be used.

So you can e.g. store that key (it's displayed on GitLab below the QR  
code, we
don't need the other stuff) in pass's db, e.g. in  
var/invent.kde.org_2FA or

such.

With the help of a small shell script invoking pass and oathtool  
(from oath-
toolkit), you can then retrieve the one-time-password by only using  
the shell:


#!/bin/bash
secret=$(pass $1)   # Get the key from pass's  
db

secret=${secret// /}# Strip all spaces from it
valid=$((30 - 10#$(date +%S) % 30)) # Calculate the validity
otp=$(oathtool --base32 --totp $secret) # Generate the OTP
echo "$otp (valid ${valid}s)"   # Print the result

Call it e.g. with the above var/invent.kde.org_2FA as the parameter,  
and you

get (after having unlocked your PGP key of course) something like

111658 (valid 28s)

If the time the password will be valid is too short, you can simply  
call it

again after some seconds (the PGP key stays unlocked for some time).

Of course, this has no error checking or such. But this could be  
added quite
trivially. This way, we neither need some phone, nor some specialized  
device

or app to deal with that OTP stuff, but only well-known console tools.

Maybe this helps somebody ;-)

Thanks.  I might just try that.

I also found a KDE app called keysmith, but Gentoo doesn't package it,  
so I don't quite know what to think of it.  I've installed it, but not  
yet tried to use it.


Jack


Cheers, Tobias


Re: Gitlab update, 2FA now mandatory

2022-10-26 Thread Tobias Leupold
Am Montag, 24. Oktober 2022, 01:16:30 CEST schrieb Jack:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> > 
> > This afternoon I updated invent.kde.org 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_authentication.
> > html#generate-new-recovery-codes-using-ssh for more details on this.
> > 
> > Please let us know if there are any queries on the above.
> > 
> > Thanks,
> > Ben
> 
> Sorry to be dense, but without a webauthn token device, it seems I'm at
> a total block if I don't have a phone (or don't have it with me.)  Is
> that correct, or is there some fine manual I need to read?

Just to take this up again, possibly for the more conservative folks here:

I never had anything to do with Two-Factor-Authentication until now. But 
actually, it's not so complicated as it seems to be at first glance.

After having messed with it a bit, I found out that one doesn't have to use a 
phone to scan QR codes and such. The one-time-password used for GitLab 2FA is 
only derived from the "secret" (or "key", as GitLab calls it) and the moment 
in time where it should be used.

So you can e.g. store that key (it's displayed on GitLab below the QR code, we 
don't need the other stuff) in pass's db, e.g. in var/invent.kde.org_2FA or 
such.

With the help of a small shell script invoking pass and oathtool (from oath-
toolkit), you can then retrieve the one-time-password by only using the shell:

#!/bin/bash
secret=$(pass $1)   # Get the key from pass's db
secret=${secret// /}# Strip all spaces from it
valid=$((30 - 10#$(date +%S) % 30)) # Calculate the validity
otp=$(oathtool --base32 --totp $secret) # Generate the OTP
echo "$otp (valid ${valid}s)"   # Print the result

Call it e.g. with the above var/invent.kde.org_2FA as the parameter, and you 
get (after having unlocked your PGP key of course) something like

111658 (valid 28s)

If the time the password will be valid is too short, you can simply call it 
again after some seconds (the PGP key stays unlocked for some time).

Of course, this has no error checking or such. But this could be added quite 
trivially. This way, we neither need some phone, nor some specialized device 
or app to deal with that OTP stuff, but only well-known console tools.

Maybe this helps somebody ;-)

Cheers, Tobias

> Thanks.
> 
> Jack





Re: Gitlab update, 2FA now mandatory

2022-10-26 Thread Ahmad Samir

On 25/10/22 15:06, Christoph Cullmann (cullmann.io) wrote:

On 2022-10-25 14:55, Ahmad Samir wrote:

On 25/10/22 14:31, Christoph Cullmann (cullmann.io) wrote:

On 2022-10-25 13:52, Ahmad Samir wrote:

On 25/10/22 13:29, Harald Sitter wrote:

On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir 
wrote:


Can a first time contributor create a fork, create multiple/100
MR's
and spin up CI jobs? if yes,
then, first time contributors can disrupt the system.

Weren't there some suspicious accounts that were using our gitlab
instance for bitcoin mining (I
could be wrong, I vaguely remember someone from Sysadmin team
talking
about something like that)?
were these first time contributors or ones with developer accounts?


I'm sure 2fa doesn't help with that (:


I am not a cyber security expert, but isn't 2FA comparable to captcha
stuff? it's not hard, but it takes some extra time. Which forum would
a
spammer target? the one with the "create account and login
immediately"
or the one with "create account, verify captcha hell, verify email
address"?


That is true, but did we have concrete issues with spam accounts?

And if yes, a one time captcha solving is a lot lower barrier the to
need to do 2fa auth for a trivial issue
Comment or merge request.

At least for any part I work on in KDE the issue is manpower.

Any step to make it more easier to help is good.
Any step to make it harder is bad.

I see the point why we not work on GitHub,
I don't like to be dependent on some random company
that in worst case can randomly pull the plug.

But I somehow don't understand why we need to enforce
this now even for new accounts without rights.

I must confess I would like it even more if 2fa
would only be required on doing some action that
Is problematic and not just on any issue or merge
request comment. But I assume that is not feasible.

Greetings
Christoph



FWIW, when I log in to GitHub, they email me a pin number that I have
to put in the web page, for me it's exactly the same level of
inconvenience:
- "check email, find pin, copy, paste"
- "check app on phone, type pin"


A mail is a lot easier on many devices,
at least for me.

My Kindle Fire can read my mails, but per default has zero otp stuff I
could use.

Same for my different work computers.
All can get mail, none had before any such application.

Therefore, yes, GitHub or the Steam Store work for me
Without any extra setup effort. A mail address was
Required anyways.

And no, not even per default KDE Plasma ships with
any obviously well integrated otp client.



In this thread Ivan said Plasma Pass has OTP support:
https://mail.kde.org/pipermail/kde-community/2022q4/007309.html

(I haven't tried it myself).

Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature


Re: Gitlab update, 2FA now mandatory

2022-10-26 Thread Ben Cooksley
On Wed, Oct 26, 2022 at 1:32 AM Christoph Cullmann (cullmann.io) <
christ...@cullmann.io> wrote:

> On 2022-10-25 13:52, Ahmad Samir wrote:
> > On 25/10/22 13:29, Harald Sitter wrote:
> >> On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir 
> >> wrote:
> >>>
> >>> Can a first time contributor create a fork, create multiple/100 MR's
> >>> and spin up CI jobs? if yes,
> >>> then, first time contributors can disrupt the system.
> >>>
> >>> Weren't there some suspicious accounts that were using our gitlab
> >>> instance for bitcoin mining (I
> >>> could be wrong, I vaguely remember someone from Sysadmin team talking
> >>> about something like that)?
> >>> were these first time contributors or ones with developer accounts?
> >>
> >> I'm sure 2fa doesn't help with that (:
> >
> > I am not a cyber security expert, but isn't 2FA comparable to captcha
> > stuff? it's not hard, but it takes some extra time. Which forum would a
> > spammer target? the one with the "create account and login immediately"
> > or the one with "create account, verify captcha hell, verify email
> > address"?
>
> That is true, but did we have concrete issues with spam accounts?
>

2FA and CAPTCHA's try to solve two totally different problems.
Please do not try to conflate them with each other.

CAPTCHA's are designed to prevent bots (and more recently other suspicious
actors) from taking specific actions, such as registering accounts.
Often CAPTCHA's are intended to block spammers.

2FA is designed to verify that a user is who they say they are - through
confirming they are in possession of something (whether that be a TOTP
Secret, or a Webauthn hardware token).
It is intended to defeat phishing, where legitimate and innocent user
accounts are compromised and abused by bad actors.


>
> And if yes, a one time captcha solving is a lot lower barrier the to
> need to do 2fa auth for a trivial issue
> Comment or merge request.
>
> At least for any part I work on in KDE the issue is manpower.
>
> Any step to make it more easier to help is good.
> Any step to make it harder is bad.
>
> I see the point why we not work on GitHub,
> I don't like to be dependent on some random company
> that in worst case can randomly pull the plug.
>
> But I somehow don't understand why we need to enforce
> this now even for new accounts without rights.
>
> I must confess I would like it even more if 2fa
> would only be required on doing some action that
> Is problematic and not just on any issue or merge
> request comment. But I assume that is not feasible.
>

You are correct.

2FA forms part of the process of authentication - that is confirming the
user is who they say they are.
It therefore can only be applied at the time of login.


>
> Greetings
> Christoph
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org


Regards,
Ben


Re: Gitlab update, 2FA now mandatory

2022-10-26 Thread Ben Cooksley
On Wed, Oct 26, 2022 at 12:22 AM Ahmad Samir  wrote:

> On 25/10/22 12:11, Carl Schwan wrote:
> > Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (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_authentication.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-2fa-for-all-users-in-a-group
> >
> > We can just require 2fa for developers because with great powers come
> great
> > responsibilities.
> >
> > Cheers,
> > Carl
> >
>
> Can a first time contributor create a fork, create multiple/100 MR's and
> spin up CI jobs? if yes,
> then, first time contributors can disrupt the system.
>

They certainly can, although it hasn't been an abuse pattern we have had to
deal with so far.


>
> Weren't there some suspicious accounts that were using our gitlab instance
> for bitcoin mining (I
> could be wrong, I vaguely remember someone from Sysadmin team talking
> about something like that)?
> were these first time contributors or ones with developer accounts?
>

Bitcoin mining no. Trying to use a Docker container on our CI nodes as
their own personal server by utilising a reverse shell, then abusing that
access to compile their own Android image, yes.
All aided by GitHub distributing the Docker image on their container
registry and ignoring our abuse reports.



>
>
> --
> Ahmad Samir
>

Regards,
Ben


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Christoph Cullmann (cullmann.io)

On 2022-10-25 21:29, Christoph Cullmann (cullmann.io) wrote:

On 2022-10-25 20:53, Albert Astals Cid wrote:
  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?


From personal experience I agree, i was going to report a VLC issue, 
their
gitlab also uses mandatory 2FA and I was very close to just giving up, 
and

that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account 
holders.




hi,

one other side note, e.g. my GitHub account login stays after valid 2FA 
auth

valid in my Chromium browser even over reboots on my normal machine.

Is that something one can configure or is GitLab just not able to 
support this?


Makes the use on the home pc a lot less annoying.


Just forget that question, my 'remember me' checkbox was just not on ;)



Greetings
Christoph


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Christoph Cullmann (cullmann.io)

On 2022-10-25 20:53, Albert Astals Cid wrote:
  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?


From personal experience I agree, i was going to report a VLC issue, 
their
gitlab also uses mandatory 2FA and I was very close to just giving up, 
and

that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account 
holders.




hi,

one other side note, e.g. my GitHub account login stays after valid 2FA 
auth

valid in my Chromium browser even over reboots on my normal machine.

Is that something one can configure or is GitLab just not able to 
support this?


Makes the use on the home pc a lot less annoying.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Albert Astals Cid
El dimarts, 25 d’octubre de 2022, a les 12:19:36 (CEST), Dan Leinir Turthra 
Jensen va escriure:
> On Tuesday, 25 October 2022 11:11:46 BST Carl Schwan wrote:
> > Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (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_authenticat
> > > > io
> > > > 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?

From personal experience I agree, i was going to report a VLC issue, their 
gitlab also uses mandatory 2FA and I was very close to just giving up, and 
that was something that kind of bothered me to a certain degree.

I agree with making 2FA non mandatory for non KDE "powerful" account holders.

Cheers,
  Albert

>   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".






Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Christoph Cullmann (cullmann.io)

On 2022-10-25 14:55, Ahmad Samir wrote:

On 25/10/22 14:31, Christoph Cullmann (cullmann.io) wrote:

On 2022-10-25 13:52, Ahmad Samir wrote:

On 25/10/22 13:29, Harald Sitter wrote:

On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir 
wrote:


Can a first time contributor create a fork, create multiple/100 
MR's

and spin up CI jobs? if yes,
then, first time contributors can disrupt the system.

Weren't there some suspicious accounts that were using our gitlab
instance for bitcoin mining (I
could be wrong, I vaguely remember someone from Sysadmin team 
talking

about something like that)?
were these first time contributors or ones with developer accounts?


I'm sure 2fa doesn't help with that (:


I am not a cyber security expert, but isn't 2FA comparable to captcha
stuff? it's not hard, but it takes some extra time. Which forum would 
a
spammer target? the one with the "create account and login 
immediately"

or the one with "create account, verify captcha hell, verify email
address"?


That is true, but did we have concrete issues with spam accounts?

And if yes, a one time captcha solving is a lot lower barrier the to
need to do 2fa auth for a trivial issue
Comment or merge request.

At least for any part I work on in KDE the issue is manpower.

Any step to make it more easier to help is good.
Any step to make it harder is bad.

I see the point why we not work on GitHub,
I don't like to be dependent on some random company
that in worst case can randomly pull the plug.

But I somehow don't understand why we need to enforce
this now even for new accounts without rights.

I must confess I would like it even more if 2fa
would only be required on doing some action that
Is problematic and not just on any issue or merge
request comment. But I assume that is not feasible.

Greetings
Christoph



FWIW, when I log in to GitHub, they email me a pin number that I have 
to put in the web page, for me it's exactly the same level of 
inconvenience:

- "check email, find pin, copy, paste"
- "check app on phone, type pin"


A mail is a lot easier on many devices,
at least for me.

My Kindle Fire can read my mails, but per default has zero otp stuff I 
could use.


Same for my different work computers.
All can get mail, none had before any such application.

Therefore, yes, GitHub or the Steam Store work for me
Without any extra setup effort. A mail address was
Required anyways.

And no, not even per default KDE Plasma ships with
any obviously well integrated otp client.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Ahmad Samir

On 25/10/22 14:31, Christoph Cullmann (cullmann.io) wrote:

On 2022-10-25 13:52, Ahmad Samir wrote:

On 25/10/22 13:29, Harald Sitter wrote:

On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir 
wrote:


Can a first time contributor create a fork, create multiple/100 MR's
and spin up CI jobs? if yes,
then, first time contributors can disrupt the system.

Weren't there some suspicious accounts that were using our gitlab
instance for bitcoin mining (I
could be wrong, I vaguely remember someone from Sysadmin team talking
about something like that)?
were these first time contributors or ones with developer accounts?


I'm sure 2fa doesn't help with that (:


I am not a cyber security expert, but isn't 2FA comparable to captcha
stuff? it's not hard, but it takes some extra time. Which forum would a
spammer target? the one with the "create account and login immediately"
or the one with "create account, verify captcha hell, verify email
address"?


That is true, but did we have concrete issues with spam accounts?

And if yes, a one time captcha solving is a lot lower barrier the to
need to do 2fa auth for a trivial issue
Comment or merge request.

At least for any part I work on in KDE the issue is manpower.

Any step to make it more easier to help is good.
Any step to make it harder is bad.

I see the point why we not work on GitHub,
I don't like to be dependent on some random company
that in worst case can randomly pull the plug.

But I somehow don't understand why we need to enforce
this now even for new accounts without rights.

I must confess I would like it even more if 2fa
would only be required on doing some action that
Is problematic and not just on any issue or merge
request comment. But I assume that is not feasible.

Greetings
Christoph



FWIW, when I log in to GitHub, they email me a pin number that I have to put in the web page, for me 
it's exactly the same level of inconvenience:

- "check email, find pin, copy, paste"
- "check app on phone, type pin"

Regards,
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Harald Sitter
On Tue, Oct 25, 2022 at 1:52 PM Ahmad Samir  wrote:
>
> On 25/10/22 13:29, Harald Sitter wrote:
> > On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir  wrote:
> >>
> >> Can a first time contributor create a fork, create multiple/100 MR's and 
> >> spin up CI jobs? if yes,
> >> then, first time contributors can disrupt the system.
> >>
> >> Weren't there some suspicious accounts that were using our gitlab instance 
> >> for bitcoin mining (I
> >> could be wrong, I vaguely remember someone from Sysadmin team talking 
> >> about something like that)?
> >> were these first time contributors or ones with developer accounts?
> >
> > I'm sure 2fa doesn't help with that (:
>
> I am not a cyber security expert, but isn't 2FA comparable to captcha stuff? 
> it's not hard, but it
> takes some extra time.

No. It's neither hard nor does it take time. 2fa is 100% scriptable.

HS


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread David Jarvie
On 25 October 2022 11:19:36 BST, Dan Leinir Turthra Jensen  
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) 
>  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


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Christoph Cullmann (cullmann.io)

On 2022-10-25 13:52, Ahmad Samir wrote:

On 25/10/22 13:29, Harald Sitter wrote:
On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir  
wrote:


Can a first time contributor create a fork, create multiple/100 MR's 
and spin up CI jobs? if yes,

then, first time contributors can disrupt the system.

Weren't there some suspicious accounts that were using our gitlab 
instance for bitcoin mining (I
could be wrong, I vaguely remember someone from Sysadmin team talking 
about something like that)?

were these first time contributors or ones with developer accounts?


I'm sure 2fa doesn't help with that (:


I am not a cyber security expert, but isn't 2FA comparable to captcha 
stuff? it's not hard, but it takes some extra time. Which forum would a 
spammer target? the one with the "create account and login immediately" 
or the one with "create account, verify captcha hell, verify email 
address"?


That is true, but did we have concrete issues with spam accounts?

And if yes, a one time captcha solving is a lot lower barrier the to 
need to do 2fa auth for a trivial issue

Comment or merge request.

At least for any part I work on in KDE the issue is manpower.

Any step to make it more easier to help is good.
Any step to make it harder is bad.

I see the point why we not work on GitHub,
I don't like to be dependent on some random company
that in worst case can randomly pull the plug.

But I somehow don't understand why we need to enforce
this now even for new accounts without rights.

I must confess I would like it even more if 2fa
would only be required on doing some action that
Is problematic and not just on any issue or merge
request comment. But I assume that is not feasible.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Ahmad Samir

On 25/10/22 13:29, Harald Sitter wrote:

On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir  wrote:


Can a first time contributor create a fork, create multiple/100 MR's and spin 
up CI jobs? if yes,
then, first time contributors can disrupt the system.

Weren't there some suspicious accounts that were using our gitlab instance for 
bitcoin mining (I
could be wrong, I vaguely remember someone from Sysadmin team talking about 
something like that)?
were these first time contributors or ones with developer accounts?


I'm sure 2fa doesn't help with that (:


I am not a cyber security expert, but isn't 2FA comparable to captcha stuff? it's not hard, but it 
takes some extra time. Which forum would a spammer target? the one with the "create account and 
login immediately" or the one with "create account, verify captcha hell, verify email address"?


--
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Harald Sitter
On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir  wrote:
>
> On 25/10/22 12:11, Carl Schwan wrote:
> > Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (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_authentication.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-2fa-for-all-users-in-a-group
> >
> > We can just require 2fa for developers because with great powers come great
> > responsibilities.
> >
> > Cheers,
> > Carl
> >
>
> Can a first time contributor create a fork, create multiple/100 MR's and spin 
> up CI jobs? if yes,
> then, first time contributors can disrupt the system.
>
> Weren't there some suspicious accounts that were using our gitlab instance 
> for bitcoin mining (I
> could be wrong, I vaguely remember someone from Sysadmin team talking about 
> something like that)?
> were these first time contributors or ones with developer accounts?

I'm sure 2fa doesn't help with that (:


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Ahmad Samir

On 25/10/22 12:11, Carl Schwan wrote:

Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (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_authentication.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-2fa-for-all-users-in-a-group

We can just require 2fa for developers because with great powers come great
responsibilities.

Cheers,
Carl



Can a first time contributor create a fork, create multiple/100 MR's and spin up CI jobs? if yes, 
then, first time contributors can disrupt the system.


Weren't there some suspicious accounts that were using our gitlab instance for bitcoin mining (I 
could be wrong, I vaguely remember someone from Sysadmin team talking about something like that)? 
were these first time contributors or ones with developer accounts?



--
Ahmad Samir



OpenPGP_signature
Description: OpenPGP digital signature


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Dan Leinir Turthra Jensen
On Tuesday, 25 October 2022 11:11:46 BST Carl Schwan wrote:
> Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (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".

-- 
..dan / leinir..
http://leinir.dk/




Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Carl Schwan
Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (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_authentication.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-2fa-for-all-users-in-a-group

We can just require 2fa for developers because with great powers come great
responsibilities.

Cheers,
Carl

> 
> Greetings
> Christoph
> 
> > Thanks,
> > Ben
> > 
> > Links:
> > --
> > [1] http://invent.kde.org
> 
> 
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread Frederik Schwarzer
Hi,

making assumptions or generalising a group of people will always "forget" about 
some people.

What about translators? Are they all as "techy" as you imagine all our devs 
are? (Spoiler: no they aren't)
What about older contributors (like me)? Are they all as up-to-date with 
emerging technologies as you think they are? Maybe not.

I do have 2FA at work. It's a hardware token with a "put the number in this 
field" workflow. I did not have to set that up, I just use it.
My bank uses a very special kind of 2FA which I just recently recognised as 
such. Meaning, I cannot use my bank's 2FA technology for anything else so it 
feels like a different tech.
Otherwise I did not yet have had the need for 2FA in my private life. I despise 
having accounts, so I do not use Paypal, Google, Amazon, Microsoft, Facebook or 
any other of the "common" accounts and do my online shopping as guest to not 
bother with login stuff there either.

So now for the KDE login I had to set up 2FA for the first time and it involved 
some confusion. I managed to set up KeePassXC with TOTP now but not without a 
close call in ruining my tax authority account credentials in the process 
becausecitvwas not clear to me at first that the Set up TOTP menu entry worked 
on one of the existing entries rather than enabling a separate way of adding 
accounts.

Speaking of taxes. In my country it's the last week for handing in tax reports, 
so I might have decided that my mind currently does not have enough free 
capacity to bother with keeping my KDE account working. The time span to handle 
this situation seems rather tight to me.

Anyway, while I see good reasoning behind the decision to use 2FA, I think it 
wasn't handled in a very good way. It would have been good to have more time 
for the change and also offer more support for people completely new to 2FA. 
Throwing in names of apps alone is not enough. Not everyone has time to spend 
an evening investigating those apps and then set one (or several) up just to 
realise it uses different terminology than gitlab (key vs secret key, pin vs 
password etc) which makes setting it up a fun little guessing game with quite 
some shrugging.

Please do not surprise a diverse group of people with different techy 
backgrounds, different age and different levels of smartness (meaning: 
eagerness to dig into new topics asap) with making something mandatory just 
because you and everyone you know are familiar with that particular tech anyway.

On a side not, I have decided to use this as an opportinity to set up 2FA for 
more of the few accounts I have and I also bought two Yubikeys to play around 
with those as well ... But I do not assume, everybody appreciates that kind of 
opportinities.

Cheers
Frederik



On 25 October 2022 05:39:32 CEST, Victoria Fierce  
wrote:
>I would like to think that anyone who either knows /enough/ about KDE that 
>they want to contribute or has used basically any other internet service 
>before coming to KDE is already familiar with 2FA that it won't be a problem 
>for them. Our users are smart, our devs are also (often) smart, everyone 
>involved is probably smarter and more capable than we would imagine. If KDE 
>contributions decline for any reason, I don't think it would be for technical 
>ones. My bank needs 2FA, my paypal needs 2FA, my work needs 
>lordt-knows-how-much 2FA, heck even when I'm using Matrix I need to do some 
>kind of 2FA-ish dance to verify the login and distribute crypto keys.
>
>On Mon, Oct 24, 2022, at 9:19 AM, Christoph Cullmann (cullmann.io) wrote:
>> Hi,
>>
 Could the 2FA stuff perhaps be limited to people with developer role
 or
 such?
>>> 
>>> It is technically possible to only apply the mandatory 2FA rules to
>>> only certain groups as Developer accounts are simply membership in
>>> teams/kde-developers.
>>> See
>>> https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group
>>> for the documentation on this.
>>> 
>>> Given that we are using Invent for authenticating our various other
>>> services and the users of those aren't necessarily developers (while
>>> still having access to sensitive information) it seemed more prudent
>>> to enforce 2FA for everyone to ensure all our systems have a minimum
>>> baseline of industry best practice protection in place.
>>> 
>>> This also avoids any issue when people are granted a developer account
>>> and suddenly find themselves subject to a new requirement.
>>
>> I think it is rather worse that now first time contributors have this 
>> requirement.
>>
>> A lot of people already complain "why can I not just use my GitHub 
>> account',
>> now they need to setup this in addition.
>>
>> And yes, beside for invent.kde.org, I never needed to use my Google Auth
>> App beside for some hosting.
>>
>> All other things I use that have 2FA use different methods that don't 
>> need
>> any such app on my phone.
>>
>> Therefore that is more then just 2 

Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Victoria Fierce
I would like to think that anyone who either knows /enough/ about KDE that they 
want to contribute or has used basically any other internet service before 
coming to KDE is already familiar with 2FA that it won't be a problem for them. 
Our users are smart, our devs are also (often) smart, everyone involved is 
probably smarter and more capable than we would imagine. If KDE contributions 
decline for any reason, I don't think it would be for technical ones. My bank 
needs 2FA, my paypal needs 2FA, my work needs lordt-knows-how-much 2FA, heck 
even when I'm using Matrix I need to do some kind of 2FA-ish dance to verify 
the login and distribute crypto keys.

On Mon, Oct 24, 2022, at 9:19 AM, Christoph Cullmann (cullmann.io) wrote:
> Hi,
>
>>> Could the 2FA stuff perhaps be limited to people with developer role
>>> or
>>> such?
>> 
>> It is technically possible to only apply the mandatory 2FA rules to
>> only certain groups as Developer accounts are simply membership in
>> teams/kde-developers.
>> See
>> https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group
>> for the documentation on this.
>> 
>> Given that we are using Invent for authenticating our various other
>> services and the users of those aren't necessarily developers (while
>> still having access to sensitive information) it seemed more prudent
>> to enforce 2FA for everyone to ensure all our systems have a minimum
>> baseline of industry best practice protection in place.
>> 
>> This also avoids any issue when people are granted a developer account
>> and suddenly find themselves subject to a new requirement.
>
> I think it is rather worse that now first time contributors have this 
> requirement.
>
> A lot of people already complain "why can I not just use my GitHub 
> account',
> now they need to setup this in addition.
>
> And yes, beside for invent.kde.org, I never needed to use my Google Auth
> App beside for some hosting.
>
> All other things I use that have 2FA use different methods that don't 
> need
> any such app on my phone.
>
> Therefore that is more then just 2 clicks for a lot of people.
>
> Greetings
> Christoph
>
> -- 
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Andrius Štikonas
2022 m. spalio 24 d., pirmadienis 00:16:30 BST Jack rašė:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> > 
> > This afternoon I updated invent.kde.org 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_authentication.html#generate-new-recovery-codes-using-ssh
> > for more details on this.
> > 
> > Please let us know if there are any queries on the above.
> > 
> > Thanks,
> > Ben
> Sorry to be dense, but without a webauthn token device, it seems I'm at  
> a total block if I don't have a phone (or don't have it with me.)  Is  
> that correct, or is there some fine manual I need to read?
> 
> Thanks.
> 
> Jack
> 

Hi,

You can actually made webauthn token device yourself if you are willing to do a 
bit of work.

You can buy a couple of ST-Link V2 debuggers for a few euros, use one of them 
to reflash another
with U2F firmware (e.g. https://github.com/gl-sergei/u2f-token) and then 
register it in Gitlab.

Kind regards,
Andrius

signature.asc
Description: This is a digitally signed message part.


Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Ben Cooksley
On Mon, Oct 24, 2022 at 11:56 PM Raghavendra Kamath 
wrote:

> On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote:
> > I
> > have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> > next time you access it.
>
> Is the 2FA in KDE identity website same as this. The KDE identity shows a
> grid
> based system where you combine the grid and your password for 2FA.
>
> I have also already enabled 2FA for KDE identity with totp, does this
> supersede it?
>

Gitlab will be replacing KDE Identity for authentication, so this 2FA setup
supersedes that yes.

Cheers,
Ben


>
>
> --
> Raghavendra Kamath
> emblik.studio
>
>
>


Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Raghavendra Kamath
On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote:
> I
> have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> next time you access it.

Is the 2FA in KDE identity website same as this. The KDE identity shows a grid 
based system where you combine the grid and your password for 2FA. 

I have also already enabled 2FA for KDE identity with totp, does this 
supersede it?


-- 
Raghavendra Kamath
emblik.studio




Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Christoph Cullmann (cullmann.io)

On 2022-10-24 11:23, Ingo Klöcker wrote:
On Montag, 24. Oktober 2022 09:19:49 CEST Christoph Cullmann 
(cullmann.io)

wrote:

I think it is rather worse that now first time contributors have this
requirement.


Do you have proof for this, e.g. a study, or is this just your 
Bauchgefühl

(gut feeling)?


I can not proof this.

I only know that even for myself this makes it a lot more work to login,
if I don't start to setup an application for that on my tablet and main 
machine

and work machine, too.

But I see the point that it makes sense for accounts with elevated 
rights.




There is plenty of proof (e.g. TBs of leaked password databases) that 
lots of
people use insecure passwords and that lots of people reuse the same 
"secure"

password everywhere. 2FA protects those ignorant people. If the 2FA-
requirement on invent helps to make more people aware of 2FA, then 
that's a

good side-effect.

Besides, my hope is that with FIDO2 "soon" passwords will be a relic of 
the

past.


That is a nice dream, but IMHO very unlikely in the near future.

Greetings
Christoph



Regards,
Ingo


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Ingo Klöcker
On Montag, 24. Oktober 2022 09:19:49 CEST Christoph Cullmann (cullmann.io) 
wrote:
> I think it is rather worse that now first time contributors have this
> requirement.

Do you have proof for this, e.g. a study, or is this just your Bauchgefühl 
(gut feeling)?

There is plenty of proof (e.g. TBs of leaked password databases) that lots of 
people use insecure passwords and that lots of people reuse the same "secure" 
password everywhere. 2FA protects those ignorant people. If the 2FA-
requirement on invent helps to make more people aware of 2FA, then that's a 
good side-effect.

Besides, my hope is that with FIDO2 "soon" passwords will be a relic of the 
past.

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.


Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Timothée Giet

Le 24/10/2022 à 09:24, Ivan Čukić a écrit :

Sorry to be dense, but without a webauthn token device, it seems I'm at
a total block if I don't have a phone (or don't have it with me.)  Is
that correct, or is there some fine manual I need to read?

You can generate TOTP codes using KeePassXC.

There's also Dan Vratil's Plasma Pass which does OTP (I'm using it for
everything nowadays - don't even launch the app on my phone anymore)

Cheers,
Ivan

I didn't see it mentionned on this list yet, there's also the oathtool 
command.


It can be used either directly ( 
https://gitlab.com/gitlab-org/gitlab/-/issues/17124 ) or in a more 
secure way with a bit of scripting (like in this example 
https://karl-voit.at/2019/03/03/oathtool-otp/ ).


Cheers,

Timothée



Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Ivan Čukić
> > Sorry to be dense, but without a webauthn token device, it seems I'm at
> > a total block if I don't have a phone (or don't have it with me.)  Is
> > that correct, or is there some fine manual I need to read?
> 
> You can generate TOTP codes using KeePassXC.

There's also Dan Vratil's Plasma Pass which does OTP (I'm using it for 
everything nowadays - don't even launch the app on my phone anymore)

Cheers,
Ivan

-- 
dr Ivan Čukić
ivan.cu...@kde.org, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12





Re: Gitlab update, 2FA now mandatory

2022-10-24 Thread Christoph Cullmann (cullmann.io)

Hi,


Could the 2FA stuff perhaps be limited to people with developer role
or
such?


It is technically possible to only apply the mandatory 2FA rules to
only certain groups as Developer accounts are simply membership in
teams/kde-developers.
See
https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group
for the documentation on this.

Given that we are using Invent for authenticating our various other
services and the users of those aren't necessarily developers (while
still having access to sensitive information) it seemed more prudent
to enforce 2FA for everyone to ensure all our systems have a minimum
baseline of industry best practice protection in place.

This also avoids any issue when people are granted a developer account
and suddenly find themselves subject to a new requirement.


I think it is rather worse that now first time contributors have this 
requirement.


A lot of people already complain "why can I not just use my GitHub 
account',

now they need to setup this in addition.

And yes, beside for invent.kde.org, I never needed to use my Google Auth
App beside for some hosting.

All other things I use that have 2FA use different methods that don't 
need

any such app on my phone.

Therefore that is more then just 2 clicks for a lot of people.

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Mathias Homann
Am Montag, 24. Oktober 2022, 01:16:30 CEST schrieb Jack:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> > 
> > This afternoon I updated invent.kde.org 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_authentication.
> > html#generate-new-recovery-codes-using-ssh for more details on this.
> > 
> > Please let us know if there are any queries on the above.
> > 
> > Thanks,
> > Ben
> 
> Sorry to be dense, but without a webauthn token device, it seems I'm at
> a total block if I don't have a phone (or don't have it with me.)  Is
> that correct, or is there some fine manual I need to read?

There is (at least) OTPClient on linux, and 2Fast on windows that can both 
manage your 2FA keys for you in the same way that an app on a phone would. I'm 
in fact using them both, and keep my keys in sync by importing exports from 
FreeOTP+ which I use on my phone.


Cheers
MH


-- 
Mathias Homann
mathias.hom...@opensuse.org
Jabber (XMPP): le...@tuxonline.tech
Matrix: @mathias:eregion.de
IRC: [Lemmy] on freenode and ircnet (bouncer active)
keybase: https://keybase.io/lemmy
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

signature.asc
Description: This is a digitally signed message part.


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Ben Cooksley
On Mon, Oct 24, 2022 at 12:16 PM Jack 
wrote:

> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> >
> > This afternoon I updated invent.kde.org 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_authentication.html#generate-new-recovery-codes-using-ssh
> > for more details on this.
> >
> > Please let us know if there are any queries on the above.
> >
> > Thanks,
> > Ben
> Sorry to be dense, but without a webauthn token device, it seems I'm at
> a total block if I don't have a phone (or don't have it with me.)  Is
> that correct, or is there some fine manual I need to read?
>

This will depend on whether it is a one-off situation or not.

If it is a one-off situation, you can use one of your recovery codes (and
if needed, obtain a fresh set of those via SSH as documented above) to
login to Gitlab.
If it is something that will happen on a more regular basis then setting up
the TOTP application on a device you have regular access to (or obtaining a
Webauthn token) would be recommended.


>
> Thanks.
>
> Jack
>

Thanks,
Ben


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Anna “CyberTailor”
On 2022-10-23 19:16, Jack wrote:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > 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_authentication.html#generate-new-recovery-codes-using-ssh
> > for more details on this.
> > 
> > Please let us know if there are any queries on the above.
> > 
> > Thanks,
> > Ben
> Sorry to be dense, but without a webauthn token device, it seems I'm at  
> a total block if I don't have a phone (or don't have it with me.)  Is  
> that correct, or is there some fine manual I need to read?

You can generate TOTP codes using KeePassXC.


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Jack

On 2022.10.23 02:32, Ben Cooksley wrote:

Hi all,

This afternoon I updated invent.kde.org 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_authentication.html#generate-new-recovery-codes-using-ssh
for more details on this.

Please let us know if there are any queries on the above.

Thanks,
Ben
Sorry to be dense, but without a webauthn token device, it seems I'm at  
a total block if I don't have a phone (or don't have it with me.)  Is  
that correct, or is there some fine manual I need to read?


Thanks.

Jack


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Ben Cooksley
On Mon, Oct 24, 2022 at 4:55 AM Christoph Cullmann (cullmann.io) <
christ...@cullmann.io> wrote:

> 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_authentication.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,
>

Hi Christoph,


>
> 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.
>

That is something you actually can't do - at least not entirely :)

Release branches are marked as protected within Gitlab, meaning that
destructive operations will be blocked by Gitlab itself.
Even if this was to be permitted by Gitlab, our hooks would intervene and
ensure a backup of the branch was taken immediately before it was deleted -
making the damage an inconvenience only as nothing would be lost.

(See refs/backups/ in any Git repository on invent.kde.org, these refs are
also protected by the hooks so they cannot be harmed)


>
> Could the 2FA stuff perhaps be limited to people with developer role or
> such?


It is technically possible to only apply the mandatory 2FA rules to only
certain groups as Developer accounts are simply membership in
teams/kde-developers.
See
https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group
for the documentation on this.

Given that we are using Invent for authenticating our various other
services and the users of those aren't necessarily developers (while still
having access to sensitive information) it seemed more prudent to enforce
2FA for everyone to ensure all our systems have a minimum baseline of
industry best practice protection in place.

This also avoids any issue when people are granted a developer account and
suddenly find themselves subject to a new requirement.

Thanks,
Ben


>
> Greetings
> Christoph
>
> >
> > Thanks,
> > Ben
> >
> > Links:
> > --
> > [1] http://invent.kde.org
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
>


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Christian
Personally I'd recommend Aegis 
(https://f-droid.org/packages/com.beemdevelopment.aegis/) over FreeOTP(+) due 
to the possibility to disable screencaps, the privacy focussed settings such 
as tap to reveal and encrypted exports (afaik FreeOTP only does unencrypted) 
and the possibility to import entries from Google Authenticator, which will 
make the migration a lot easier. 

In either case, any of them will work.

Kind regards, 

Christian

Am Sonntag, 23. Oktober 2022, 21:18:27 CEST schrieb Bernie Innocenti:
> I was going to recommend andOTP for Android, but sadly the author no
> longer has time to maintain it:
> 
>https://github.com/andOTP/andOTP
> 
> Looks like FreeOTP+ is actively maintained, so I'll look into migrating
> to it.
> 
> On 24/10/2022 03.38, Sune Vuorela wrote:
> > On 2022-10-23, Ben Cooksley  wrote:
> >> (such as a Yubikey) or TOTP (using the app of choice on your phone)
> > 
> > There seems to be some questions about what possible "app of choice" is
> > available.
> > 
> > kde has keysmith
> > f-droid have freeotp+
> > sailfish has sailotp somewhere
> > 
> > In the less privacy oriented ecosphere, but should not actually use this
> > data for their nefarious purposes,
> > 
> >   - microsoft has a authenticator
> >   - google has a authenticator
> >   - github has a authenticator
> > 
> > There is probably others in both the google and apple stores and maybe
> > also other stores.
> > 
> > /Sune






Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Mathias Homann
Am Sonntag, 23. Oktober 2022, 21:18:27 CEST schrieb Bernie Innocenti:
> I was going to recommend andOTP for Android, but sadly the author no
> longer has time to maintain it:
> 
>https://github.com/andOTP/andOTP
> 
> Looks like FreeOTP+ is actively maintained, so I'll look into migrating
> to it.

I've been using FreeOTP+ for quite some time now - the best part about it is 
that it can export your 2FA keys in a format that can be imported into 
OTPClient on Linux, and into 2Fast on Windows - and of course the export is a 
pretty damn fine backup, too.

Cheers
MH

-- 
Mathias Homann
mathias.hom...@opensuse.org
Jabber (XMPP): le...@tuxonline.tech
Matrix: @mathias:eregion.de
IRC: [Lemmy] on freenode and ircnet (bouncer active)
keybase: https://keybase.io/lemmy
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

signature.asc
Description: This is a digitally signed message part.


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Akseli Lahtinen
I highly recommend Aegis authenticator, it's on f-droid as well:
https://getaegis.app/

- Akseli

On Sunday, 23 October 2022 22.18.27 EEST Bernie Innocenti wrote:
> I was going to recommend andOTP for Android, but sadly the author no
> longer has time to maintain it:
> 
>https://github.com/andOTP/andOTP
> 
> Looks like FreeOTP+ is actively maintained, so I'll look into migrating
> to it.
> 
> On 24/10/2022 03.38, Sune Vuorela wrote:
> > On 2022-10-23, Ben Cooksley  wrote:
> >> (such as a Yubikey) or TOTP (using the app of choice on your phone)
> > 
> > There seems to be some questions about what possible "app of choice" is
> > available.
> > 
> > kde has keysmith
> > f-droid have freeotp+
> > sailfish has sailotp somewhere
> > 
> > In the less privacy oriented ecosphere, but should not actually use this
> > data for their nefarious purposes,
> > 
> >   - microsoft has a authenticator
> >   - google has a authenticator
> >   - github has a authenticator
> > 
> > There is probably others in both the google and apple stores and maybe
> > also other stores.
> > 
> > /Sune


signature.asc
Description: This is a digitally signed message part.


Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Sune Vuorela
On 2022-10-23, Ben Cooksley  wrote:
> (such as a Yubikey) or TOTP (using the app of choice on your phone)

There seems to be some questions about what possible "app of choice" is
available.

kde has keysmith
f-droid have freeotp+
sailfish has sailotp somewhere

In the less privacy oriented ecosphere, but should not actually use this
data for their nefarious purposes, 
 - microsoft has a authenticator
 - google has a authenticator
 - github has a authenticator

There is probably others in both the google and apple stores and maybe
also other stores.

/Sune




Re: Gitlab update, 2FA now mandatory

2022-10-23 Thread Christoph Cullmann (cullmann.io)

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_authentication.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?


Greetings
Christoph



Thanks,
Ben

Links:
--
[1] http://invent.kde.org


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Gitlab update, 2FA now mandatory

2022-10-23 Thread Ben Cooksley
Hi all,

This afternoon I updated invent.kde.org 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_authentication.html#generate-new-recovery-codes-using-ssh
for more details on this.

Please let us know if there are any queries on the above.

Thanks,
Ben