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