On Wed, Feb 09, 2022 at 11:33:24AM +0100, Kamil Paral wrote: > However, even if Anaconda changes the bug reporting mechanism and asks the > user to create an API key first, and then provide it to Anaconda, I fear > that this will have a devastating impact on the number of bug reports that > we receive. It is quite different to fill out a username and a password > (which you already remember or have it stored, but is of a reasonable > length), from going to bugzilla (on a different computer, because your > current one is crashed during installation), creating a new api key (you > can't even display your existing ones, so you must have them stored > separately or always create a new one), and then retyping a 40-character > random string from one computer to another. Who will have the dedication to > do this "stuff"? And possibly repeatedly, in case of more crashes? (Even > we, the QA team, will hate this. You can't always easily share your > clipboard into a VM with the installation environment, or when using bare > metal, and if we have to retype a 40-character random string several times > per day, because we made the installer crash, that's going to severely > impact us on multiple levels). Using API tokens over username/password is a good thing from a security POV, but as you say, the process of creating the token and getting it over to the client is horribly user unfriendly. This feels like a similar problem space to that of signing onto a streaming service, with an app on your smart TV. In the streaming apps I've used this is quite user friendly. The (client) app displays a short unique code (presumably acquired from thue server), which is effectively a one time code to identify that client. The user logs in to the service on their laptop/tablet/mobile, does authentication in whatever way they need to (username / password or a software 2fa, or a hardware token, etc). They then just enter the unique code shown on the TV, thus associating the device with their account and the device is now automagically logged on. I'm assuming that what's going on here is that when you enter the one time identity code, the service is effectively creating an API token behind the scenes in your account, and handing that back to the TV app client. I do wonder what security people think of this kind of approach. To be a significant benefit the one time codes have to be fairly short and simple to type in on your separate browser. So there's still a tradeoff between the amount of entropy they have and the usability. In all the cases I've seen though, the codes are noticably simpler/shorter than a typical API token would be. I'm guessing the very short validity time of these one time tokens lets them get away with having less entropy, than a long lived API token needs. I've not seen this kind of auth dance implemented in any software other than TV streaming apps, and not bugzilla and not any other bug tracker I've come across. So it is not a practical solution today, more of a thought experiment on how API tokens could possibly be made less awful to acquire for something like Anaconda or Abrt. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
