Change of policy on GitLab account creation/login?
Raymond Toy
toy.raymond at gmail.com
Sun Oct 7 17:02:22 UTC 2018
On Sun, Oct 7, 2018 at 5:55 AM Erik Huelsmann <ehuels at gmail.com> wrote:
> Hi all,
>
> Almost 4 years have passed since the initial installation of GitLab on
> common-lisp.net.
> During that period, GitLab (the open source project) has seen tremendous
> growth both in user community and functionality. Our own GitLab instance
> has grown quite a bit as well. With almost 700 projects and nearly 500
> users, it's quite a bit bigger now than the initial CVS migration which
> resulted in 379 projects and 395 users. (We did both the Git and Darcs
> migrations after that, which added to the growth.)
>
> Originally, we decided we wanted to create our own accounts and not
> support account-auto-creation (based on experience shared by GitLab.com).
> Today, GitLab lets itself be configured to auto-create accounts from GitHub
> using GitHub credentials.
> We have long supported the possibility of allowing accounts to be tied to
> Google and GitHub OAuth2 for the purpose of authentication. Additionally,
> we support 2FA these days.
> I'm wondering if we can be a bit more relaxed with account creation
> (allowing auto-creation), but be a bit more strict on account login: i.e.
> require 2FA.
>
Auto-creation seems nice since it lowers the barrier to entry for people
wanting to create create projects or filing bugs, and there's also less
work for the admins. But I thought one reason you stopped doing this was
the number of spam accounts. Will this become a problem?
Are you going to require 2FA for existing accounts as well? And what 2FA
methods will you support? SMS? Google Authenticator app? Security (FIDO)
keys? (I'm finally going to set up 2FA for my personal accounts using
security keys, so this comes at a good time. I've had to add 2FA to my
github account already, using the authenticator app.)
> Do you have any opinion on the matter?
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
--
Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20181007/117d307f/attachment.html>
More information about the clo-devel
mailing list