On Wed, Jul 31, 2019 at 8:00 PM Björn Persson <Bjorn@rombobjörn.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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
