[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Salsa as authentication provider for Debian



On Thu, 9 Apr 2020 09:44:38 +0200
Enrico Zini <enrico@enricozini.org> wrote:

> On Wed, Apr 08, 2020 at 03:48:43PM +0000, Luca Filipozzi wrote:
> 
> > > If you're instead generally expressing a fear that once we migrate to
> > > Salsa, we'll be in a local optimum that is going to be considered good
> > > enough to be worth bothering migrating to anything else, then I would
> > > argue that the problem wouldn't be having moved to Salsa as an OIDC
> > > provider, and rather that the next step that is proposed wouldn't be
> > > bringing enough compelling advantages to the problem at hand.  
> > 
> > Indeed, a local optimum is worrisome.  
> 
> If you mean that we should block a workable proposal for incremental
> improvement in case it turns out to be good enough, I think I don't want
> that.

I've already mentioned a couple points that are worrisome.

It also appears that there is an intent to drop -guest naming. I haven't seen
any technical discussion about this beyond learning about the current
structure. I am very concerned that this will have significant consequences in
regard to DSA-managed LDAP.

Perhaps the -guest naming should (definitely) be retired, but that sounds like a
very different can of worms that's better opened later.

> What we have /now/ is unsustainable, to the point that I'm afraid and
> ashamed of keeping some of the services I'm responsible for online.

As mentioned, we understand this. It is a very significant issue... one that
most were unaware of and some of us (hand raised) thought was already dealt
with. It's ... ugly, at best.

> [...]
> Then we can talk about a better, long-term, technically excellent,
> actively supported and sustainable solution, and by all means, I'd like
> to see that.

I do enjoy that there is consensus on the long-term goal.

> We could also do a post-mortem of why we have had what sounded like a
> good solution for more than one year and never managed to get it
> deployed. Not for pointing fingers: for avoiding getting in such a
> stalled situation in the future.
> 
> I am not at all in the mood for any of that, though, while I find myself
> starting responding to users' requests for help by apologising for the
> state things are.

(please forgive me if this sounds terse/blunt/rude... it's not intended)
I'm concerned that this sounds a lot like tunnel-vision, where only the fastest
and easiest way out of this cruddy situation is worth considering.

FWIW, that's very understandable, especially considering just how bad the status
quo has been for the past year or so. It's truly an ugly situation and one where
I can empathize with your pain. I can also understand the motivation to find the
nearest exit and I would probably be doing the exact same thing in your shoes.


For the moment, I would love to do whatever I can to help you with user issues.
I know this isn't a substitute for fixing the problem, but perhaps I can help
ease your burden and night terrors?


Meanwhile, there are now five people with an interest in doing what we can to
rectify the situation. It's unfortunate that we weren't aware of the stall a
year ago, but we're here now, and I don't intend to work slowly. I'm confident
you're aware of my "requirements gathering" phase. Design has been roughly
discussed and I'm now taking a day to bury myself in documentation. Since I'm
still playing the social distancing game, you can probably guess where my
weekend priorities will be. :)

Cheers,
-- 
Michael Lustfield


Reply to: