LWN's unreliable predictions for 2022

Posted Jan 6, 2022 22:55 UTC (Thu) by Creideiki (subscriber, #38747)
In reply to: LWN's unreliable predictions for 2022 by KJ7RRV
Parent article: LWN's unreliable predictions for 2022

Gitea just received funding from NLnet to further the development of federation features, so maybe we'll see something despite the demise of the original ForgeFed project.

LWN's unreliable predictions for 2022

Posted Jan 11, 2022 1:05 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

I'd be happy if they would just make the existing federated login in Gitea usable, so people could roam between self-hosted repository services without making a gazillion accounts. WTF is a "OAuth2 client key" and why do I have to configure one per remote host, and for that matter why do I have to manually configure each remote host allowed to log in? Do I just make something up in that field? Do I have to go around bothering other sysadmins for this info? (that'd be a deal killer)

This stuff was so much easier to understand back in the OpenID days, but nobody implements providers for that any more because it got squeezed out by this enterprise headache. Of course the protocol's over-engineered on purpose to kill off small-scale participation on the web, but even the software I'm *using* that speaks both ends of it can't talk to each other.

LWN's unreliable predictions for 2022

Posted Jan 11, 2022 1:23 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Ah, OAuth2. Basically, service providers got unhappy that users were using Any Client instead of the Blessed Client™ (which has ads, tracking, and other "fun" enterprise-y things embedded). So OAuth2 has the idea of authenticating a *client* to the service. Users then allow that client to access the service on their behalf. I agree that this does indeed have security benefits including:

- scraping account auth isn't useful as the other client also needs the client secret (though this is a DRM-ish thing in that "fat" clients have the secret embedded somewhere anyways)
- limiting access to the account through specific services (instead of "app passwords" which generally are full account access)
- generally better permission lockdowns (though this isn't exclusive, "no one" implements app password-based limited access)

However, it means that FOSS apps are SOL and users must instead register their copy as a separate client because…the client secret has to come from somewhere and it's not very secret in a public repo (GitHub or F-Droid). FWIW, this has worked for me with Google's enterprise account, but I couldn't find how to register an app with my free account (e.g., for use with `offlineimap` or `rclone`).

Now I have no idea how the Gitea federation stuff is in practice, but if that's any indication, expect pain and suffering when you have to register as a "new app" at each service manually.