On Wed, Jul 1, 2026 at 7:32 AM Alexander Bokovoy <[email protected]> wrote: > > On Срд, 01 ліп 2026, Neal Gompa wrote: > >On Wed, Jul 1, 2026 at 4:49 AM Daniel P. Berrangé <[email protected]> > >wrote: > >> > >> On Wed, Jul 01, 2026 at 10:36:04AM +0200, [email protected] wrote: > >> > On Sun, 2026-06-28 at 15:21 -0500, Maxwell G wrote: > >> > While this can be preferable to some more technical Fedora > >> > contributors, to me it kinda looks like trying very hard to avoid > >> > making a simple web app instead, that takes the content of a couple > >> > fields, validates the content of them if possible (change type set, > >> > owner FAS account exists, Fedora version set, etc.) and generates > >> > outputs as needed (plaintext email summary, static web page, etc.). > >> > >> The problem with a "simple web app" is that while the initial job > >> may look simple, and impl may even be simple, we then have an > >> ongoing never ending burden to support this web app. > >> > >> We've got a long (and disappointing) track record in Fedora of building > >> things and then being unable to support them sufficiently well due to > >> lack of resources, especially when the original author moves on. > > > >We have a long history of not providing community support for > >Fedora-originated projects. Infrastructure or otherwise, it's rare for > >a project coming from Fedora to be broadly successful because there is > >no designed intent to market them and build communities around them. > > > >It even happens to Fedora Linux itself, if you look at the variants > >other than the Red Hat-supported ones. > > > >I would rather us go down the road of making simple web apps for this > >stuff. What we need to own up to is that we cannot count on Fedora > >itself to be an advocate for projects built by Fedora contributors. > >Those contributors need to actively do community-building work > >themselves. > > > >> We > >> can't even get sufficient resources to support & develop critical > >> infrastructure such as our accounts system (see recent discussions > >> about its sub-optimal support for 2FA that no one has had time to > >> improve for years). > >> > > > >I mean, this one is mostly the fault of FreeIPA. It isn't designed for > >community projects, and shoehorning it into Fedora has resulted in > >this flaw. It won't be fixed because no corporate customer of IdM > >needs it, since the model works for business deployments. > > > >It isn't going to get fixed because IdM doesn't consider Fedora an > >important customer/stakeholder/etc for feature development. > > You are wrong, Neal. I don't want to spent time in fruitless discussions > but I'd ask you to refrain from unsubstantiated statements. >
I am not wrong. Having MFA support is not the same thing as supporting low-touch MFA workflows. Zero-touch MFA reset has been a requested feature ever since we started talking about MFA for packagers. We don't have it. Instead, we have to contact an admin to reset it. No self-service recovery code based mechanism, or email verification mechanism, or anything of the sort. These are all things that are part of table-stakes for account systems like ours, and we don't have it. This is a genuine hardship, and we know that it's something that takes actual time from people since ~15 resets have been done in the past six months alone. Self-service resets are, from my point of view, the only major blocker to considering mandatory MFA. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
