Re: Bodhi's move to OIDC

Hey folks! A long email to give you some context, please bear with me :-) A while back, Bodhi's integration tests stopped working on the "pip" release (basically the latest python packages from PyPI). Since the integration tests were flaky at that time, they were disabled on the "pip" release. Now that the flakiness has been fixed (for now ;-) ) I've revisited why they still fail. It led me to open a bodhi ticket <https://github.com/fedora-infra/bodhi/issues/4356> that explains the situation: basically Pyramid is switching the session serializer from pickle to JSON, because pickle is pretty insecure. However, one of our dependencies, python-openid, stores an object instance in the session, and that can't be serialized to JSON. A ticket has been opened on python-openid about that in *2011*, and the last comment in 2014 states that the library is pretty much unmaintained. I think it's the final nail in Bodhi's OpenID auth coffin, we've wanted to switch to OIDC (OpenID Connect) for a long while but haven't got around to it yet. Now I don't think we can delay it much longer, as the newer versions will find their way in Fedora releases and things will stop working without horrible ad-hoc patches. I've started to convert Bodhi to OIDC, using the authlib library. The server part isn't so hard (there isn't a ready-made integration layer for Pyramid as there is for Flask and Django, but it's fine, it's not a big layer). The client however is going to be pretty different after the conversion. To log in, users won't be able to pass the login and password as they do now. When an authenticated operation is requested, the command-line client will open a browser window to ask the user to login on id.fp.o, as for web apps. After a successful login the page will say "You can now close this page and go back to bodhi". I know it looks weird to have a command-line tool open a graphical tool, but it's actually the recommended way to do things securely.

Weirdness aside, I'm wondering if this could hurt people who may run the bodhi client CLI on a headless server. The browser must be opened on the same host where the CLI is running. There could be a way around that but it would need a (minor, according to Patrick) addition to Ipsilon. (this workaround does not involve starting elinks instead)

So, I have questions: - Do any of you run the bodhi CLI on a headless server instead of on their workstation? - Do you use the --username and --password command-line switches of bodhi-client? - How far ahead should we warn users of this change? There's doc to update too.

I don't think I can easily keep both stacks (OpenID and OIDC) working simultaneously, but in the interest of ease of migration I can try, if it's worth the non-negligible effort. I think I can get this work done in the context of the Bodhi initiative this quarter. If things don't explode too big. Comments? Opinions? Thanks for reading this far :-)