Greetings fellow Fedorans, We're about to release Bodhi 3.0.0[0] upstream, which has a backwards incompatible CLI change[1] that I am considering backporting to the stable Fedoras, but I wanted feedback first before I do that. The Bodhi 2 CLI will use the USERNAME environment variable when authenticating you, if present, and the Bodhi 3 CLI[3] does not use any environment variable (yet) for authentication. Here's the reasoning: * The Bodhi 2 CLI previously didn't have the ability to remember your username, but it did have the environment variable, which kind of acted like a bandaid. I believe this variable was in place before I got involved. * The CLI got a lot of love earlier this year, and one of the big things added was the ability for it to remember your username if you've ever successfully authenticated before. This feature largely removed the need for the environment variable, but keeping the variable seemed harmless at the time. * I recently learned that the variable is painful for some users, because GDM sets this variable to your local system's login username, which is not necessarily the same as your FAS username. * When the username is present, Bodhi will not prompt the user for their username, which leads to a very poor experience upon first login for GDM users who have mismatching FAS account names (Bodhi prompts for their password and then tells them it's wrong). Without the variable, Bodhi will prompt users to enter their username upon first use. * Users can currently override the USERNAME environment variable with a --user flag as a workaround. * Though it may seem that Kerberos addresses this problem, Bodhi does not use Kerberos (it uses OpenID) and there are not plans to adjust Bodhi to use Kerberos because we plan to convert it to use OpenID Connect instead. In order to address the above, and in the spirit of working quickly due to the other pressures to complete 3.0.0, it was easy enough to just drop support for this environment variable with 3.0.0, since 3.0.0 already needed other backwards incompatible changes. However, I have a few questions for the list: 0) Do you have a use case for an environment variable to set your username? If there is sufficient demand for this feature, we can add it back with a different name in a future Bodhi 3 release (perhaps BODHI_USER or FAS_USER would suffice). 1) I'd like to make a backwards incompatible patch for the stable Fedoras so that GDM users get a better experience without having to wait for Fedora 28, but I don't want to do this if it is too disruptive. Normally I am quite against backwards incompatible changes in Fedora, but this can also be viewed as a painful bug and fixing the bug might alleviate more pain than the change would cause. Would such a change be a disruption to us developers, or does the good outweigh the bad? A few options for F25-27: 0) Do nothing, and let Rawhide be the only place this change happens. 1) Drop USERNAME. 2) s/USERNAME/BODHI_USER/ or similar. Thoughts? P.S. The Bodhi 3.0 beta is also deployed to staging[2], though no user visible changes will be apparent. It's main feature is the ability to mash modules. [0] https://bodhi.stg.fedoraproject.org/docs/release_notes.html [1] https://github.com/fedora-infra/bodhi/issues/1789 [2] https://bodhi.stg.fedoraproject.org/ [3] https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi-pre-release
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
