Upcoming Change Proposal for making 2FA mandatory for all packagers

decathorpe commented

2026-06-24 18:08:01 +00:00

Owner

I have been made aware (at this point, by two people!) that there is a work-in-progress Change proposal for making 2FA mandatory for members of the packager group ¹:
https://fedoraproject.org/wiki/Changes/2FAChangeProposal

¹ and possibly more groups? The text in the current draft is not entirely clear to me.

Apparently yesterday's decision to change the FESCo Provenpackager policy to upgrade the "SHOULD use 2FA" to "MUST" has kind of surprised the people involved.

I suggested to @jspaleta that it might make sense to have (at least one) FESCo member and potentailly (at least one) Council member be co-owner of that proposal to make sure it's sound and in good shape before submission.

So I'm filing this ticket essentially as a "call for volunteers".

I have been made aware (at this point, by two people!) that there is a work-in-progress Change proposal for making 2FA mandatory for members of the `packager` group ¹: <https://fedoraproject.org/wiki/Changes/2FAChangeProposal> ¹ and possibly more groups? The text in the current draft is not entirely clear to me. Apparently yesterday's decision to change the FESCo Provenpackager policy to upgrade the "SHOULD use 2FA" to "MUST" has kind of surprised the people involved. I suggested to @jspaleta that it might make sense to have (at least one) FESCo member and potentailly (at least one) Council member be co-owner of that proposal to make sure it's sound and in good shape before submission. So I'm filing this ticket essentially as a "call for volunteers".

decathorpe referenced this issue

2026-06-24 18:08:40 +00:00

Should we require 2FA for provenpackagers? #3618

decathorpe commented

2026-06-24 18:14:21 +00:00

Author

Owner

Note: One element of the "surprise" appears to be that the policy change we discussed yesterday did not itself go through the Change process.

Personally I don't think it would have been appropriate for a reasonably small-scoped change to a FESCo policy document (and associated implementation) to go through the full Change process - this would have been way too much overhead, and I'm also not sure that the Change process would be the appropriate venue to discuss FESCo Policy. But I do see the point that it could be argued that it should have gone through a more formal process (announcement / discussion / vote), whether that would have been the actual Change process or just something similar to it.

Note: One element of the "surprise" appears to be that the policy change we discussed yesterday did not itself go through the Change process. Personally I don't think it would have been appropriate for a reasonably small-scoped change to a FESCo policy document (and associated implementation) to go through the full Change process - this would have been way too much overhead, and I'm also not sure that the Change process would be the appropriate venue to discuss FESCo *Policy*. But I do see the point that it could be argued that it *should* have gone through a more formal process (announcement / discussion / vote), whether that would have been the actual Change process or just something similar to it.

blc commented

2026-06-24 19:14:28 +00:00

By the way, there is a draft change proposal of a similar notion here: https://fedoraproject.org/wiki/Changes/2FAChangeProposal

We (CLE) hadn't put it forward for review yet due to so many things going on leading up to Flock, but were going to be bringing it up shortly. We think using the Change Proposal process is correct because it is what is documented and normal for the full community, of which we are members.

As for what to do for now, perhaps we should combine forces?

By the way, there is a *draft* change proposal of a similar notion here: https://fedoraproject.org/wiki/Changes/2FAChangeProposal We (CLE) hadn't put it forward for review yet due to so many things going on leading up to Flock, but were going to be bringing it up shortly. We think using the Change Proposal process is correct because it is what is documented and normal for the full community, of which we are members. As for what to do for now, perhaps we should combine forces?

gotmax23 commented

2026-06-24 20:13:58 +00:00

Owner

We did have a devel list thread where the provenpackager change was discussed, a link to the FESCo ticket was posted to make clear that this was being discussed as a policy change, and it was included on the FESCo meeting agenda. Using the Changes Process honestly didn't occur to me, as it's usually meant for large, concrete changes to the distribution, not FESCo policy changes. And community feedback on the devel thread was largely positive.

I thought that was sufficient, but I see how this could have been missed with conference travel and the long discussion thread, etc. If anybody has ideas on how to make FESCo policy discussion more transparent, of course we're all ears :).

We did have a devel list thread where the provenpackager change was discussed, a link to the FESCo ticket was posted to make clear that this was being discussed as a policy change, and it was included on the FESCo meeting agenda. Using the Changes Process honestly didn't occur to me, as it's usually meant for large, concrete changes to the distribution, not FESCo policy changes. And community feedback on the devel thread was largely positive. I thought that was sufficient, but I see how this could have been missed with conference travel and the long discussion thread, etc. If anybody has ideas on how to make FESCo policy discussion more transparent, of course we're all ears :).

gotmax23 commented

2026-06-24 20:15:08 +00:00

Owner

Re. the main $subject, I do agree that making 2FA mandatory for the entire packager group needs more careful consideration, planning, and discussion. That is why the initial proposal was scoped to the provenpackager group only. It only involved changing a single word in the existing provenpackager policy about 2FA (SHOULD -> MUST) and a lightweight process surrounding it.

Enabling this for all packagers is more difficult. For one thing, there are 114 provenpackager (about half of which already had 2FA enabled). There are 1376 packager members. Also, the process we're using to enforce provenpackager 2FA that involves manually removing group memberships won't work if we want to require 2FA more broadly.

The accounts system, issuance of kerberos tickets, and Ipsilon (or whatever service replaces Ipsilon) used for OIDC auth with web services will all need resourced work to prevent users without 2FA from logging in until they configure 2FA and provide the setup flow described in the draft Change Proposal. We also need to improve the account recovery process in Noggin. Proper support for hardware keys via FIDO2 would also be ideal. My main feedback on the draft proposal text is that it needs to more clearly enumerate the technical steps in each system to implement these necessary enhancements and who will be doing that work.

So I do think that larger change should go through the Changes Process or some similar process. Since you already have a draft Change Proposal, I don't see a strong reason not to build on that that, even if parts of the template (like Targeted release) are not applicable. The important steps are really just making space for community feedback and having FESCo vote on the final proposal which this accomplishes.

Re. the main $subject, I do agree that making 2FA mandatory for the entire packager group needs more careful consideration, planning, and discussion. That is why the initial proposal was scoped to the provenpackager group only. It only involved changing a single word in the existing provenpackager policy about 2FA (`SHOULD` -> `MUST`) and a lightweight process surrounding it. Enabling this for all packagers is more difficult. For one thing, there are **114** provenpackager (about half of which already had 2FA enabled). There are **1376** packager members. Also, the process we're using to enforce provenpackager 2FA that involves manually removing group memberships won't work if we want to require 2FA more broadly. The accounts system, issuance of kerberos tickets, and Ipsilon (or whatever service replaces Ipsilon) used for OIDC auth with web services will all need resourced work to prevent users without 2FA from logging in until they configure 2FA and provide the setup flow described in the draft Change Proposal. We also need to improve the account recovery process in Noggin. Proper support for hardware keys via FIDO2 would also be ideal. My main feedback on the draft proposal text is that it needs to more clearly enumerate the technical steps in each system to implement these necessary enhancements and who will be doing that work. So I do think that larger change should go through the Changes Process or some similar process. Since you already have a draft Change Proposal, I don't see a strong reason not to build on that that, even if parts of the template (like Targeted release) are not applicable. The important steps are really just making space for community feedback and having FESCo vote on the final proposal which this accomplishes.

blc commented

2026-06-24 20:33:48 +00:00

OK, it sounds like us proceeding with a change proposal still makes the most sense, thanks! We can take advantage of the feedback that was supplied during the ProvenPackager discussion. As we update the proposal we can speak to the topics that were raised and the portions we'd sign up to do ourselves. Hopefully everybody recognizes this is a perfect-is-the-enemy-of-the-good situation.

kashyapc commented

2026-06-24 22:07:45 +00:00

Hopefully everybody recognizes this is a perfect-is-the-enemy-of-the-good situation.

FWIW, as @gotmax23 implies above, I see that recognition in the step-wise approach of first starting with 'provenpackager' as the sensible pilot, then resolve the uncovered technical issues, and then to roll out broadly -- this is not explicitly stated yet, for reasons noted by others above, but it doesn't imply there's no "intent". Some people seem to mix these up.

So, "some team" with the relevant skills need to figure out the solutions to the technical problems in the various identity and authentication systems. @kevin outlined some open problems in FreeIPA and other components in his response on that 2FA devel thread.

PS: The discussion on the 'fedora-devel' was extensive enough that even LWN wrote a competent summary of it (a SubscriberLink that's world-readable).

> Hopefully everybody recognizes this is a perfect-is-the-enemy-of-the-good situation. FWIW, as @gotmax23 implies above, I see that recognition in the step-wise approach of first starting with 'provenpackager' as the sensible pilot, then resolve the uncovered technical issues, and then to roll out broadly -- this is not explicitly stated yet, for reasons noted by others above, but it doesn't imply there's no "intent". Some people seem to mix these up. So, "some team" with the relevant skills need to figure out the solutions to the technical problems in the various identity and authentication systems. @kevin outlined some open problems in FreeIPA and other components in his [response](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ET45BSH4KNVUBRJV5TJRSGAWQWBRF6PR/) on that 2FA devel thread. PS: The discussion on the 'fedora-devel' was extensive enough that even LWN wrote a competent [summary of it](https://lwn.net/SubscriberLink/1078964/f846b3aba1d3ef64/) (a SubscriberLink that's world-readable).

👀 1

ngompa commented

2026-07-03 07:18:37 +00:00

Owner

@blc wrote in #3625 (comment):

OK, it sounds like us proceeding with a change proposal still makes the most sense, thanks! We can take advantage of the feedback that was supplied during the ProvenPackager discussion. As we update the proposal we can speak to the topics that were raised and the portions we'd sign up to do ourselves. Hopefully everybody recognizes this is a perfect-is-the-enemy-of-the-good situation.

Sure, but there's a difference between "lacking table stakes" and "not being perfect". There needs to be some progress on closing gaps that were identified the first few times this has come up. If there isn't any, I find it difficult to support this at all.

@blc wrote in https://forge.fedoraproject.org/fesco/tickets/issues/3625#issuecomment-866829: > OK, it sounds like us proceeding with a change proposal still makes the most sense, thanks! We can take advantage of the feedback that was supplied during the ProvenPackager discussion. As we update the proposal we can speak to the topics that were raised and the portions we'd sign up to do ourselves. Hopefully everybody recognizes this is a perfect-is-the-enemy-of-the-good situation. Sure, but there's a difference between "lacking table stakes" and "not being perfect". There needs to be _some_ progress on closing gaps that were identified the first few times this has come up. If there isn't any, I find it difficult to support this at all.

salimma commented

2026-07-07 09:12:40 +00:00

Owner

I'd suggest waiting to see how it shakes out among provenpackagers before submitting CLE"s Change Proposal? That way any feedback from the smaller group can be incorporated and addressed. As @ngompa noted, if we're applying the current 2FA to all packagers I would have to vote no too, I reluctantly voted yes for provenpackagers hoping that the issues we've known for years will actually start being addressed if it's actually enforced on a large group of trusted packagers and they start having issues.

👍 1

thebeanogamer referenced this issue from security/tickets

2026-07-10 18:33:03 +00:00

Review Fedora security documents to align with "Vulnerability and Incident Policy" CRA requirement #14

zbyszek commented

2026-07-21 10:59:39 +00:00

Owner

@gotmax23 Can you publish the updated statistics of 2FA enablement for PPs? (How does one extract this information?) And can we have the same for non-PPs?

gotmax23 commented

2026-07-21 12:57:15 +00:00

Owner

@kevin or another accounts admin will have to do that. If the percentage is still high, I can send more reminders.

Rows
Columns

Upcoming Change Proposal for making 2FA mandatory for all packagers #3625