Fedora: Inaccurate and apparently-unsupervised actions by agentic AI system under your control
Hi, Nathan. I'm CCing devel@ and test@ so folks are aware this has been going on.
It came to my attention this morning that you appear to be using some kind of agentic AI system to try and resolve Fedora bugs. It's great that you're trying to fix things, but the results seem to be kind of erratic. I'm still working through your Bugzilla history, but so far I've seen several issues.
1. You or your system (henceforth just "you", for simplicity) are consistently re-assigning bugs to your account, even though you are not a maintainer of any of the affected packages AFAICT and so do not actually have the power to resolve them in Fedora. Fedora Bugzilla is for tracking the *downstream* state of bugs; thus the assignee should be a person who can actually resolve the bug in downstream, i.e. a package maintainer. Please stop assigning bugs to your account. Examples: https://bugzilla.redhat.com/show_bug.cgi?id=2477150 , https://bugzilla.redhat.com/show_bug.cgi?id=2480139 , https://bugzilla.redhat.com/show_bug.cgi?id=2480661 etc. etc. (there are dozens of these).
2. You have closed multiple bugs immediately upon submitting an apparently-LLM generated fix upstream, or upon a proposed fix being merged upstream. This is not appropriate for downstream Fedora reports. The appropriate state for a Fedora downstream bug where a fix is proposed upstream but not yet applied in any way downstream is POST. The downstream bug should only be closed when a fix is applied downstream and has reached stable (and, ideally, been verified in testing). Examples: https://bugzilla.redhat.com/show_bug.cgi?id=2469013 , https://bugzilla.redhat.com/show_bug.cgi?id=2479830
3. You have closed multiple bugs in components you do not own as NOTABUG, with a clearly LLM-generated comment. In several instances the comment more or less regurgitated the reporter's description: https://bugzilla.redhat.com/show_bug.cgi?id=2481872#c1 , https://bugzilla.redhat.com/show_bug.cgi?id=2481744#c2 . In other cases the message is superficially plausible, but problematic in other ways, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2481012#c2 , where you confidently asserted that the problem was definitely a firmware issue and explicitly recommended a difficult and potentially problematic action ("Please try installing the `intel_cvs` driver from the Intel Vision Drivers repository").
4. You have submitted LLM-generated "fixes" that are incorrect, and replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix: https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893
I don't think, taken together, these actions are having a positive impact on Fedora or the upstream projects.
I would suggest you adjust your agentic system to be substantially less autonomous. Specifically, I would suggest that it must not:
1. Assign bugs in RHBZ to yourself 2. Change the state of bugs 3. Post confident assertions or specific action recommendations
without review by yourself or another human with appropriate topic area understanding. In all cases it should not assign bugs to yourself or any other party who does not actually have the necessary commit access to resolve those bugs *in Fedora*, and should not change the state of a bug incorrectly (the reference here is https://docs.fedoraproject.org/en-US/package-maintainers/bug_status/ , but that doc is unfortunately broken, I see; I'll send a fix when I'm done cleaning this up). Any LLM-generated text that purports to explain why an issue is happening, why a given change would fix it, and/or recommends any actions to a reporter or maintainer should be clearly flagged as LLM-generated and potentially incorrect, unless it has been carefully reviewed and edited by a human expert.
Thanks!
On Wed, 2026-05-27 at 10:49 -0700, Adam Williamson wrote:
Hi, Nathan. I'm CCing devel@ and test@ so folks are aware this has been going on.
Update on this: Nathan got back to me and says his credentials were compromised and he was not the one behind this AI system. Obviously we should therefore treat any actions it has taken with suspicion. I'm continuing to review the history of Nathan's Bugzilla account; I'll adjust the texts I'm posting to bugs and associated upstream PRs from now on, and review them even more aggressively.
If folks can help look for other actions taken by Nathan's accounts and review them, that would be great.
On Wed, May 27, 2026 at 12:15:44PM -0700, Adam Williamson wrote:
On Wed, 2026-05-27 at 10:49 -0700, Adam Williamson wrote:
Hi, Nathan. I'm CCing devel@ and test@ so folks are aware this has been going on.
Update on this: Nathan got back to me and says his credentials were compromised and he was not the one behind this AI system.
If we take them at their word, that this was indeed a case of password compromise leading to account takeover, then this is rather an embarrasing situation for Fedora IMHO.
IIRC, we last talked about mandating 2FA for all contributors after the xz attack 2 years ago:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
and AFAIR the only outcome of that was a weak docs statement that Provenpackager "should" have 2FA enabled
https://pagure.io/fesco/issue/3186 https://forge.fedoraproject.org/fesco/docs/pulls/90
How many of our PP have got 2FA enabled today ?
When will we get around to mandating 2FA for all contribtors ?
Will we ever augment OTP support with FIDO2/U2F to enable use of hardware tokens ?
GitHub has required 2FA since 2023 GitLab has required 2FA this year PyPI has required 2FA since 2024
IMHO it is not a good look that Fedora continues to allow passwords alone, given we know we are a high value target, and the consequences can be potentially far reaching. 2FA isn't a magic solution to all threats, but continuing to allow passwords alone makes compromising account credentials too easy.
With regards, Daniel
On Thu, Jun 11, 2026 at 11:05 AM Daniel P. Berrangé berrange@redhat.com wrote:
IMHO it is not a good look that Fedora continues to allow passwords alone, given we know we are a high value target, and the consequences can be potentially far reaching. 2FA isn't a magic solution to all threats, but continuing to allow passwords alone makes compromising account credentials too easy.
Don't forget that the actions here happened on Bugzilla, which uses a separate account, and is not necessarily connected to people's FAS accounts (and on GitHub, also not FAS related). I'm not sure that the "classic" bugzilla login supports 2FA *at all* (while FAS does at least to some degree).
Fabio
On Thu, Jun 11, 2026 at 03:25:17PM +0200, Fabio Valentini wrote:
On Thu, Jun 11, 2026 at 11:05 AM Daniel P. Berrangé berrange@redhat.com wrote:
IMHO it is not a good look that Fedora continues to allow passwords alone, given we know we are a high value target, and the consequences can be potentially far reaching. 2FA isn't a magic solution to all threats, but continuing to allow passwords alone makes compromising account credentials too easy.
Don't forget that the actions here happened on Bugzilla, which uses a separate account, and is not necessarily connected to people's FAS accounts (and on GitHub, also not FAS related). I'm not sure that the "classic" bugzilla login supports 2FA *at all* (while FAS does at least to some degree).
Yes, but the inability of BZ to offer this, doesn't mean we should ignore the possiblity to mandate 2FA for FAS where we can offer it.
Possibly BZ will become less relevent if we adopt the issue tracker built into forge.fedoraproject.org instead.
With regards, Daniel
I use 2FA for basically everything *except* Fedora. Yet my Fedora account is one of my highest-value accounts. Compromise a Fedora packager and you can push malware more or less directly to users.
I'm afraid Fedora is just not ready for 2FA. Kerberos is currently the biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171
And even if gnome-online-accounts could theoretically handle 2FA, I still wouldn't be willing to enable it to see whether it works, because if it doesn't work there is no way to disable 2FA without requesting admin intervention.
Presumably almost everybody agrees that we should eventually require 2FA. But first we need to get everything working well, and we're not close yet. Then it ought to be optional for a year or two *after* that point so we can try it out without fear that we will be locked in if there are problems, so we can complete the transition smoothly.
Also, I'm pretty sure I've written more or less this same mail to this list before, possibly several years ago, and we've had no progress since then. Unfortunately we're all busy with our usual work, and nobody has been prioritizing these problems. So: basically the usual explanation for how things happen in open source projects.
On Thu, Jun 11, 2026 at 08:52:54AM -0500, Michael Catanzaro via devel wrote:
Also, I'm pretty sure I've written more or less this same mail to this list before, possibly several years ago, and we've had no progress since then. Unfortunately we're all busy with our usual work, and nobody has been prioritizing these problems. So: basically the usual explanation for how things happen in open source projects.
No one is motivated to prioritize improving 2FA because it is not mandatory. Set a deadline for making it mandatory and it'll nudge someone into making it a priority.
Or we could continue ignoring the problem until another Fedora account's credentials are compromised and does greater damage that causes Fedora significant reputational harm.
With regards, Daniel
On Thursday, 11 June 2026 at 15:46, Michael Catanzaro via devel wrote:
I use 2FA for basically everything except Fedora. Yet my Fedora account is one of my highest-value accounts. Compromise a Fedora packager and you can push malware more or less directly to users.
I'm afraid Fedora is just not ready for 2FA. Kerberos is currently the biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171
[...]
FWIW, I've been using YubiKey-based OTP (via ykman) and fkinit for 2FA with Fedora account for quite some time now and it works quite well.
Regards Dominik
Il 11/06/26 15:56, Dominik 'Rathann' Mierzejewski ha scritto:
On Thursday, 11 June 2026 at 15:46, Michael Catanzaro via devel wrote:
I use 2FA for basically everything except Fedora. Yet my Fedora account is one of my highest-value accounts. Compromise a Fedora packager and you can push malware more or less directly to users. I'm afraid Fedora is just not ready for 2FA. Kerberos is currently the biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171[...]
FWIW, I've been using YubiKey-based OTP (via ykman) and fkinit for 2FA with Fedora account for quite some time now and it works quite well.
Regards Dominik
I've recently purchased a yubikey, but I didn't set up it for authentication with Fedora kerberos. Is there any guide on how to do that?
BTW my idea of using a yubikey with kerberos is to issue fkinit + enter yubikey pin and confirm user presence: is it possible? I must say I'm a newby with hardware tokens and I struggled a lot to understand how to configure the key for basic usage like storing ssh keys for several online accounts. I thought it was and should be easier for users to set up their devices.
Mattia
On Thu, Jun 11, 2026 at 11:02 AM Mattia Verga via devel < devel@lists.fedoraproject.org> wrote:
Il 11/06/26 15:56, Dominik 'Rathann' Mierzejewski ha scritto:
On Thursday, 11 June 2026 at 15:46, Michael Catanzaro via devel wrote:
I use 2FA for basically everything except Fedora. Yet my Fedoraaccount
is one of my highest-value accounts. Compromise a Fedora packagerand
you can push malware more or less directly to users. I'm afraid Fedora is just not ready for 2FA. Kerberos is currentlythe
biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals:https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171
[...]
FWIW, I've been using YubiKey-based OTP (via ykman) and fkinit for 2FA
with
Fedora account for quite some time now and it works quite well.
Regards Dominik
I've recently purchased a yubikey, but I didn't set up it for authentication with Fedora kerberos. Is there any guide on how to do that?
BTW my idea of using a yubikey with kerberos is to issue fkinit + enter yubikey pin and confirm user presence: is it possible? I must say I'm a newby with hardware tokens and I struggled a lot to understand how to configure the key for basic usage like storing ssh keys for several online accounts. I thought it was and should be easier for users to set up their devices.
What you're basically asking for there is to set up your Yubikey as a smart-card with your Fedora account. In theory, the FreeIPA system backing it would support this, but I don't know what it would take to accomplish with the Fedora Accounts bits layered on top.
On Чцв, 11 чэр 2026, Stephen Gallagher wrote:
On Thu, Jun 11, 2026 at 11:02 AM Mattia Verga via devel <[1]devel@lists.fedoraproject.org> wrote:
Il 11/06/26 15:56, Dominik 'Rathann' Mierzejewski ha scritto:
On Thursday, 11 June 2026 at 15:46, Michael Catanzaro via devel wrote:
I use 2FA for basically everything except Fedora. Yet my Fedora
account
is one of my highest-value accounts. Compromise a Fedora packager
and
you can push malware more or less directly to users.
I'm afraid Fedora is just not ready for 2FA. Kerberos is
currently the
biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals:
[2]https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171
[...]
FWIW, I've been using YubiKey-based OTP (via ykman) and fkinit for 2FA
with
Fedora account for quite some time now and it works quite well.
Regards Dominik
I've recently purchased a yubikey, but I didn't set up it for authentication with Fedora kerberos. Is there any guide on how to do that?
BTW my idea of using a yubikey with kerberos is to issue fkinit + enter yubikey pin and confirm user presence: is it possible? I must say I'm a newby with hardware tokens and I struggled a lot to understand how to configure the key for basic usage like storing ssh keys for several online accounts. I thought it was and should be easier for users to set up their devices.
What you're basically asking for there is to set up your Yubikey as a smart-card with your Fedora account. In theory, the FreeIPA system backing it would support this, but I don't know what it would take to accomplish with the Fedora Accounts bits layered on top.
Both FIDO2 and smartcard-based setup are possible with FreeIPA. Indeed, there is some trouble with Fedora Accounts (Nogin) bits. I have some news to share at the Flock, but I had hard time finding *anyone* from the accounts team to respond to my queries over Matrix and IRC in the past few months.
On Thursday, 11 June 2026 at 17:01, Mattia Verga via devel wrote:
Il 11/06/26 15:56, Dominik 'Rathann' Mierzejewski ha scritto:
On Thursday, 11 June 2026 at 15:46, Michael Catanzaro via devel wrote:
I use 2FA for basically everything except Fedora. Yet my Fedora account is one of my highest-value accounts. Compromise a Fedora packager and you can push malware more or less directly to users. I'm afraid Fedora is just not ready for 2FA. Kerberos is currently the biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171[...]
FWIW, I've been using YubiKey-based OTP (via ykman) and fkinit for 2FA with Fedora account for quite some time now and it works quite well.
Regards Dominik
I've recently purchased a yubikey, but I didn't set up it for authentication with Fedora kerberos. Is there any guide on how to do that?
https://docs.fedoraproject.org/en-US/fedora-accounts/user/#twofactor
BTW my idea of using a yubikey with kerberos is to issue fkinit + enter yubikey pin and confirm user presence: is it possible?
Not to my knowledge. The above sounds like U2F workflow, which YubiKey supports, but FAS doesn't, at the moment.
https://docs.fedoraproject.org/en-US/fedora-accounts/user/#pkinit
Regards, Dominik
Mattia Verga via devel devel@lists.fedoraproject.org writes:
I've recently purchased a yubikey, but I didn't set up it for authentication with Fedora kerberos. Is there any guide on how to do that?
You know, I'm in the same boat except that I've owned yubikeys for probably over a decade but never got to the point where I actually used them for anything. (And now they're probably too old to be useful, if I could even find them.)
I really just need to be told what to buy and what to do with it and then I'll use it. In over a decade I've simply not managed to put together the time to figure this out for myself.
Jason L Tibbitts III wrote:
Mattia Verga via devel devel@lists.fedoraproject.org writes:
I've recently purchased a yubikey, but I didn't set up it for authentication with Fedora kerberos. Is there any guide on how to do that?
You can use a Yubikey to generate the OATH-TOTP codes that FAS supports. The GUI program for that became packaging-unfriendly and was dropped from Fedora, but there's the command-line program "ykman" and a wrapper script called "ykocli".
The secret from which TOTPs are generated is written to the Yubikey when you set it up, and can't be read back out, which makes the Yubikey a true second factor. You can configure it to require you to show your presence by touching the Yubikey. If the touch requirement is disabled, then someone with remote access can generate TOTPs while the Yubikey is plugged in.
I use this for various websites, but not for Fedora. The workflow with fedpkg and kinit or fkinit is designed around typing a password and optionally a TOTP. My "password" is a strong random passcode stored in a passcode manager. I'm not going to type that. I can pipe the passcode from the passcode manager to kinit, but that leaves no place for a TOTP. I need to write a program to integrate fedpkg, kinit, the passcode manager and the Yubikey before I can use OATH-TOTP with FAS.
If your FAS password is so weak that you can remember it and type it, then you can probably use OATH-TOTP with FAS – and then you're also among those who need it most.
You know, I'm in the same boat except that I've owned yubikeys for probably over a decade but never got to the point where I actually used them for anything. (And now they're probably too old to be useful, if I could even find them.)
I bought my Yubikey 4 in 2017. It works with OATH-TOTP, so it should work with FAS if the workflow were acceptable. It also works with U2F among other things. For FIDO2 you need a newer Yubikey 5.
Björn Persson
On Thu, Jun 11, 2026 at 08:46:45AM -0500, Michael Catanzaro via devel wrote:
I use 2FA for basically everything *except* Fedora. Yet my Fedora account is one of my highest-value accounts. Compromise a Fedora packager and you can push malware more or less directly to users.
Yep, we're simply lucky that Fedora hasn't already suffered from such attacks. Our luck will run out sooner or later and when that happens, our reputation will be harmed when people see we've known we've needed 2FA for years & yet not treated it as a priority. I don't want to wake up to see Fedora in such news headlines :-(
I'm afraid Fedora is just not ready for 2FA. Kerberos is currently the biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171
This GNOME limitation feels very much like a "nice to have" category item rather than something that should be treated as a blocker. Not everyone uses GNOME, and IIUC there's still the fallback to the CLI so this bug is just a usability improvement.
And even if gnome-online-accounts could theoretically handle 2FA, I still wouldn't be willing to enable it to see whether it works, because if it doesn't work there is no way to disable 2FA without requesting admin intervention.
With mandatory 2FA disabling 2FA is not a concept that would exist. Re-setting 2FA credentials is needed, but admin intervention isn't that much different from what's needed in many other services that use 2FA
It would be better if Fedora had a "recovery tokens" concept like most other sites do for 2FA thogh.
With regards, Daniel
On Thu, Jun 11, 2026 at 08:46:45AM -0500, Michael Catanzaro via devel wrote:
I'm afraid Fedora is just not ready for 2FA. Kerberos is currently the biggest problem. No way would I be willing to enable 2FA before gnome-online-accounts is able to handle ticket renewals: https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/work_items/171
I wrote a simple script to access a keypassxc database on my private nextcloud instance. It makes using 2FA with Fedora reasonably easy. And yes in theory I shouldn't have passwords and totp in the same db, but I'm ok with that.
Steve
On Thu, 2026-06-11 at 08:46 -0500, Michael Catanzaro via devel wrote:
Presumably almost everybody agrees that we should eventually require 2FA. But first we need to get everything working well
Hot take, but: maybe we shouldn't.
Maybe we should make people use 2FA anyway. For two reasons:
1) I'd argue we are at a point where the prevalence of real-world supply-chain attacks makes it sufficiently important that we need to do it *even if the experience is bad*. 2) Bluntly stated, making people use an open source thing that sucks is a great way to make it better. Fedora has believed this for a long time, we just usually say it in nicer words, but that's what we *mean*. That's why we shipped GNOME 3.0 and systemd in the same release![0]
We've been sitting on our hands saying "yeah, well, mandatory 2FA would be great but somebody needs to fix <long wishlist> first" for years now. It clearly isn't working. We need to do something else.
I've had 2FA turned on on my account for years, and I deal with it. Would it be nice if g-o-a handled ticket renewal? Sure. Is it a dealbreaker? No. I have `kinit -R adamwill@FEDORAPROJECT.ORG` in my shell history. I run it once a day. It's fine.
We really, really, really need to mandate 2FA for proven packagers at minimum.
Then we need to fix https://forge.fedoraproject.org/forge/forge/issues/27 and mandate that proven packagers use a secured ssh key.
Then we need to extend that to all packagers.
[0] https://fedoraproject.org/wiki/Releases/15/FeatureList
On Thu, Jun 11, 2026 at 3:34 PM Adam Williamson adamwill@fedoraproject.org wrote:
I've had 2FA turned on on my account for years, and I deal with it.
So have I (and I do (deal)). Would I prefer my FIDO2 key just worked (like it does with github, and numerous other services)? Sure. But the TOTP token is at least a good first step[0].
We really, really, really need to mandate 2FA for proven packagers at minimum.
When that was last proposed some PP's said they would leave the project rather than do so. I do not know if many still believe that, or would actually do that, but even if so, it is long past time to require 2FA (I was of the opinion it was long past time more than two years ago, so consider this an echo from the past).
[0] Perfect is the enemy of good enough.
On Thu, 11 Jun 2026 at 17:34, Adam Williamson adamwill@fedoraproject.org wrote:
I've had 2FA turned on on my account for years, and I deal with it. Would it be nice if g-o-a handled ticket renewal? Sure. Is it a dealbreaker? No. I have `kinit -R adamwill@FEDORAPROJECT.ORG` in my shell history. I run it once a day. It's fine.
I have this automated using systemd user units. It's really dead simple (and could even be packaged as an RPM after some basic configurability is added). This is a slightly simplified (and untested) version of what I have in my home dir:
$ cat "$HOME/.config/systemd/user/krenew.timer" [Unit] Description=Run krenew every 30m
[Timer] OnCalendar=*:00/30:00 OnStartupSec=10m
[Install] WantedBy=timers.target $ cat "$HOME/.config/systemd/user/krenew.service" [Unit] Description=Run krenew
[Service] Type=oneshot ExecStart=kinit -R <principal>@FEDORAPROJECT.ORG $
You just need to add those two files into your home dir (or globally into /usr/lib/systemd/user/), and then run once: $ systemctl --user enable krenew.timer && systemctl --user start krenew.timer
(My setup is a bit more complicated - there is a script instead of the plain kinit -R ... that handles multiple principals and caches, but this simple version should work for most after possibly some minor tweaks.)
On Thu, 2026-06-11 at 08:34 -0700, Adam Williamson wrote:
Maybe we should make people use 2FA anyway. For two reasons:
Except that there are people store their password *and* their sw generated 2FA token in the same db/application making all of this somewhat moot...
sadly whenever you improve security you find someone that self-defeats it better.
Simo.
On 6/11/26 02:37 PM, Simo Sorce wrote:
On Thu, 2026-06-11 at 08:34 -0700, Adam Williamson wrote:
Maybe we should make people use 2FA anyway. For two reasons:
Except that there are people store their password *and* their sw generated 2FA token in the same db/application making all of this somewhat moot...
sadly whenever you improve security you find someone that self-defeats it better.
Problem I see is that every web site naturally generates a different shared secret - I've got roughly 3 dozen and counting. I don't know how to deal with that other than having a database somewhere that contains them all. On the phone it's google authenticator or similar. On the pc it's keepassxc or similar.
I played around with yubikey but found it unhelpful. Maybe the newer ones can store lots of keys, but the old ones didn't. And of course you need at least two keys in case one breaks and of course you have to keep them in sync. And you probably still want a software backup in case a key wears out. It isn't an easy problem.
Steve
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
- You have submitted LLM-generated "fixes" that are incorrect, and
replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix: https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893
Also, this should be DEEPLY inspected, and probably reverted immidately. No patch from an account that is showing suspicious behavior should be in Fedora.
On 5/27/26 3:22 PM, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
- You have submitted LLM-generated "fixes" that are incorrect, and
replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix: https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893
Also, this should be DEEPLY inspected, and probably reverted immidately. No patch from an account that is showing suspicious behavior should be in Fedora.
I'd just revert it. I'm not exactly an expert here, but from reading https://bugzilla.redhat.com/show_bug.cgi?id=2480169 Adam suggested that it being a "fix" for anything related to the bug was a pure hallucination, and from a quick read of kernel code, "warn" is the default for split_lock_detect in any case - I can't tell where the claim of "avoiding a crash" even came from. Other than a hallucination, of course.
-Eric
On Wed, 2026-05-27 at 16:15 -0500, Eric Sandeen wrote:
On 5/27/26 3:22 PM, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
- You have submitted LLM-generated "fixes" that are incorrect,
and replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix: https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893
Also, this should be DEEPLY inspected, and probably reverted immidately.
For the record, we have reverted the PR in Anaconda: https://github.com/rhinstaller/anaconda/commit/1a27b78b061202c250539dc79a8f1...
No patch from an account that is showing suspicious behavior should be in Fedora.
I'd just revert it. I'm not exactly an expert here, but from reading https://bugzilla.redhat.com/show_bug.cgi?id=2480169%C2%A0Adam suggested that it being a "fix" for anything related to the bug was a pure hallucination, and from a quick read of kernel code, "warn" is the default for split_lock_detect in any case - I can't tell where the claim of "avoiding a crash" even came from. Other than a hallucination, of course.
-Eric
Il 28/05/26 13:59, mkolman@redhat.com ha scritto:
On Wed, 2026-05-27 at 16:15 -0500, Eric Sandeen wrote:
On 5/27/26 3:22 PM, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
- You have submitted LLM-generated "fixes" that are incorrect,
and replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix: https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893
Also, this should be DEEPLY inspected, and probably reverted immidately.
For the record, we have reverted the PR in Anaconda: https://github.com/rhinstaller/anaconda/commit/1a27b78b061202c250539dc79a8f1...
Does any update with that patch included ever landed in repositories? Shall we untag any build pushed in testing/stable?
Mattia
On Thu, 2026-05-28 at 16:03 +0000, Mattia Verga via devel wrote:
Il 28/05/26 13:59, mkolman@redhat.com ha scritto:
On Wed, 2026-05-27 at 16:15 -0500, Eric Sandeen wrote:
On 5/27/26 3:22 PM, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
- You have submitted LLM-generated "fixes" that are
incorrect, and replied to objections with LLM-generated justifications that eventually overwhelmed the maintainer into merging the fix: https://github.com/rhinstaller/anaconda/pull/7074#issuecomment-4556782893
Also, this should be DEEPLY inspected, and probably reverted immidately.
For the record, we have reverted the PR in Anaconda: https://github.com/rhinstaller/anaconda/commit/1a27b78b061202c250539dc79a8f1...
Does any update with that patch included ever landed in repositories? Shall we untag any build pushed in testing/stable?
Mattia
Good point - I've just checked & we actually release 2 of those PRs into Anaconda 45.5 2 days ago:
https://github.com/rhinstaller/anaconda/releases/tag/anaconda-45.5 https://koji.fedoraproject.org/koji/buildinfo?buildID=3002191
So maybe from the abundance of caution lets untag that, just in case ?
And we can do a new build tomorrow from our main branch that already has those PRs reverted.
-
Adam Williamson -
Alexander Bokovoy -
Björn Persson -
Chris Adams -
Daniel P. Berrangé -
Dominik 'Rathann' Mierzejewski -
Eric Sandeen -
Fabio Valentini -
Gary Buhrmaster -
Jason L Tibbitts III -
Mattia Verga -
Michael Catanzaro -
mkolman＠redhat.com -
Ondrej Mosnáček -
Simo Sorce -
Stephen Gallagher -
Steven A. Falco