Hello,

I've just fixed sso.debian.org to work again after the upgrade of
diabelli to bullseye.

I however have not used SSO certificates in years and don't intend to.
This means I'm unable to test if certificate authentication still works,
and to effectively maintain the site: I won't be able to do much more to
it than fix Django issues.

Unless some other DD steps in to take over maintenance, I annouce my
intention to decommission sso.debian.org by the end of March 2023.

I would welcome better single sign-on systems for Debian than Salsa, and sso.debian.org is not it.

I'm posting this to debian-devel as an early heads-up and a call for
other maintainers. If nobody steps in my the end of October, I'll post a
proper sunset announce to debian-devel-announce.


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEJJAhGtA2CH5tHZqS0P9Jy+P0+2gFAmNMPdEACgkQ0P9Jy+P0 +2gP7w/+JptLSgIfRFTCAftuMed49xrHhu7E4JTyiJXTl/Biq1NXC/KoPEpnuU0e +Jwo1f63bGCExNXrUwT9fVeZiKrIdT4Hn/s+NHrMg+pDeHL6FZc7FrsxK1lY2ySF F5vJToPwgbVtjUOGNb7ec+SFOoH7sHB0pEvjb71LdjS/ckNXY5v8WOSgG9yqF0wf PhLWykCkHoXrqpzjQ6tsq09VaG1pznsLqwgbCaScMhJ4ak2ojdHZbJEtUjpjbZa4 IKWyDmg8ZsWMYfufGA1JfIrhEdVNMDJ4RFLOBLd8G5JniEtvgc1RuYQ5QwTxM+Px 6Ip8nr3ppae89sNUTIPy4umj8cusIQ+ddB4O/w2Z6+eHp8B49hxKREiWM40mRlqb RChH0qmmXZlHZ3xLk5zE/a54NQGv6cndHL9azWSQ0twWEDToUDCRjV9FF2I3Hmiq 3GyHHSU52l0AmEZZgtoGHFIgqhi1AecVzcUUFQCO/ZjfmsLa26J/ci/R3uwmRtKk Py7VVKji01fmC53OdZsODZ2o+FhLVH/cnMC/pfxMUxCTz68IwyTGZ0kUt3LcyOTd VtkLVFALJgk7geZafMKTxvuGzOTS0ErPVvtzVpbPBi/aqZwGpIB0ic+OxOTpgVZJ uKWMoZFpJAziaB83YgLVNVzkakxSFG/+dLDZOzawLLsqQt08v4U=
=psL1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sun 16 Oct 2022 at 07:22PM +02, Enrico Zini wrote:

Hello,

I've just fixed sso.debian.org to work again after the upgrade of
diabelli to bullseye.

I however have not used SSO certificates in years and don't intend to.
This means I'm unable to test if certificate authentication still works,
and to effectively maintain the site: I won't be able to do much more to
it than fix Django issues.

Unless some other DD steps in to take over maintenance, I annouce my intention to decommission sso.debian.org by the end of March 2023.

I would welcome better single sign-on systems for Debian than Salsa, and sso.debian.org is not it.

I'm posting this to debian-devel as an early heads-up and a call for
other maintainers. If nobody steps in my the end of October, I'll post a proper sunset announce to debian-devel-announce.

Thank you for the notification.

At the present time, I believe this will break DDs logging into tracker.debian.org. I recently had to mess around with client
certificates in order to login there and subscribe to a new package.

--
Sean Whitton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-10-16 at 16:21 -0700, Sean Whitton wrote:

At the present time, I believe this will break DDs logging into tracker.debian.org.  I recently had to mess around with client
certificates in order to login there and subscribe to a new package.

It will still be possible to manage DPT subscriptions via email:

https://www.debian.org/doc/manuals/developers-reference/resources.en.html#the-debian-package-tracker
https://qa.pages.debian.net/distro-tracker/usage/messages.html#subscribing-to-a-package

In addition it will still be possible to subscribe via the web using
the form at the bottom left of the pages on the old PTS, IIRC this will
send mail to modify the DPT subscriptions.

https://packages.qa.debian.org/z/zlib.html

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmNMrxEACgkQMRa6Xp/6 aaNSJA/+ItDCOB6zLPK/D6P9Q6fA366A3UyfI3qfbemLf6x1IqjO1h8ZxV4bSpMo Q9tL7s026wleH/YbhLDLXrkXJ6IE5topFER5rR06KovaAY9WkzFxf29SSkpBfbjx hDEBa1dS9qp1544NoxTddJof+c0p9lQGK2+IU4pOYOXN+RMfLYu9qy4/4LFTnDIz E/3hISvciFG8jzBDitqjF7cacCeJMyV6Mr2/rf6PE02Hn/fFsAD0HQSJzmILzsa3 WsvjSFGsIkXTqXvapBWbd82G3y79TTIxe398OFr//opXBJ5He99glQR+KPxEMfNx SnzvRO6Zjk5K/Up6d9AheJ0W0YjKyQ29JhF9ZOi7r97tnmwyfDh2/cFMFoU/6fsz oW6pEJXP+Iv6t6UHFnhWh3QF8VE9RFCkL4IjLzlEupGtJcdnhfDbokIr/EVOBMW7 beAfyhJmWr+z1vAVA3ZyuPf2ARgnNEu3RwgMCdzKib8l3Hth7rJ40dMyz7GQRt4I CFR53eZbtmkR8tl2glQetCyG3Dy/F+VisG1JFQRH7GacV7DsfeLtwl5RhWf3Xnxz GEE1I+cQyvSR2726umCVjT9hGfVWduPEvCjHen3jk/kqw31FO0exvBwN3GoNXAbv 0Y05zyN0lKrAuGmqi2aAk/aFQCjrW4NAX8INgw4OO+InLYCEVP0=
=dxUR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Oct 16, 2022 at 7:23 PM Enrico Zini <enrico@enricozini.org> wrote:

I would welcome better single sign-on systems for Debian than Salsa, and sso.debian.org is not it.

I think Keycloak [1] is quite nice and used more and more by other
FOSS projects (it is RedHat sponsored after all). Opinions about using
this as potential SSO? Can be easily integrated to Salsa/Gitlab as
well (packaging might not be easy though).

Cheers,
Stephan

[1]: https://www.keycloak.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Mon, 17 Oct 2022, at 09:52, Hakan Bayındır wrote:

We use Keycloak in both at office and in international projects as
backbones of relatively big and federated SSO systems, and it works fine.

It's not very hard to deploy and configure on bare metal. Enabling its
own HTTPS/SSL features are also relatively straightforward.

I'm sure that it can handle a project at the size of Debian. It handles traffic from half of EU (as a part of EGI SSO infrastructure) just fine.

We use Keycloak recently at Collabora, and it does its job well. We’ve only started using it recently, so it’s not being used up to its full potential, I guess, but from what I was told by people who worked with it closely there weren’t any issues,
and it doesn’t seem resource-hungry.

--
Cheers,
Andrej

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FNbI0eBdTZtuJA5kzhwk58pb
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

V2UgdXNlIEtleWNsb2FrIGluIGJvdGggYXQgb2ZmaWNlIGFuZCBpbiBpbnRlcm5hdGlvbmFs IHByb2plY3RzIGFzIA0KYmFja2JvbmVzIG9mIHJlbGF0aXZlbHkgYmlnIGFuZCBmZWRlcmF0 ZWQgU1NPIHN5c3RlbXMsIGFuZCBpdCB3b3JrcyBmaW5lLg0KDQpJdCdzIG5vdCB2ZXJ5IGhh cmQgdG8gZGVwbG95IGFuZCBjb25maWd1cmUgb24gYmFyZSBtZXRhbC4gRW5hYmxpbmcgaXRz IA0Kb3duIEhUVFBTL1NTTCBmZWF0dXJlcyBhcmUgYWxzbyByZWxhdGl2ZWx5IHN0cmFpZ2h0 Zm9yd2FyZC4NCg0KSSdtIHN1cmUgdGhhdCBpdCBjYW4gaGFuZGxlIGEgcHJvamVjdCBhdCB0 aGUgc2l6ZSBvZiBEZWJpYW4uIEl0IGhhbmRsZXMgDQp0cmFmZmljIGZyb20gaGFsZiBvZiBF VSAoYXMgYSBwYXJ0IG9mIEVHSSBTU08gaW5mcmFzdHJ1Y3R1cmUpIGp1c3QgZmluZS4NCg0K Q2hlZXJzLA0KDQpIYWthbg0KDQpPbiAxNy4xMC4yMDIyIDEwOjE0LCBTdGVwaGFuIExhY2hu aXQgd3JvdGU6DQo+IE9uIFN1biwgT2N0IDE2LCAyMDIyIGF0IDc6MjMgUE0gRW5yaWNvIFpp bmkgPGVucmljb0BlbnJpY296aW5pLm9yZz4gd3JvdGU6DQo+Pg0KPj4gSSB3b3VsZCB3ZWxj b21lIGJldHRlciBzaW5nbGUgc2lnbi1vbiBzeXN0ZW1zIGZvciBEZWJpYW4gdGhhbiBTYWxz YSwgYW5kDQo+PiBzc28uZGViaWFuLm9yZyBpcyBub3QgaXQuDQo+IA0KPiBJIHRoaW5rIEtl eWNsb2FrIFsxXSBpcyBxdWl0ZSBuaWNlIGFuZCB1c2VkIG1vcmUgYW5kIG1vcmUgYnkgb3Ro ZXINCj4gRk9TUyBwcm9qZWN0cyAoaXQgaXMgUmVkSGF0IHNwb25zb3JlZCBhZnRlciBhbGwp LiBPcGluaW9ucyBhYm91dCB1c2luZw0KPiB0aGlzIGFzIHBvdGVudGlhbCBTU08/IENhbiBi ZSBlYXNpbHkgaW50ZWdyYXRlZCB0byBTYWxzYS9HaXRsYWIgYXMNCj4gd2VsbCAocGFja2Fn aW5nIG1pZ2h0IG5vdCBiZSBlYXN5IHRob3VnaCkuDQo+IA0KPiBDaGVlcnMsDQo+IFN0ZXBo YW4NCj4gDQo+IFsxXTogaHR0cHM6Ly93d3cua2V5Y2xvYWsub3JnLw0K

--------------FNbI0eBdTZtuJA5kzhwk58pb--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEULItFeESq+SJGkXo3mItzvCdB5wFAmNNF8wACgkQ3mItzvCd B5x/SRAAmwuhb1QwTOMRJ/IeGJyaKbHwUL/oaadFjUQg2cBDTbqZFyUCdHHgVl9k txEKmUTo2u7VSdeMHMqiHQMrb3rxgrpMBqm86Y+/I8WWDyJ+oD0ORvShCvKJFBun Dtlmy213OHDjo5AFjDPirM1qWaI1IYgL43tEhBewPdOILfxzOILEERj0x/gXIJ5c NF1ZMGi6AWm+vSE9RWSFAR2Sw8t6bD+j0q6c5hHIM4OlbVZcf7L7oak9H85rhuEE sVdk6bUtOB6nRQ+samb4mtVa4AsbTfPkB5/4RrD+Cu70aWPPoPxLeiYpff7g22sb HAGrrsM3h3SzMBoGexVW0madpWQPSV4siantrLvGdsZUeFgFiV5Btno5iiEV94Yf qvILZR493xCsYWumJUGGb1r9g9QyxuxqJ93nhB5VvDB4MissV72GTxrvKiBbmHsb lJN6E3hQ6aUeHN+ckqjk8q9lyF5FqhD/8wojNg2DCCPOqGHQqnjOcx1lNBhh1Jfc K/52I6iWP/pjAnfIuI3baf5MQP7MwlolP9ZE6feX5dcwAh9iOAl4JI+xEBI/Cy71 6QdYEc5dbR3xJeweUekQ6mCDSxpp2zb2PZObq75mREV5bgRkXFXyCzy9BpZJZ9dZ G7wFflx6a/8Xs1w5+7ef4ZPcfdRfdmlrIvJJWe8KwS8lUhB4pKk=
=12+U
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Oct 16, 2022 at 07:22:28PM +0200, Enrico Zini wrote:

I'm posting this to debian-devel as an early heads-up and a call for
other maintainers. If nobody steps in my the end of October, I'll post a proper sunset announce to debian-devel-announce.

Everyone coming up with solutions, please review the old thread about
that
https://lists.debian.org/msgid-search/20200405184610.GA581270@waldi.eu.org

Regards,
Bastian

--
What kind of love is that? Not to be loved; never to have shown love.
-- Commissioner Nancy Hedford, "Metamorphosis",
stardate 3219.8

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank <waldi@debian.org> wrote:

Everyone coming up with solutions, please review the old thread about
that https://lists.debian.org/msgid-search/20200405184610.GA581270@waldi.eu.org

Keycloak also provides OpenID Connect / OAuth2 and can connect to LDAP
servers - so it is not really "intrusive" in that sense. For websites
using the SSO the switch would probably just changing a URL, which of
course opens the question what the advantage of Keycloak over the
current Gitlab based solution would be. I guess Keycloak integrates
better to LDAP and has more user management tools, but that doesn't
mean the work is worth it. I just wanted to point out a solution in
case we want a new SSO.

Cheers,
Stephan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 17 octobre 2022 13:50:36 GMT+02:00, Stephan Lachnit <stephanlachnit@debian.org> a écrit :

On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank <waldi@debian.org> wrote:

Everyone coming up with solutions, please review the old thread about
that
https://lists.debian.org/msgid-search/20200405184610.GA581270@waldi.eu.org

Keycloak also provides OpenID Connect / OAuth2 and can connect to LDAP >servers - so it is not really "intrusive" in that sense. For websites
using the SSO the switch would probably just changing a URL, which of
course opens the question what the advantage of Keycloak over the
current Gitlab based solution would be. I guess Keycloak integrates
better to LDAP and has more user management tools, but that doesn't
mean the work is worth it. I just wanted to point out a solution in
case we want a new SSO.

Cheers,
Stephan

Hi,

Also lemonldap-ng, already packaged

Cheers,
Yadd
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Stephan" == Stephan Lachnit <stephanlachnit@debian.org> writes:

Stephan> On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank <waldi@debian.org> wrote:
>>
>> Everyone coming up with solutions, please review the old thread
>> about that
>> https://lists.debian.org/msgid-search/20200405184610.GA581270@waldi.eu.org

Stephan> Keycloak also provides OpenID Connect / OAuth2 and can
Stephan> connect to LDAP servers - so it is not really "intrusive"
Stephan> in that sense. For websites using the SSO the switch would
Stephan> probably just changing a URL, which of course opens the
Stephan> question what the advantage of Keycloak over the current
Stephan> Gitlab based solution would be. I guess Keycloak integrates
Stephan> better to LDAP and has more user management tools, but that
Stephan> doesn't mean the work is worth it. I just wanted to point
Stephan> out a solution in case we want a new SSO.

Okay, that's all great and stuff, but I'm not sure it solves the problem
we have.

Today, we have:

* Some services using salsa for sso
* tracker using client certs
* The source of client certs going away unless someone steps up to
maintain it.

* Like enrico, I think sso.debian.org's time has passed, and I don't
think stepping up to keep it alive advances anything.

You propose adding keycloak.

That
* Gives us a second source of sso
* still leaves tracker wanting to consume client certs
* As far as I can tell keycloak can consume but not produce client certs
* Even if it can produce client certs we have all the usability
challenges of client certs

I think the minimal solution here, which I'm not volunteering to do, is
for tracker.debian.org to gain salsa sso support instead of client cert support.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16654 March 1977, Sam Hartman wrote:

I think the minimal solution here, which I'm not volunteering to do,
is
for tracker.debian.org to gain salsa sso support instead of client
cert
support.

But that isnt neccessarily the best solution. I think it would be better
to NOT rely on salsa for SSO.
Salsa should be there for git (related) things. NOT as an identity/login provider for Debian, that is a different task.

--
bye, Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17.10.22 17:29, Sam Hartman wrote:

That
* Gives us a second source of sso
* still leaves tracker wanting to consume client certs
* As far as I can tell keycloak can consume but not produce client certs
* Even if it can produce client certs we have all the usability
challenges of client certs

But is there a technical reason for tracker.d.o to do client certs in
the first place? It's easy for a first-party d.o service running on DSA machines to enable OpenID Connect-based SSO against Salsa. And that only requires minor changes to the code to get the username from the slightly different HTTP header.

If there are API clients talking to it, it might be slightly more
involving to setup - but it's not like other people haven't had to deal
with getting OIDC tokens for various APIs before. :)

Kind regards
Philipp Kern

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 2022-10-17 at 21:28 +0200, Joerg Jaspert wrote:

Salsa should be there for git (related) things.
NOT as an identity/login provider for Debian

There are already Debian services that do not offer any other option
for auth than Salsa.

Personally I do not like GitLab, Salsa nor OIDC/Oauth2, vastly prefer
TLS client certs and thus usually never use Salsa authed services.

Arguably it is probably a good thing to use Salsa, since it means
services can have an auth option for all of the Debian contributors,
including those who are not currently DDs or DMs.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmNOFOUACgkQMRa6Xp/6 aaNSug//UPEmn4ghohVdU0+r52RcEXNOKS+Ok12CzqlTHBWC61lxJ8H6ge2g2xlS zCgDxD48r1VqhB22dYiK9pfVP0Maz5dZphKPn82AaG8L5TeGGQEDnx+9JJ244MeV Spf8FrzVoMicEIvGlg3mCjqdRjuvDyBubZrE7c4n4ddiWBm8gn0m4gCXsVcbDtbc 2bRJm4Vv3DW7SRcMnxJomGqO1hnGArLPxQxZlIOdQS1wqkxlDtvF6hFiWCPD3ggZ bcGL+m03MJXpkS9tHM+G67j63kGFXVJP5iUnX4zOp6XxzrLZiLXh1nuKPTir/hB4 QNtFB/IhMg5/AT9G9YZwpAkUYXT4kzp6ypc744GEkrcNCC+JFWVp5O4nAFohQJu2 taRGIbK+zsTr0Bh8DwP9MJS9gfWLhvQCU2ZsUieCdLH8L+QoqPHL774Y3Znr5PM2 MaZKvHMzPKfyUAbSIyV1/n83r/ZP7AYvSt9AhyIemuvw72UXH2RcwegUbREo4LWm P+15Apq0jGHdKPCncvxHgCc6xD2zQrVDGG0kseJe0knDHc6mTY9q4rdqIYGhZczq sI+z1yvSaq1gjPFnMtPqIZUYediplb4JBcn8MwU52rPVkSRkuHgKcyE80NPG6hrK oQcciPEp1cWEiKZrd5AxmxT2XUhLUyMV9MjVwwb1f6fB74sbvfY=
=tDGU
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Oct 17, 2022 at 5:29 PM Sam Hartman <hartmans@debian.org> wrote:

I think the minimal solution here, which I'm not volunteering to do, is
for tracker.debian.org to gain salsa sso support instead of client cert support.

Can point out the tracker.d.o code? Maybe I'll take a look, I find this topic interesting (but I can't promising anything - short on time and never done stuff like this before).


On Tue, Oct 18, 2022 at 4:53 AM Paul Wise <pabs@debian.org> wrote:

On Mon, 2022-10-17 at 21:28 +0200, Joerg Jaspert wrote:

Salsa should be there for git (related) things.
NOT as an identity/login provider for Debian

There are already Debian services that do not offer any other option
for auth than Salsa.

Personally I do not like GitLab, Salsa nor OIDC/Oauth2, vastly prefer
TLS client certs and thus usually never use Salsa authed services.

Arguably it is probably a good thing to use Salsa, since it means
services can have an auth option for all of the Debian contributors, including those who are not currently DDs or DMs.

I think this more an argument against Salsa than one for it - just having a Salsa account does not really put you into any "box" except whether you are part of the Debian group or not. Having a "proper" SSO that connects to db.d.o and has proper groups such as DD, non-uploading DD, DM, etc is not a bad idea. Again, not saying that it is worth the effort.


On Mon, Oct 17, 2022 at 2:04 PM Yadd <yadd@debian.org> wrote:

Also lemonldap-ng, already packaged

Cool, didn't know that one, thanks for pointing out. Do you by any chance know whether it supports client certs or not? Since it seems there are ppl
prefering client certs, it would be nice to have an option that supports both.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Oct 18, 2022 at 11:20:10AM +0200, Joerg Jaspert wrote:

Am 2022-10-18 04:52, schrieb Paul Wise:

Salsa should be there for git (related) things.
NOT as an identity/login provider for Debian

Please formally retract the agreement that was forged two years ago
then. I properly referenced it already. Until then, it still is an
identity provider.

No, it is a bad, not a good thing, to use Salsa for this.
Salsa is a "repository service" with some added nice features related to them. It is good at that, yay. Fine.

No, it is much more then a repository system.

Salsa is really bad as an identity/authentication service. Having a salsa account does NOT mean ANYTHING related to Debian, like DM/DD/whatever.

It is an identity provider, yes. It provides a fixed identity.
Further information are optional. Where are they required?

And thats information that such a service ought to provide too.

This is the Debian LDAP.

It also does not allow any kind of useful management of identities besides "the account is there/blocked/deleted". And so, as soon as you would want to NOT allow someone a login to a service that uses salsa as a login service - you need
to delete their account. Including their repositories and abilities there. Not good.

When exactly do you want to do that and how would that work?

Bastian

--
Women are more easily and more deeply terrified ... generating more
sheer horror than the male of the species.
-- Spock, "Wolf in the Fold", stardate 3615.4

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 2022-10-18 04:52, schrieb Paul Wise:

Salsa should be there for git (related) things.
NOT as an identity/login provider for Debian

There are already Debian services that do not offer any other option
for auth than Salsa.

Which is bad. And should be changed.

Arguably it is probably a good thing to use Salsa, since it means
services can have an auth option for all of the Debian contributors, including those who are not currently DDs or DMs.

No, it is a bad, not a good thing, to use Salsa for this.
Salsa is a "repository service" with some added nice features related to
them. It is good at that, yay. Fine.

Salsa is really bad as an identity/authentication service. Having a
salsa account does NOT mean ANYTHING related to Debian, like
DM/DD/whatever. And thats information that such a service ought to
provide too. It also does not allow any kind of useful management of
identities besides "the account is there/blocked/deleted". And so, as
soon as you would want to NOT allow someone a login to a service that
uses salsa as a login service - you need to delete their account.
Including their repositories and abilities there. Not good.

IMO that functionality of salsa should be deactivated *right* *now*. To
not have it get used even more.

Salsa ought to use some service for login, not the other way. Keycloak
or whatever else, doesnt matter. And that service ought to be properly integrated with NM and the DSA services.

--
bye Joerg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)