[Alioth-staff-replacement] Alioth needs your help

[Alexander Wirt]

On Sun, 20 Aug 2017, Geert Stappers wrote:

> On Sun, Aug 20, 2017 at 02:39:36PM +0200, Alexander Wirt wrote:
> > On Sun, 20 Aug 2017, Shengjing Zhu wrote:
> > > On Sun, Aug 20, 2017 at 7:47 PM, Mattia Rizzolo <mattia at debian.org> wrote:
> > > > I wonder: would it be so complex to have gitlab use sso.d.o for
> > > > authentication?  Consider that sso.d.o only provides with user
> > > > certificates, doesn't have any openid/oauth2/whatever provider.
> > > >
> > > > sso.d.o could grow a registration feature for guest accounts (instead of
> > > > pulling them from alioth, I can't see that as something so different).
> > > >
> > > 
> > > It would be great if sso.d.o provides oauth2.
> > > And has a independent account system for guests, considering after Alioth
> > > retired, there should be a way for guests to access.
> > > 
> > > And I think it still needs a shim for gitlab to integrate with
> > > sso.d.o, and restrict
> > > the account name.
> > > For example, someone login to a registery service via sso.d.o,
> 
> URL to sso.d.o.  is  https://sso.debian.org/
> 
> 
> > > and that service creates account on gitlab with proper name.
> > > Or better, we write a ruby plugin that makes gitlab talk to sso.d.o directly.
> > > After a quick look at gitlab docs, it can be achieved by writing a omniauth[1]
> > > plugin
> > it will probably the other way round. Gitlab as being a backend for sso.
> 
> That feels wrong.
> 
> > SSO doesn't have own backends.
> 
> Isn't  db.debian.org the backend that knowns about all DD?
Should mean: anything own. I needs external backends. It doesn't have any
kind of user management.

Alex