On Tue, Feb 1, 2022 at 12:16 PM Aurelien Bompard
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
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.
It also doesn't work at all if you're doing work from a remote box or
in a headless system (like Vagrant or whatever). I've tried myself,
and I've failed to pull it off.
Weirdness aside, I'm wondering if this could hurt people who may
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)
I'd like to see anything that makes this better. It would also help
for the eventual transition away from SSH for committing to Dist-Git,
as that's also blocked on the awkward workflow for HTTPS usage.
So, I have questions:
- Do any of you run the bodhi CLI on a headless server instead of on
- Do you use the --username and --password command-line switches of
- How far ahead should we warn users of this change? There's doc to update too.
I do. There's also other external clients, like Fabio Valentini's
Rust-based ones. We should check with him on how we affect that.
I don't think I can easily keep both stacks (OpenID and OIDC)
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.
Thanks for reading this far :-)
Thanks for looking into this!
真実はいつも一つ！/ Always, there's only one truth!