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 :-)
Aurélien
On Tue, Feb 1, 2022 at 12:16 PM Aurelien Bompard abompard@fedoraproject.org wrote:
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.
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 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)
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
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 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) 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 :-)
Thanks for looking into this!
On Tue, Feb 1, 2022 at 12:16 PM Aurelien Bompard <abompard(a)fedoraproject.org> wrote:
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.
Hi,
Sorry if this response looks weird, I'm using hyperkitty web interface to respond inline since I was not subscribed to this list yet. (And thanks to Neal for CCing me in his response.)
But yeah, making it impossible to use the bodhi cli without opening a web browser for authentication would be bad for my use cases / my projects - particularly fedora-update-feedback. If I need to open a web browser for authentication, I can just use it to submit bodhi feedback as well, and then why use a CLI app?
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.
While there's apparently Rust libraries that could handle OpenID connect stuff for me, I'd need to look into how they handle the authentication flow, i.e. if they require opening a web browser too. It would also require rewriting the whole lower layer of my Rust bodhi API bindings / fedora-update-feedback *again*, because I *just today* finished the transition onto async / await and released versions 2.0.0 of those projects ...
So if there's any transition period, that would be greatly appreciated, since I will need time (and that's not growing on trees nowadays) to adapt my projects.
Fabio
But yeah, making it impossible to use the bodhi cli without opening a web browser for authentication would be bad for my use cases / my projects - particularly fedora-update-feedback. If I need to open a web browser for authentication, I can just use it to submit bodhi feedback as well, and then why use a CLI app?
Ah, I wasn't clear. In the OIDC flow, you need to open a web browser the first time you use the CLI, then the token is saved and you don't need to do that anymore.
While there's apparently Rust libraries that could handle OpenID connect stuff for me, I'd need to look into how they handle the authentication flow, i.e. if they require opening a web browser too. It would also require rewriting the whole lower layer of my Rust bodhi API bindings / fedora-update-feedback *again*, because I *just today* finished the transition onto async / await and released versions 2.0.0 of those projects ...
Ah, sorry about that. If the OpenID Connect libraries are not practical or async-enabled, you can probably use the OAuth2 libraries, since OpenID Connect is mainly a discovery layer on top of OAuth2. You'll need to specify 3 URLs instead of discovering them based on one, but the rest should work the same.
So if there's any transition period, that would be greatly appreciated, since I will need time (and that's not growing on trees nowadays) to adapt my projects.
I think we can at least keep the OIDC-enabled instance in staging for a while, when prod would still be running on OpenID, so you can test your clients.
Hope that helps
Aurélien
On Tue, Feb 01, 2022 at 06:15:59PM +0100, Aurelien Bompard wrote:
Hey folks!
...snip background...
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)
I think the workaround might be welcome here for these people who do hit this case. Or documentation on how to run it on a workstation with a local browser and move/copy the token to the headless place?
So, I have questions:
- Do any of you run the bodhi CLI on a headless server instead of on
their workstation?
Yes. bodhi-backend01. ;) ie, we need to make sure releng can auth to do pushes still and the automated cron that does pushes still works.
- 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 think once we have a really good idea of what we are going to change and the workarounds, etc we should announce it then.
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 :-)
Thanks for heading this up... I guess once this is done, our only openid app left will be pagure?
kevin
On Tue, 2022-02-01 at 11:17 -0800, Kevin Fenzi wrote:
On Tue, Feb 01, 2022 at 06:15:59PM +0100, Aurelien Bompard wrote:
Hey folks!
...snip background...
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)
I think the workaround might be welcome here for these people who do hit this case. Or documentation on how to run it on a workstation with a local browser and move/copy the token to the headless place?
So, I have questions:
- Do any of you run the bodhi CLI on a headless server instead of on
their workstation?
Yes. bodhi-backend01. ;) ie, we need to make sure releng can auth to do pushes still and the automated cron that does pushes still works.
Isn't the 'workaround' for cases like this just to issue a non-expiring token? That's what we do for e.g. things in infra that need to edit the wiki...
On Tue, Feb 01, 2022 at 11:31:35AM -0800, Adam Williamson wrote:
On Tue, 2022-02-01 at 11:17 -0800, Kevin Fenzi wrote:
On Tue, Feb 01, 2022 at 06:15:59PM +0100, Aurelien Bompard wrote:
Hey folks!
...snip background...
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)
I think the workaround might be welcome here for these people who do hit this case. Or documentation on how to run it on a workstation with a local browser and move/copy the token to the headless place?
So, I have questions:
- Do any of you run the bodhi CLI on a headless server instead of on
their workstation?
Yes. bodhi-backend01. ;) ie, we need to make sure releng can auth to do pushes still and the automated cron that does pushes still works.
Isn't the 'workaround' for cases like this just to issue a non-expiring token? That's what we do for e.g. things in infra that need to edit the wiki...
yeah, but we need to make sure that works.
kevin
On Wed, 2 Feb 2022 at 05:20, Kevin Fenzi kevin@scrye.com wrote:
On Tue, Feb 01, 2022 at 06:15:59PM +0100, Aurelien Bompard wrote:
Hey folks!
...snip background...
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)
I think the workaround might be welcome here for these people who do hit this case. Or documentation on how to run it on a workstation with a local browser and move/copy the token to the headless place?
So, I have questions:
- Do any of you run the bodhi CLI on a headless server instead of on
their workstation?
Yes. bodhi-backend01. ;) ie, we need to make sure releng can auth to do pushes still and the automated cron that does pushes still works.
- 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 think once we have a really good idea of what we are going to change and the workarounds, etc we should announce it then.
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 :-)
Thanks for heading this up... I guess once this is done, our only openid app left will be pagure?
This ticket is mostly up to date with the status (other than what is in this thread)
https://pagure.io/fedora-infrastructure/issue/10241
—ryanlerch
kevin _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Feb 1, 2022 at 6:19 PM Aurelien Bompard abompard@fedoraproject.org wrote:
Hey folks!
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.
Yup, packit has a CLI workflow and a headless workflow (to create updates automatically if user wishes to do that).
Sorry for a late reply, noticed this email just now.
Tomas
Aurélien
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
infrastructure@lists.fedoraproject.org