Re: Gitlab update, 2FA now mandatory
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
> > 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
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
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
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
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
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
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
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
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
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
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
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
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