On 10/19/2017 04:09 PM, Randy Barlow wrote:
> 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?
I don't think this change will affect my workflow at all. That said,
I've had this in my .bashrc for a while:
# Used by /usr/bin/bodhi at least
export FAS_USERNAME="crobinso"
And checking f25 dist-git bodhi code gives:
$ git grep USERNAME
bodhi-0.9.12.2/bodhi/tools/client.py: return
os.getenv('FAS_USERNAME', getuser())
bodhi-0.9.12.2/docs/bodhi.1:.IP "\fB\-u --username\fP USERNAME"
So indeed seems like the historical env name here is FAS_USERNAME, and
the switch to USERNAME is only in f26+ bodhi era code. I think that
changes a lot of the above dynamics. Maybe just switch the stable
branches back to FAS_USERNAME which avoids the GDM issue
Thanks,
Cole
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
