On Tue, Feb 1, 2022 at 3:30 AM Jeff Fearn <jfearn@xxxxxxxxxx> wrote:
Tl;dr From Monday 28th February, applications making API calls to
Bugzilla may no longer authenticate using passwords or supplying API
keys in call parameters. Instead, API keys must be supplied in the
Authorization header.
Support for using the Authorization header has been deployed to all Red
Hat Bugzilla instances. You can change your code at any time and not
have to wait for the old methods to be disabled.
We will require all authenticated API usage to use this new method; this
will break API access to Red Hat Bugzilla for any tools that don't use
the Authorization header [1].
If you are not certain your tooling authenticates using this header then
you need to take action to confirm it does and to modify your tooling to
use it if it doesn't.
This new method does away with logging in and out of the API and uses
API_KEYs in a standard Authorization header. This header needs to be
sent with every call to the API.
The old methods will be disabled on a rolling basis across the RHBZ servers.
Target Dates:
https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC
https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC
initially I (and not just me) read the email as "update to the latest python-bugzilla and you'll be fine". But after I played with bugzilla.stage, and read the announcement more carefully, it seems that the only possible authentication method is now using the bugzilla api key, i.e. using the username + password login is no longer possible (for API access). Is that correct?
I do have several concerns regarding that. The change seems too sudden and a lot of Fedora tooling interacts with bugzilla. Even worse, there are some tools which will get downright broken or massively impacted with no option to fix that. The first one that comes to mind is the Anaconda installer. If there's a crash during installation, it asks the user for username+password bugzilla credentials to report a bug. This can't get fixed for F35, because the installer images are already created, there is no update mechanism. So we'll lose all installer bug reports (unless reported manually) starting Feb 28th. This could be improved in F36, which is currently scheduled for a release on April 19th.
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).
This same issue is shared with Fedora's crash reporting tool, ABRT. Any time something crashes on the desktop, the user is suggested to submit a bug report. Instead of providing the username+password, the user will have to go through the api key creation motions. But at least this time the api key can be remembered by ABRT. But again I fear we'll lose a considerable amount of bug reports. Instead of removing obstacles, we're adding them. And as before, the change is too sudden, the ABRT team might not be able to react in time and we'll lose all bug reports starting Feb 28th.
So, basically two questions:
1. Why are we given so little time to react? Can this change wait at least until F36 is released (around the end of April), so that the Anaconda and ABRT teams (as well as others) can incorporate the changes?
2. Is there a good enough justification for completely banning username+password authentication? Because this will have a strong impact on Fedora quality by reducing the amount of crash reports which we receive, I can't imagine it any other way.
PS: This is also sent to the Fedora devel list, I hope you can reply there as well. It can be done from the web interface, if you prefer [1].
Thanks,
Kamil Páral
Fedora QE
_______________________________________________ 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
