12:59 p.m.
I recently added two new packages to Fedora. Things have changed a bit
since the previous time I did this, and more things can now be done
through fedpkg. I would like to share my experience with this. This is
what the procedure is like for a volunteer who only sometimes works on
Fedora stuff:
· When the package has passed review I need to request a Git repository.
There's a handy command for that: "fedpkg request-repo". But before I
can run that I must log in to a special web interface and get an API
token that I must paste into a configuration file that I've otherwise
never heard of. This comes across as a half-baked design.
The token expires, so next time I add a package I'll have to do this
again. I won't remember the URL, nor the pathname of the file, so I'll
have to look them up every time.
· Once the repository exists I need to clone it with "fedpkg clone".
This requires SSH authentication. This is the method I like best,
partly because it uses a key encrypted with a master passphrase, so
that the passphrase I type never leaves my workstation, but also because
it's the same SSH that I use all the time, so I already know how to
manage it. SSH key management is actually rather clumsy; I'm just used
to it.
· The next step is to add files to the repository and upload the source
tarball. Again there's a handy command: "fedpkg import". But that fails
halfway through because I'm not authenticated with Kerberos. It doesn't
even ask me for a password. Instead I have to run a kinit command to
authenticate. This gives the impression that somebody completely forgot
to implement the authentication bit.
Another problem with this method is that it expects me to directly type
in the shared secret. I can't have the secret stored in a keyring
encrypted with a master passphrase.
Then I retry "fedpkg import", but that fails because of the files it
added to Git the first time, and I have to upload the tarball with
"fedpkg new-sources" instead.
· Before I build the new package I may need a buildroot override.
"fedpkg override" is the command, and it appears to use yet another
authentication method. This one is actually capable of asking for a
password. It doesn't say which password it wants, but I tried the FAS
password and it was apparently right. It even seems to cache the
password or some authentication token, because it doesn't ask again
when I request a second buildroot override.
This is better thought-out than request-repo and the various upload and
build commands, but even this method expects me to type in the shared
secret. There is no keyring option as far as I can tell.
One task, one front-end program, four different authentication methods,
each with its own idiosyncrasies. It's not even four separate accounts.
Everything hinges on the same FAS password. (Even SSH keys are managed
with the FAS password.) Why do I have to authenticate to the same
account four times in four different ways?
I'm sorry to be complaining. I know everybody has too much to do (myself
included), but seriously folks, this needs to be improved. This is not
a good user experience. I hope the plans to retire some less important
services will lead to somebody finding some time to improve the user
interface for these essential tasks.
I would think that the infrastructure team's lives would be easier with
fewer authentication protocols to worry about, but as a user I'd be
satisfied if the incoherence would be hidden behind a consistent user
interface. Here are some improvements I would like to see:
1: If the various upload and build commands could ask for the FAS
password and perform the Kerberos authentication, instead of just
giving up, then that would be a good start.
2: If the request-repo command and its relatives could ask for the FAS
password and use that to acquire their API tokens under the hood, then
that would greatly improve usability.
3: Once points 1 and 2 are done, it would be great if all commands that
need the FAS password were able to fetch it from a common keyring. The
first time the keyring program would ask me to unlock the keyring with
the master passphrase. The master passphrase wouldn't be sent anywhere;
it would only be used for decrypting the FAS password. After that the
password would be automatically fetched from the keyring each time it's
needed, just like it works with the SSH agent. That way I'd only need
to remember the master passphrase, and I wouldn't need to manually copy
the FAS password from the keyring to various password prompts.
4: If point 3 would be implemented, then the FAS password would be about
as user-friendly as an SSH key. Then, and not before, it might make
sense to use Kerberos authentication in SSH, if the Kerberos bits were
able to fetch the password from the keyring described in point 3.
5: This point is less important than the others, but it would also be
nice if Pagure would refrain from spamming me with warnings that my API
key (token, key, whatever) is about to expire and the sky is going to
fall unless I get a new one. I'm not using that token in any
"non-interrupted service". I'll get a new token next time I add a new
package, which may be years from now, if that system is still in use by
then.
Björn Persson
1:20 p.m.
On Wed, Jul 31, 2019 at 8:00 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
I recently added two new packages to Fedora. Things have changed a bit
since the previous time I did this, and more things can now be done
through fedpkg. I would like to share my experience with this. This is
what the procedure is like for a volunteer who only sometimes works on
Fedora stuff:
Even as someone who contributes to fedora on an almost daily basis,
these are some things that confuse me from time to time.
· When the package has passed review I need to request a Git
repository.
There's a handy command for that: "fedpkg request-repo". But before I
can run that I must log in to a special web interface and get an API
token that I must paste into a configuration file that I've otherwise
never heard of. This comes across as a half-baked design.
The token expires, so next time I add a package I'll have to do this
again. I won't remember the URL, nor the pathname of the file, so I'll
have to look them up every time.
This is because pagure handles authenticated requests via an API token.
In this case, access with the API token is required to be able to
create a new ticket for the "new repository queue".
· Once the repository exists I need to clone it with "fedpkg
clone".
This requires SSH authentication. This is the method I like best,
partly because it uses a key encrypted with a master passphrase, so
that the passphrase I type never leaves my workstation, but also because
it's the same SSH that I use all the time, so I already know how to
manage it. SSH key management is actually rather clumsy; I'm just used
to it.
· The next step is to add files to the repository and upload the source
tarball. Again there's a handy command: "fedpkg import". But that fails
halfway through because I'm not authenticated with Kerberos. It doesn't
even ask me for a password. Instead I have to run a kinit command to
authenticate. This gives the impression that somebody completely forgot
to implement the authentication bit.
I think this is caused by the upload to the lookaside cache using curl
with kerberos authentication.
Another problem with this method is that it expects me to directly
type
in the shared secret. I can't have the secret stored in a keyring
encrypted with a master passphrase.
You can add your "kerberos account" to GNOME online accounts once, and
it will automatically renew tickets for you.
This way you'll never have to type your FAS password (or run kinit)
for this again.
Then I retry "fedpkg import", but that fails because of the
files it
added to Git the first time, and I have to upload the tarball with
"fedpkg new-sources" instead.
· Before I build the new package I may need a buildroot override.
"fedpkg override" is the command, and it appears to use yet another
authentication method. This one is actually capable of asking for a
password. It doesn't say which password it wants, but I tried the FAS
password and it was apparently right. It even seems to cache the
password or some authentication token, because it doesn't ask again
when I request a second buildroot override.
This is because creating an override uses the bodhi python client bindings.
bodhi uses OpenID for authentication, so that's FAS username and FAS password.
The bodhi client bindings use openid authentication from the "fedora"
python package, which does some limited amount of credentials / cookie
caching on disk, which is why you don't have to authenticate with
password every time.
This is better thought-out than request-repo and the various upload
and
build commands, but even this method expects me to type in the shared
secret. There is no keyring option as far as I can tell.
One task, one front-end program, four different authentication methods,
each with its own idiosyncrasies. It's not even four separate accounts.
Everything hinges on the same FAS password. (Even SSH keys are managed
with the FAS password.) Why do I have to authenticate to the same
account four times in four different ways?
As far as I can tell, that's because it calls different web services
in the background, which use different authentication mechanisms.
I'm sorry to be complaining. I know everybody has too much to do
(myself
included), but seriously folks, this needs to be improved. This is not
a good user experience. I hope the plans to retire some less important
services will lead to somebody finding some time to improve the user
interface for these essential tasks.
I think there's an active effort to use OpenID Connect authentication
for more services (at least for bodhi).
I would think that the infrastructure team's lives would be
easier with
fewer authentication protocols to worry about, but as a user I'd be
satisfied if the incoherence would be hidden behind a consistent user
interface. Here are some improvements I would like to see:
1: If the various upload and build commands could ask for the FAS
password and perform the Kerberos authentication, instead of just
giving up, then that would be a good start.
2: If the request-repo command and its relatives could ask for the FAS
password and use that to acquire their API tokens under the hood, then
that would greatly improve usability.
3: Once points 1 and 2 are done, it would be great if all commands that
need the FAS password were able to fetch it from a common keyring. The
first time the keyring program would ask me to unlock the keyring with
the master passphrase. The master passphrase wouldn't be sent anywhere;
it would only be used for decrypting the FAS password. After that the
password would be automatically fetched from the keyring each time it's
needed, just like it works with the SSH agent. That way I'd only need
to remember the master passphrase, and I wouldn't need to manually copy
the FAS password from the keyring to various password prompts.
4: If point 3 would be implemented, then the FAS password would be about
as user-friendly as an SSH key. Then, and not before, it might make
sense to use Kerberos authentication in SSH, if the Kerberos bits were
able to fetch the password from the keyring described in point 3.
5: This point is less important than the others, but it would also be
nice if Pagure would refrain from spamming me with warnings that my API
key (token, key, whatever) is about to expire and the sky is going to
fall unless I get a new one. I'm not using that token in any
"non-interrupted service". I'll get a new token next time I add a new
package, which may be years from now, if that system is still in use by
then.
Björn Persson
I've been working on rust bindings for some fedora services, and this
is as far as I got with all the different, partly non-standard
authentication mechanisms.
Somebody please correct me if I wrote something that's wrong.
Fabio
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/devel@lists.fedoraproject.org
2:16 p.m.
Fabio Valentini wrote:
You can add your "kerberos account" to GNOME online accounts
once, and
it will automatically renew tickets for you.
This way you'll never have to type your FAS password (or run kinit)
for this again.
First, I don't use Gnome 3 because a software engineer's workstation has
other needs than a hand-held Facebook terminal.
Second, As I understand what I've been told about Gnome Online Accounts,
it would keep me constantly logged in to Fedora servers as long as I'm
logged in to my workstation. That's appropriate for a corporate network
or a university campus, which I suppose is what Kerberos is designed
for. It's not appropriate for a project that I sometimes contribute to
when I have time and when something needs doing.
Fedora needs an authentication method that authenticates on demand, not
proactively, using a keyring that isn't tied to a single desktop.
Björn Persson
2:45 p.m.
On 7/31/19 12:16 PM, Björn Persson wrote:
Fabio Valentini wrote:
> You can add your "kerberos account" to GNOME online accounts once, and
> it will automatically renew tickets for you.
> This way you'll never have to type your FAS password (or run kinit)
> for this again.
First, I don't use Gnome 3 because a software engineer's workstation has
other needs than a hand-held Facebook terminal.
Did you really have to include this? A simple 'I'm sorry, I don't use
Gnome' would have been fine...
Second, As I understand what I've been told about Gnome Online Accounts,
it would keep me constantly logged in to Fedora servers as long as I'm
logged in to my workstation. That's appropriate for a corporate network
or a university campus, which I suppose is what Kerberos is designed
for. It's not appropriate for a project that I sometimes contribute to
when I have time and when something needs doing.
Fedora needs an authentication method that authenticates on demand, not
proactively, using a keyring that isn't tied to a single desktop.
Things are moving (all be it slowly) toward OIDC.
Sorry they are all over the place right now...
kevin
2:48 p.m.
On Wed, Jul 31, 2019 at 3:46 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On 7/31/19 12:16 PM, Björn Persson wrote:
> Fabio Valentini wrote:
>> You can add your "kerberos account" to GNOME online accounts once,
and
>> it will automatically renew tickets for you.
>> This way you'll never have to type your FAS password (or run kinit)
>> for this again.
>
> First, I don't use Gnome 3 because a software engineer's workstation has
> other needs than a hand-held Facebook terminal.
Did you really have to include this? A simple 'I'm sorry, I don't use
Gnome' would have been fine...
>
> Second, As I understand what I've been told about Gnome Online Accounts,
> it would keep me constantly logged in to Fedora servers as long as I'm
> logged in to my workstation. That's appropriate for a corporate network
> or a university campus, which I suppose is what Kerberos is designed
> for. It's not appropriate for a project that I sometimes contribute to
> when I have time and when something needs doing.
>
> Fedora needs an authentication method that authenticates on demand, not
> proactively, using a keyring that isn't tied to a single desktop.
Things are moving (all be it slowly) toward OIDC.
Are we talking about OIDC like how Bodhi does it or like how fedpkg
https auth does it?
Because the latter is pretty difficult to use when you're in a server
environment. :(
Sorry they are all over the place right now...
We'll eventually get there...
--
真実はいつも一つ！/ Always, there's only one truth!
2:32 p.m.
On Wed, 31 Jul 2019 at 14:00, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
I'm sorry to be complaining. I know everybody has too much to do (myself
included), but seriously folks, this needs to be improved. This is not
a good user experience. I hope the plans to retire some less important
services will lead to somebody finding some time to improve the user
interface for these essential tasks.
FAS has been on the block to replace/fix for over 10 years. Changes in
authentication methods require a lot of dedicated work because it affects
all workflows somewhere.. and because it would mean so much downtime.. it
has never gotten the resources in time and engineers to do. Even taking
someone else's existing solution and using it requires rewriting a lot of
tools to get it to work consistently. It also sometimes means something we
could do before is gone. So instead we have had to jury rig in a new method
each time a service comes in.. all in the hopes that next year we can get
the replacement.
I would love that I could wave a magic wand and fix this.. but I would have
done that any time in the last 10 years.
--
Stephen J Smoogen.
2:51 a.m.
Stephen John Smoogen wrote:
Changes in
authentication methods require a lot of dedicated work because it affects
all workflows somewhere.. and because it would mean so much downtime.. it
has never gotten the resources in time and engineers to do.
Obviously replacing an authentication protocol is a big change that
affects many things, but some smaller improvements could make the user
interface suck less. Asking for a password instead of just failing is
an isolated client-side change. It would take some programming work of
course, but little or no coordination between different components.
Authenticating in advance with kinit would continue to work, so nobody's
workflow would break.
Björn Persson
8:01 a.m.
On Thu, 1 Aug 2019 at 03:52, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
Stephen John Smoogen wrote:
>Changes in
>authentication methods require a lot of dedicated work because it affects
>all workflows somewhere.. and because it would mean so much downtime.. it
>has never gotten the resources in time and engineers to do.
Obviously replacing an authentication protocol is a big change that
affects many things, but some smaller improvements could make the user
interface suck less. Asking for a password instead of just failing is
an isolated client-side change. It would take some programming work of
course, but little or no coordination between different components.
I think we are talking about different things. I am talking about fixing
the backend to make it so fedpkg can authenticate easier. You are talking
about having fedpkg talk to a non-working 80% api backend. The fedpkg could
ask for a password.. it could also fail regularly spectacularly because the
backend wasn't meant to deal with that but was hacked together to sort of
work like that. So to make the front end have a better user experience..
you need to make the backend work consistently. [Even the kerberos side you
mention is not really tied into authentication easily.. but is done through
a set of clever programming to make disparate tools work together.]
Authenticating in advance with kinit would continue to work, so
nobody's
workflow would break.
Björn Persson
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
1729
days inactive
1730
days old
7 comments
5 participants
participants (5)
-
Björn Persson -
Fabio Valentini -
Kevin Fenzi -
Neal Gompa -
Stephen John Smoogen