I am not going into the advantages of the "Salsa as OIDC" provider
approach, nor into summarising the brainstorming that happened about how
this improvement could either combine with other things or could merge
into a longer-term SSO strategy: I am only focusing on blockers. People
in this thread have already started thinking about incremental
improvements to this proposal and about other proposals, and that is
*great*. I wouldn't want work to *end* at this: I want work to
*begin* from this.
The current situation with Single Sign-On in Debian sits in a spectrum
between painful and useless.
The painful side is nm.debian.org, where we force people to use it,
leaving them no other choice. https://wiki.debian.org/DebianSingleSignOn does a great job of listing workarounds for all the shortcomings, but
currently gaining access to nm.debian.org might be for some people the
most complex, frustrating, and time consuming step towards becoming DD
I have for long being considering taking contributors.debian.org
offline: it's irresponsible to keep that service running if people can't
log in to manage their accounts. The Salsa as OIDC provider proposal is
something I'd rather work on, than taking the service offline.
Other services in the Debian federation are instead implementing their
own account management (like DebConf), or looking into directly
authenticating via OIDC against Salsa anyway, like DebianSocial.
I see using Salsa as OIDC provider as a mitigating step that would
leave Debian with a useful Single Sign-On, without blocking further
progress. Waiting longer means either closing services or scattering the
federation into ad-hoc solutions.
I solicited feedback to see if, for some reason, this step would make
matters *worse* than the status quo, or make it *harder* to migrate
onwards to something else.
I'm summarising here the concerns that have been raised and how they've
* There are better solutions out there, like Keycloak or Lemon LDAP NG
It would be great to have them. In the meantime, using Salsa as OIDC
provider does not seem to be getting in the way of their potential
adoption in the future.
It does not seem that we would end up worse than we are now in that
respect, and the next iteration of SSO in Debian is free to start at any
* There was work done on using Lemon LDAP NG plus Nacho
There was indeed, and Debian has never managed to put together enough
energy to deploy it. I strongly want to thank Alexander Wirt and Birger
Schacht for working on it, and sadly it never grew into something with
enough support in the project to get deployed and maintained.
This has stalled for long enough, and there is no indication that it
could get deployed anytime soon.
* Migrating to Salsa as OIDC provider would give us an imperfect but
good enough local optimum, and we will get stuck in that
Perfect is the enemy of good.
Blocking a workable proposal for incremental improvement in case it
turns out to be good enough, seems inconsistent to me give the current
state of single sign-on in Debian.
We are not proposing Salsa as the ultimate solution, but as a fix for
the current situation, that does not prevent moving on to something
* There might be other solutions more secure than Gitlab
I would find it hard to argue that the current sso.debian.org codebase
is better than Gitlab, so we would be doing no worse than now.
Additionally, the whole SSO ecosystem has always been considered
somewhat untrusted and kept outside of the security perimeter of
sensitive Debian operation, and this is not going to change with our
* If we drop the requirement of having "-guest" for non-DD users on
Salsa, how can one tell if a user is a DD?
Waldi has a prototype ready for showing official membership status
prominently and directly on a user's page, with information synced from
Making sure that only current DDs have access to certain repositories is
a problem that can be solved independently from account naming policies.
* Will nm.d.o have a field which reflects the username on salsa?
Yes, finally! It's been really painful not to have that so far.
* How do we avoid namespace clashes between LDAP and Salsa?
The two namespaces start in sync for non-guest accounts. nm.debian.org
will forward the Salsa username to LDAP when new LDAP accounts are
created, and will ask people who don't have an LDAP account, to choose a
Salsa account name that is free in LDAP.
This means that LDAP remains independent from Salsa and DSA remains
fully in control over the user account namespace. It is the Salsa
namespace that will have to adapt to what is free on LDAP's side, the
moment someone with a Salsa account requests an account in LDAP.
For people who get an account in LDAP and later want to rename their
Salsa account, the option remains to register a new account to keep the
old name locked.
Re: Wrapping up the Salsa as OIDC provider proposal
On Fri, 2020-04-10 at 20:38 +0200, Enrico Zini wrote:
> * If we drop the requirement of having "-guest" for non-DD users on
> Salsa, how can one tell if a user is a DD?
> Waldi has a prototype ready for showing official membership status
> prominently and directly on a user's page, with information synced from
This seems to address the only concern I had with your proposal.
Thanks for all your work on SSO.
73.46% of all statistics are made up.
> I could not see any reason why this proposal would make the
> situation *worse* than the status quo, or any reason this
> proposal would block further migration to something else in
> the future.
Let me publicly thank you for your work in sso, nm, contributors,
etc. I've been using these services for years and they have made
my life in Debian a lot easier that I can probably imagine.
Big kudos for you and all people involved!
> I therefore consider it a useful iterative improvement over
> what we have, and see no reason to block it.
FWIW, I like interative improvements and I fully support your
approach. Though I can understand that there are some concerns
in the long term, I'm totally up for small improvements even
if those end up making a longer path.
Sorry for not sharing this earlier and support your initiative.