On Mon, 6 Apr 2020 20:38:59 +0200 Enrico Zini <enr...@enricozini.org> wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +0000, Luca Filipozzi wrote: > > > That said, please consider an approach that would see keycloak used as > > an idenitity broker, allowing external users to create accounts using > > social identities that are then promoted to full Debian identities (in > > LDAP) if they complete the onboarding process. Could be used as > > replacement for debsso, could be used for wiki, could be used for > > debconf, could be used for salsa. What does keycloak provide over something like lemonldap or similar tools? > [...] > and well known. Gitlab's codebase, while large and complex, is widely > deployed, and we already have know-how about it in Debian. I was previously involved with a company that audited various git-hosting services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so please forgive the lack of specifics. Gitlab is a tool that gets many things right, and many things wrong. Access control is an area where I have seen some critical bugs. Some of those bugs lead me to not trust it as a non-internal authentication source. Security aside, and perhaps more importantly, is the vendor lock-in problem that can be seen with Alioth. If that system were not being used as an authentication source, then the whole migration would have been entirely agnostic to such concerns and changing auth sources would never have come up. Choosing to migrate to gitlab as an authentication source just introduces a painful(?) migration for the sake of another similar migration in the future. > I would not want to see a workable proposal that we could implement over > the next two weeks and that we have the resources to maintain long-term, > blocked by something that risks getting us stuck with sso.d.o for > another bunch of years until we get it right, and possibly ending up > being maintained long term by a team with a dwindling bandwidth and bus > factor. I was previously (before gitlab's deployment) lead to believe that the problem was already being dealt with. Since this is still a problem, then I volunteer to implement and maintain whatever solution is most appropriate. Is there any summary of where those previous discussions lead and/or their conclusions? I saw something about GSoC mentioned. Is there anything viable which can be taken from that effort? Also, please, don't focus on time to deployment. I'll do whatever we need in order to implement a proper long-term solution. As you may have noticed- I take my time to plan projects before execution. If anything, this is a change that should involve more planning than anything else. -- Michael Lustfield
