Il 19/08/22 07:17, Adam Williamson ha scritto:

On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote:

...

Hello everyone!

I just completed the first run of FESCo's newly approved Inactive Packager Policy[1]. Packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the F37 final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.)

So on this point specifically - I had a look through the tickets for interest, and saw two cases where people replied to the ticket to say essentially "yes, it's fine to take away my packager rights". Which, ironically, would prevent it from happening, it seems.

Can we handle that? Can you manually flag those cases to continue through the process, or something?

Unfortunately, with the script in the current status **ALL** tickets need to be handled manually. This kind of reply from a user is what it made me choose to not handle opened tickets automatically when I initially wrote the script. I know this will going to be painful in this first run, but in following runs I'd expect only a bunch of tickets to be created.

It can however be enhanced, maybe we can add a specific tag "requested_removal" so that the script knows how to handle them (in a future version). But it will always need a manual intervention to add the tag to the ticket.

Mattia

Do I get removed, while waiting for packages to be approved ? Have been waiting for a year, may take another ...

Jan FAS copperi ________________________________ From: Ben Cotton bcotton@redhat.com Sent: Friday, August 19, 2022 2:59 PM To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Inactive packagers to be removed after the F37 release

On Fri, Aug 19, 2022 at 1:18 AM Adam Williamson adamwill@fedoraproject.org wrote:

Can we handle that? Can you manually flag those cases to continue through the process, or something?

It's like 10,000 spoons, when all you need is removal from the packager group. But yes, I'm manually handling those cases. Right now, it's by putting them on a list of "people who will show up as active but have acked removal". I have plans for how that can be handled in the future without me keeping a separate list on my Todoist task. But for now I am (slowly) going through every comment on tickets to make sure that everything gets handled correctly.

-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On 19/08/2022 08:45, Merlin Cooper wrote:

I like this policy, but it strikes me as odd that the packagers' email addresses are posted publicly on the Pagure tickets... Wouldn't that make it easier for spammers to get more email addresses?

Spammers can easily get email addresses from all Git commits.

On Fri, Aug 19, 2022 at 1:08 PM Ben Cotton bcotton@redhat.com wrote:

On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper mxanthropocene@outlook.com wrote:

...

I like this policy, but it strikes me as odd that the packagers' email addresses are posted publicly on the Pagure tickets... Wouldn't that make it easier for spammers to get more email addresses?

The script has a flag I can use in the future which (I believe) will mask the addresses in the tickets. I didn't use it this time because email addresses are already displayed all over the place. If a spammer gets an email address from these tickets that they didn't have before, then I'll be very surprised.

I really wish people would stop making the argument that just because other places/systems have terrible data hygiene, we can have terrible data hygiene too. Fedora should be trying to set the example of how to interact and behave, and the "follow the herd" mentality here is not acceptable in my opinion.

Email address could be considered PII, and so there is a debate about when the GDPR-type regulations would apply to them (from what I read, it would apply for work email addresses giving full names or personal email addresses). While there is a legal basis for keeping the email address in the system and using it, I fail to see a legal basis that would allow publicly displaying an email address in this way.

Many systems are also trying to reduce the exposure of personal email addresses, with major git hosting providers even creating anonymous commit emails that can be associated with user accounts on those systems and then used for your commits should you choose.

So in short, I strongly argue for masking/removing the email address from all tickets like this, and the fact that they are displayed there was is so concerning to me that I opened a ticket about it last night: https://pagure.io/find-inactive-packagers/issue/619.

-Ian

That said, if there's a general consensus that addresses should be masked in the ticket, then we can do that in the future. I considered whether the tickets should default to private, but the downside is that people wouldn't be able to log in and comment on the ticket via the Pagure web interface, only by email.

-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On Fri, 2022-08-19 at 10:37 -0400, Stephen Smoogen wrote:

On Fri, 19 Aug 2022 at 08:42, Ian McInerney via devel devel@lists.fedoraproject.org wrote:

...

On Fri, Aug 19, 2022 at 1:08 PM Ben Cotton bcotton@redhat.com wrote:

...

On Fri, Aug 19, 2022 at 2:46 AM Merlin Cooper mxanthropocene@outlook.com wrote:

...

I like this policy, but it strikes me as odd that the packagers' email addresses are posted publicly on the Pagure tickets... Wouldn't that make it easier for spammers to get more email addresses?

The script has a flag I can use in the future which (I believe) will mask the addresses in the tickets. I didn't use it this time because email addresses are already displayed all over the place. If a spammer gets an email address from these tickets that they didn't have before, then I'll be very surprised.

I really wish people would stop making the argument that just because other places/systems have terrible data hygiene, we can have terrible data hygiene too. Fedora should be trying to set the example of how to interact and behave, and the "follow the herd" mentality here is not acceptable in my opinion.

Email address could be considered PII, and so there is a debate about when the GDPR-type regulations would apply to them (from what I read, it would apply for work email addresses giving full names or personal email addresses). While there is a legal basis for keeping the email address in the system and using it, I fail to see a legal basis that would allow publicly displaying an email address in this way.

Many systems are also trying to reduce the exposure of personal email addresses, with major git hosting providers even creating anonymous commit emails that can be associated with user accounts on those systems and then used for your commits should you choose.

So in short, I strongly argue for masking/removing the email address from all tickets like this, and the fact that they are displayed there was is so concerning to me that I opened a ticket about it last night: https://pagure.io/find-inactive-packagers/issue/619.

I am going to argue that this isn't bad data hygiene because this data being public serves an important purpose for the ongoing working of this project.

When you become a Fedora maintainer, you are not just helping your fellow maintainers, you are also helping the general public who may be upstream developers, users, and packagers in different projects. When a person makes a change or has had their 'hands' on a package, that is made public in many many places to make sure that any and all interested people can contact them for questions. Upstream may have suggestions to make that change better or worse. Other packagers may need to understand why that package affects them. Packagers in different projects need to contact to see if this will solve their problem with said package or not. This has been and is mostly still done via email first and bugzilla and other methods last.

When that information is not easily available, trust in the change, package, maintainer drops. That lack of trust tends to boil through many areas and lowers trust in the overall operations of the distribution. Because of this, email addresses for packagers have never been very secret. They are in spec files, they are in email posts about changes to packages, they are in various message buses which anyone can subscribe to on the idea that the information being free improves trust.

Then there comes the removal of privileges. This is a big concern and needs to be done in an open and clear fashion. Other developers and packagers need to understand WHO was attempted to be contacted and why that contact may have failed. When other projects have not done this in an open arena, it has caused unrelated packagers to quit because they are not sure they can trust the project to not do the same with them. There is also the fact that email addresses change a lot and sometimes the person who has been listed as `foobaz@uforgot.me` may have gone to `notme@notmy.email` and need to update their info. It might be even clear that notme@notmy.email has been active in bugzilla or some other area but hasn't done a build because a different maintainer has done so.

We may need to come up with different methods of 'trust'. That is a larger conversation because it would require a complete rethink of what we are as a project and how we 'trust' each other, and allow others to 'trust' us.

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Might I suggest that the equivalent fedora email, i.e. user@fedoraproject.org, is instead published? That way the user can receive and redirect packaging mail while at least retaining a layer of anonymity.

Or is that not possible?

Il 19/08/22 18:53, Gary Buhrmaster ha scritto:

On Fri, Aug 19, 2022 at 10:47 AM P J P pjp@fedoraproject.org wrote:

...

• Interesting numbers there.

(see below on another number)

...

• While I get that such pruning from time to time is generally good. What happens to the packages orphaned by removing inactive packagers?

• Removing orphaned packages may not be easy, as other packages may depend on them.

Obviously, if the packages are still desired or needed, an active packager will need to pick them up. For a number of those packages I suspect that they have been running more or less on successful auto-pilot (mass rebuild) for some time, so picking them up should not result in substantially increased workload going forward after the initial take, but I admit I, myself, do not look forward to having to add to the list of packages I might need to feel (at least notionally) responsible for if I end up having to take some of them on due to dependencies in things I do care about.

I would also say, that while it is probably not entirely easy to do so, a *very* interesting additional number would have been how many packages would be orphaned if all of the identified packagers are removed, just so we have an order of magnitude of what we are looking at moving forward. But that list is probably best produced at a later time, as, for all we know, many of the people may indeed still be active (and because their packagers do run on auto-pilot, do not regularly engage).

These are, of course, probably mostly first run issues. Once the process is in place and ongoing, the order of magnitude of the people and packages is likely to be the usual background noise levels.

If anyone wants to have a look to what packages **may** be orphaned when those users are removed from the packager group, I've set up a script and uploaded the results here [1].

Do not be too scared by those results: there's still plenty of time for those users to show up and declare their willingness to maintain their status. If you, however, see a package you care listed with an asterisk (look at the bottom of the list), take notice that these are the packages that will surely be orphaned, because the current maintainer has asked to be removed from the packager group. Maybe you can start asking them to transfer the package to you.

I plan to post an updated list before the end of the month and at mid October (or maybe Ben will do, if he prefer).

Mattia

[1] https://mattia.fedorapeople.org/inactive-packagers/affected_packages.txt

On Sun, Sep 4, 2022 at 1:38 PM Mattia Verga wrote:

If anyone wants to have a look to what packages **may** be orphaned when those users are removed from the packager group, I've set up a script and uploaded the results here [1].

Do not be too scared by those results: there's still plenty of time for those users to show up and declare their willingness to maintain their status. If you, however, see a package you care listed with an asterisk (look at the bottom of the list), take notice that these are the packages that will surely be orphaned, because the current maintainer has asked to be removed from the packager group. Maybe you can start asking them to transfer the package to you.

I plan to post an updated list before the end of the month and at mid October (or maybe Ben will do, if he prefer).

[1] https://mattia.fedorapeople.org/inactive-packagers/affected_packages.txt

Regarding the following package from that list : - NetworkManager-l2tp (owned by ivanromanov)

I've been maintaining the package (and upstream source) since 2016, but I'm not the 'owner" or "main admin", just a member/admin.

What's the best way to become owner of the NetworkManager-l2tp package?

Thanks, Doug

On Sat, 2022-09-03 at 13:04 -0700, Kevin Fenzi wrote:

On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote:

...

So, I have a probably-controversial idea for a follow-up on this.

Even after this sweep, we have 141 proven packagers. That's a lot of people who can build almost anything in Fedora.

It should be possible to check whether a provenpackager has built any package they don't have direct commit rights to in the last X months.

Should we construct that search, run it, and propose removing provenpackager status from folks who aren't using it, to cut down that set?

That policy was setup before this one for packagers. ;)

https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

Look, I'm getting old, okay? ;)

But yeah, looking at that, one 'loophole' is it doesn't check if they're actually needing *proven* packager powers - just packager powers. If a proven packager is only building packages they have explicit commit rights to, they may not need proven packager powers any more?

On Sat, Sep 3, 2022 at 10:01 PM Adam Williamson adamwill@fedoraproject.org wrote:

Look, I'm getting old, okay? ;)

I am highly confident that everyone is getting older (with the possible exception being if your name is Benjamin Button).

But yeah, looking at that, one 'loophole' is it doesn't check if they're actually needing *proven* packager powers - just packager powers. If a proven packager is only building packages they have explicit commit rights to, they may not need proven packager powers any more?

True enough, although I think if someone is actually active, and building multiple packages (even if they have gotten explicit commit rights (either before or after getting PP powers)), that we would probably need quite an extended time frame (2+ years) to determine with some confidence (to avoid undue annoyance emails) that they no longer appear to need that group membership. It would certainly be interesting to run a test to determine if any PP would fall into that category (and not the larger one of no builds at all) but I suspect that there would be a large number. btw, it would seem that a way for a PP to avoid the annoyance emails under your loophole closing would be to drop explicit commit rights and use PP privs on some package (the loophole bypass loophole defense?)

On Sat, Sep 03, 2022 at 05:40:28PM -0700, Adam Williamson wrote:

Gadzooks, foiled by the old loophole bypass loophole defense again?!

No one expects the... :)

No, seriously, I'm kinda assuming 'positive intent' here. It's not meant to catch someone trying to 'avoid' the check. More maybe just someone who got PP powers years ago but now just maintains one or two packages, but never thought about giving them up. Maybe if there are folks like that they'd be happy to drop the privileges so if they do lose their laptop or something, the consequences are more limited.

Could be. Actually builds isn't a good test either entirely. You could use your provenpackager powers to fix things for others and let them do the builds, or use them for filing bodhi updates for packages you didn't build that someone else didn't file...

Perhaps it would be better (although more noisy) to just mail all provenpackagers every cycle and ask if anyone would like to leave the group?

kevin

On Sun, Sep 4, 2022 at 1:53 AM Richard Shaw hobbes1069@gmail.com wrote:

Is it that big of a deal to require some sort of practical affirmation on an annual basis? It could be completely automated.

Am I way off base here?

I don't think so, with some extensions. I still assert that PP's that do not have and use a "PassKey" (Apple's rebranding of FIDO2 multifactor (Apple is great about branding)) should regularly (once a year?) need to reaffirm "I'm not dead (yet)", while those with an enrolled PassKey should be able to only revalidate when then hit one/more of the other criteria, as their account is highly protected against abuse.

On Sun, 2022-09-04 at 03:02 +0000, Gary Buhrmaster wrote:

On Sun, Sep 4, 2022 at 1:06 AM Kevin Fenzi kevin@scrye.com wrote:

...

Perhaps it would be better (although more noisy) to just mail all provenpackagers every cycle and ask if anyone would like to leave the group?

One should ask a PP (I am not so honored), but getting an email every cycle (and requiring an affirmative response) would be one of those reasons that I would consider a loophole closure loophole bypass ("stop annoying me!").

Personally, once a year wouldn't be anywhere near frequent enough to trigger me to Do Something About It - it took me years to turn off Bugzilla's "hey look you have needinfo bugs!" thing and I was getting that every *day*. :P But I dunno about others.

On 04/09/2022 02:40, Adam Williamson wrote:

Maybe if there are folks like that they'd be happy to drop the privileges so if they do lose their laptop or something, the consequences are more limited.

We just need to force all proven packagers to use 2FA. Problem solved.

On Sun, Sep 4, 2022 at 3:52 PM Adam Williamson adamwill@fedoraproject.org wrote:

Well, not really. 2FA isn't a magic bullet. I would be in favor of doing this, but you can't treat any security measure as solving all your problems completely.

Nothing is a magic bullet (and most security can be bypassed with the $10 (it was $5 before inflationary increase) wrench) but passkeys (which can eliminate passwords entirely) do tend to raise the bar substantially, and those services doing authorization can require additional levels of real time identity assurance for additional levels of access (so inserting a usb token, or having your phone nearby, might let you login, but you need to provide additional something (pin, biometrics, whatever) to access things at a higher level at the time you require that (say, for this case, using PP powers)).

However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*).

(*) Given that all the major tech companies are moving towards allowing (and will be encouraging) customers to use passkeys I hope we will see better integrations with FreeIPA and Ipsilon at some point.

On 04/09/2022 19:30, Michael Catanzaro wrote:

And anybody who isn't willing to buy a security key wouldn't be able to contribute to Fedora at all.

So, you want to ban all contributors from countries where such tokens are prohibited, am I right? Strongly -1.

On Mon, 2022-09-05 at 10:13 +0200, Dominik 'Rathann' Mierzejewski wrote:

Wait, what? Which countries are 2FA token illegal in?

Regards, Dominik

I cannot think of any reason why 2FA would be illegal in any country when TOTP is based on HMAC and by default uses SHA-1.

Further if I may offer my unsolicited opinion, I am strongly in favor in requiring 2FA. And if doing it across the board is inconvenient, at least for "important" packages/roles.

There's been too many supply chain incidents (see npm, github, any corporate data breach, et al.) that I think Fedora would benefit from mandating 2FA.

On 05/09/2022 10:33, Tommy Nguyen wrote:

I cannot think of any reason why 2FA would be illegal in any country when TOTP is based on HMAC and by default uses SHA-1.

In some countries (eg. Russia, China) all cryptographic devices must be certified by local government security service.

Further if I may offer my unsolicited opinion, I am strongly in favor in requiring 2FA.

Who will pay for these devices? Red Hat? Gnome Foundation? Most maintainers won't be happy to spend $50 on a hobby project.

There's been too many supply chain incidents (see npm, github, any corporate data breach, et al.) that I think Fedora would benefit from mandating 2FA.

For 15 years, there hasn't been a single incident with Fedora.

On Monday, 05 September 2022 at 12:40, Vitaly Zaitsev via devel wrote:

On 05/09/2022 10:13, Dominik 'Rathann' Mierzejewski wrote:

...

Wait, what? Which countries are 2FA token illegal in?

Russia, China and all countries from the US export banlist.

Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it.

Especially since for example Google's Titan Security Keys are made by a Chinese company Feitian[1][2].

[1] https://www.cnbc.com/2018/08/30/google-titan-made-by-chinese-company-feitian... [2] https://www.zdnet.com/article/google-launches-titan-security-keys-but-recomm...

Regards, Dominik

On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote:

On 05/09/2022 14:58, Dominik 'Rathann' Mierzejewski wrote:

...

Do you have any references to articles of law or other regulations? Sorry, but this sounds so absurd I can't just take your word for it.

Sure (in Russian, use Google Translate):

• http://clsz.fsb.ru/clsz/in-out.htm
• http://clsz.fsb.ru/clsz/notif.htm

The site blocks access from outside of Russia.

On ma, 05 syys 2022, Vitaly Zaitsev via devel wrote:

On 05/09/2022 17:05, Alexander Bokovoy wrote:

...

The site blocks access from outside of Russia.

Yes, you need RU proxy to read the original documents. But you can use your favorite search engine to find "FSB notification" articles in English.

Example: http://www.mintest-russia.com/news/russia-importing-encrypted-products-fsb-n...

There are solutions by Russian companies which use WebAuthn and were certified by Russian state (FSTEK). For example, Avanpost Web SSO and Avanpost FAM were certified in 2021. They are using tokens from Aladdin, Feitian, and Rutoken, compatible with FIDO2 U2F/WebAuthn. These products are certified and allowed for use in Russia.

I happen to know as they support FreeIPA integration officially.

The issue right now is not a non-certified usage but a basic unavailability of these tokens inside the country. However, this is a completely different store.

Avanpost's press-releases (in Russian): https://avanpost.ru/news/928/ https://avanpost.ru/news/944/, and https://avanpost.ru/news/973/

...

However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*).

You don't have to be a provenpackager to be able to do serious damage; you just need to maintain one package that's installed by a sufficiently-interesting quantity of Fedora users. In the long run, we should be moving to require WebAuthn for all Fedora authentication-related purposes, since it's unphishable. Last year I entered my GitHub password into a phishing page that was proxying the real GitHub... if the evil page had gone to just slightly more effort, it could have easily intercepted a simple TOTP/HOTP challenge. This is not possible with WebAuthn, which I would say actually is pretty much equivalent to a security magic bullet.

That said, I say this keenly aware that WebKitGTK doesn't support WebAuthn yet, and I would be interacting with Fedora packaging a lot less if I couldn't use my normal web browser. And anybody who isn't willing to buy a security key wouldn't be able to contribute to Fedora at all.

But webauthn and 2FA only stops someone else from compromising my account, it would probably be easier to join and become a packager by packaging a random leaf package no one would use, then as a packager pick up an random orphaned package that's in the core distro and then just compromise the distro that way TBH. 2FA won't stop that as they can just setup an actual 2FA token for their packaging account.

On 9/5/22 16:54, Maxwell G via devel wrote:

On Monday, September 5, 2022 Peter Robinson wrote:

...

it would probably be easier to join and become a packager by packaging a random leaf package no one would use, then as a packager pick up an random orphaned package that's in the core distro and then just compromise the distro that way TBH.

They wouldn't even need to pick up a core package. "Supplements: kernel" would get them far enough...

Only solution I know is to require review of certain changes to package dependencies, enforced by post-build automated checks. Not sure which changes should require such review.

On Sun, Sep 4, 2022 at 5:30 PM Michael Catanzaro mcatanzaro@gnome.org wrote:

And anybody who isn't willing .....

... or able (they are not free, and there may be other restrictions regarding crypto capable device export/import that can require a bit of hoop jumping due to sourcing site shrinkage, all of which does raise bars a bit higher)

... to buy a security key wouldn't be able to contribute to Fedora at all.

True, and we (as a community) need to understand and support all that wish to contribute, even if they do not have those means. But it is also true that the intent with passkey includes being able to use your (sufficiently modern) mobile device or computer as a source rather than just a physical key(*) (and while I have not tried it (so have no idea how complete/capable it is) I recall there is a golang implementation using your computers TPM2 chip that can be a fido2 authenticator "key" on Linux).

While we clearly are not *there* yet, we are getting closer every year where almost everyone has a usable authenticator available to them nearly all the time (typically carried around in their back pocket, or with the user's face staring at the screen).

(*) At the recent RSA conference I saw a live demo from a person with devices running iOS, Android, macOS and Windows (no Linux) which could transparently exchange credentials created via FIDO2/passkey technology (even the presenter was a bit surprised there was only a minor "demo effect" glitch since it was partially pre-GA code, but work it did).

On 06/09/2022 10:26, Ondrej Mosnáček wrote:

This is just not true. Anyone with an Android or iOS device can set up a software token via FreeOTP [1].

I'm OK with software 2FA authenticators, but they want to force everyone to use Fido2 compatible hardware tokens. $50/each.

On 06/09/2022 17:00, Gary Buhrmaster wrote:

mobile device

Requires proprietary Google services.

computer

Requires proprietary TPM 2.0 chip.

On 06/09/2022 18:36, Kevin Fenzi wrote:

For an OTP generating app? I don't see why it would...

No, for FIDO2 authentication.

On Tue, 2022-09-06 at 18:18 +0200, Vitaly Zaitsev via devel wrote:

On 06/09/2022 17:00, Gary Buhrmaster wrote:

...

mobile device

Requires proprietary Google services.

...

computer

Requires proprietary TPM 2.0 chip.

Hi,

Neither of this is true. For example, I use Raivo on my iOS device which isn't proprietary.

It seems that your concerns regarding 2FA are based on a number of misconceptions.

1. That it will cost money

You can generate TOTP codes using password generators, desktop apps, or even by hand in the command line. It's a simple algorithm that doesn't even require an Internet connection. However, in order for it to truly be 2FA, it should be on a separate device (i.e, your phone) though generating it on the desktop is what people do if they have no external device.

2. That the algorithm will pose problems in other countries

I'm aware of ITAR and munitions exports, but I'm not convinced SHA1 and HMAC poses as much of a problem as you say it does, even in Russia/China.

3. That it requires specialized hardware

Again, not true. See part 1. TOTP should work on any device regardless of the underlying hardware so long as it supports basic cryptographic primitives.

On Tue, Sep 6 2022 at 10:11:54 AM -0700, Adam Williamson adamwill@fedoraproject.org wrote:

i.e. it was specifically about moving away from allowing "simple TOTP/HOTP" 2FA, as it is phishable, and requiring webauthn, of which Vitaly's points are I believe accurate.

Yes indeed.

That said, I *think* it could be done entirely in software, as the browser doesn't actually know whether it's talking to real hardware or to software pretending to be real hardware, right? I don't know enough about FIDO2 to be sure, but I assume that it should be possible to do it. Using a hardware token is not actually the primary goal. The goal is to programatically enforce that the authentication token is keyed to the domain that is *actually* requesting authentication, as reported by the web browser, so the 2FA token that gets generated for the fake fedoraproject.org.evil would not be a valid 2FA token for the real fedoraproject.org.

Of course, hardware authenticators would be even more secure, and it sure seems pretty reasonable to expect that people with commit access to Fedora packages are able to purchase a $25 or 30€ security key [1][2]. You don't need to spend $50 for a simple security key. But this really only makes a difference if the packager's computer is compromised, and at that point we've probably already lost.

Any 2FA is better than no 2FA. Currently I do not have any 2FA enabled on my Fedora account because there's no way to disable it once enabled, and I'm afraid something will break, so I'm not brave enough to opt in. I highly doubt I'm alone here.

Michael

[1] https://www.yubico.com/product/security-key-nfc-by-yubico/ [2] https://shop.nitrokey.com/shop/product/nkfi2-nitrokey-fido2-55

On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:

On 06/09/2022 19:49, Michael Catanzaro wrote:

...

Of course, hardware authenticators would be even more secure, and it sure seems pretty reasonable to expect that people with commit access to Fedora packages are able to purchase a $25 or 30€ security key [1][2].

Having to pay even $25 for a hobby project is not acceptable, IMO. If you want to enforce such a policy, find sponsors and buy devices for all Fedora contributors.

Fedora must be looked at as more than just a "hobby project" even though it is a hobby for some.

It's an OS that many rely on and $25 is a somewhat trivial cost for improved security.

With your suggestion of sponsors to cover such devices - how does that work for new packagers? It seems pretty impossible to do such a thing and tons of money would simply be wasted on packagers that did very little to nothing after becoming a packager.

-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On 9/6/22 17:29, Alex Perez wrote:

Jonathan,

Your perspective on costs seems extremely developed-country-centric, and I'd like to suggest you check your (financial) privilege. I don't know where you're from; I'm from the US, but I am well aware of the reality of many open source contributors from countries where the exchange rate against the US dollar is awful.

You may not see this sort of cost as a barrier to contribution, but I can assure you that other casual contributors may, and likely would. You have to realize that the cost of the token isn't necessarily the only factor that contributes to the overall cost of obtaining such a device. International shipping costs can easily triple this dollar amount, to say nothing of other associated costs such as import duties, etc. There are plenty of countries where such tokens are not domestically available, and must be shipped from abroad.

This just isn't as simple or straightforward as you seem to want it to be. Erecting financial barriers to contribution is dangerous, and has unintended consequences.

Yes, this stinks.

Unfortunately, there are no good alternatives I am aware of. The closest I can think of is some form of software FIDO2 implementation. Qubes OS will hopefully have one eventually, but I am not sure if it will be usable outside of Qubes OS and maybe SpectrumOS. Another option is a TPM-based authenticator. Would this be acceptable?

On 9/14/22 03:51, Vitaly Zaitsev via devel wrote:

On 13/09/2022 23:50, Demi Marie Obenour wrote:

...

Another option is a TPM-based authenticator.  Would this be acceptable?

No. TPM 2.0 chip is a *proprietary* black box. Some of them have known critical security vulnerabilities[1].

OK, but so is every onther secure processor (yubikeys, finians, etc). At least TPM2 is ubiquitous, and watched/tested widely, and being improved as a result. The vulnerability you refer to was due to not encrypting LPC traffic between the motherboard and the TPM chip, which was apparently due to the implementation being lazy rather than a TPM deficiency. Traffic encryption is a standard protocol feature, and is increasingly being used.

On 06/09/2022 23:14, Jonathan Wright wrote:

Fedora must be looked at as more than just a "hobby project" even though it is a hobby for some.

There are many casual maintainers who maintain one or two packages. We shouldn't force them to leave Fedora.

It's an OS that many rely on and $25 is a somewhat trivial cost for improved security.

There are many contributors from countries where $25 is a lot. We shouldn't set up financial barriers. This is a dead end.

With your suggestion of sponsors to cover such devices - how does that work for new packagers? It seems pretty impossible to do such a thing and tons of money would simply be wasted on packagers that did very little to nothing after becoming a packager.

They will be able to request one after they get more than 2 packages.

On Wed, 7 Sept 2022 at 02:53, Adam Williamson adamwill@fedoraproject.org wrote:

On Wed, 2022-09-07 at 08:41 +0200, Vitaly Zaitsev via devel wrote:

...

On 06/09/2022 23:14, Jonathan Wright wrote:

...

Fedora must be looked at as more than just a "hobby project" even

though

...

...

it is a hobby for some.

There are many casual maintainers who maintain one or two packages. We shouldn't force them to leave Fedora.

...

It's an OS that many rely on and $25 is a somewhat trivial cost for

improved security.

...

There are many contributors from countries where $25 is a lot. We shouldn't set up financial barriers. This is a dead end.

I think we kind of have two competing factors here, and it's not much use Camp A saying "FACTOR A IS IMPORTANT!" and Camp B saying "NO FACTOR B IS IMPORTANT!" and that just going round in circles.

On the one hand, Fedora is not just a hobby project. It's an important upstream in the F/OSS ecosystem. Very important downstreams like CentOS, RHEL, Amazon Linux and others are built out of it. It's absolutely an attractive target for a supply chain attack. We have an ethical responsibility to the F/OSS community to harden ourselves against such attacks, and FIDO2 auth would be a good way to do that.

So I think all this focusing on FIDO2 as a requirement is the problem. We are looking at least 2-3 years before Fedora Infrastructure could actually support it at scale. This is not just technical support, but needing people to actually handle the problems. We have a hard enough handling OTP tokens that people put in and then immediately lose so can't log in or change their accounts. Dealing with 100 developers who only put one token on their system and then promptly lose it after going for a jog etc is going to be a nightmare. [I had to support scientists with one time tokens before, and it is a constant 'I lost my token and I need to be verified that I am who I am. Can I get a new token?' etc.]

So I am going to say I am in agreement with Vitaly that FIDO2 is not a solution we could support at this time. At most we could support HOTP via yubikey but we would need to be able to make sure 1. That we have some sort of '5 codes which can be used in case of emergency'. These are printed on a screen and that is it. 2. We make sure that people have 2 additional devices attached before OTP is 'enabled'.

Otherwise this is going to end in tears even before we tried to get 'FIDO2' set up.

On the other hand, you are correct that requiring people to either pay money or accept proprietary software at some level in order to contribute packages to Fedora would be a barrier to contribution, and barriers to contribution suck. We could maybe find a sponsor to send *existing* packagers a hardware token, but that still leaves the problem of what to do about *new* packagers - find a sponsor willing to mail a key to anyone who passes a package review? Well, maybe. What to do about country laws and export controls that have been brought up? That's another problem.

So, we are in a dilemma without a perfect solution. We either have to decide which factor is more important, or find some way to compromise/finesse things, like requiring FIDO2 auth only for provenpackagers. Or only for commits to critpath packages. (And then what to do about Supplements:-style attacks?)

The productive thing to do is discuss which factor is the most important, or what the best compromise would be. Not just have two sets of people keep repeating at each other that each factor exists. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On Wed, 2022-09-07 at 14:26 +0200, Petr Pisar wrote:

...

So I am going to say I am in agreement with Vitaly that FIDO2 is not a solution we could support at this time. At most we could support HOTP via yubikey but we would need to be able to make sure

1. That we have some sort of '5 codes which can be used in case of

emergency'. These are printed on a screen and that is it. 2. We make sure that people have 2 additional devices attached before OTP is 'enabled'.

Otherwise this is going to end in tears even before we tried to get 'FIDO2' set up.

Do people lose their tokens more often than forget their passwords? How do we deal with a forgotten password now https://accounts.fedoraproject.org/forgot-password/ask? Do we have to strenghten an authenticiation reset with the advent of tokens?

I'm asking because to me it seems that the problem as you painted it is not about having a token but about resetting authentication credentials.

Shouldn't we instead start with strengthening the credentials reset even for password-only authentication? I.e. disallowing the reset. Or enabling having multiple passwords.

-- Petr

The security is only as strong as the weakest link. Often times this is the password or the password reset password. For example, 2FA via SMS is deprecated, yet some websites allow you to fallback to SMS if you do not have TOTP available. This is more convenient for users, but horribly insecure (an attacker can just fallback to the more insecure option since it's available). The most secure option is to ONLY allow TOTP, for example, and once it's enabled, lock the user out if they lose access to their device. Typically companies will verify a user's identify if they need to reset their 2FA (technically insecure due to social engineering attacks, which is a problem as of recent). Given that Fedora is a community project, it may be more feasible to verify someone's identity than some random corporate support desk, but still suspectible to social engineering.

Anyway, users are always going to forget their passwords, lose their devices and want an easy way back in, but making the security weak to accomodate this just trains bad behaviors I think.

V Wed, Sep 07, 2022 at 08:53:15AM -0400, Stephen Smoogen napsal(a):

On Wed, 7 Sept 2022 at 08:27, Petr Pisar ppisar@redhat.com wrote:

...

Shouldn't we instead start with strengthening the credentials reset even for password-only authentication? I.e. disallowing the reset. Or enabling having multiple passwords.

Maybe. What work do you not want done in Fedora for the next couple of years to do this. There are a lot of 'OMG we need this' initiatives and very few volunteers who have the skill level to help anymore.

That said, having multiple passwords without additional tokens attached is a security nightmare. I have dealt with 6 systems which had them because people thought it would cut down work and it either ramped up work or ended up with security compromises which were horrible. Disallowing resets end up requiring about 2-3 people whose main job every couple of minutes is to go through some form to try and confirm a person is who they are and then reset manually. You are welcome to take that over as your full time job.

My idea of disallowing reset is no reset. That does not mean somobody will manually reset records in a database. It means no way. It means new account, a different login name and repeating the onboarding process (becoming a packager, nonresponsive process for the old account, overtaking orphaned packages).

-- Petr

On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote:

On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:

...

On 06/09/2022 19:49, Michael Catanzaro wrote:

...

Of course, hardware authenticators would be even more secure, and it sure seems pretty reasonable to expect that people with commit access to Fedora packages are able to purchase a $25 or 30€ security key [1][2].

I think most people would find it not reasonable for contributors to an open source project to pay any amount of cash, even $25, to gain packaging rights. That's tantamount to a membership or entrance fee.

While I think this discussion has gone off the rails, here are my thoughts: - Why such a focus on FIDO2? It seems that nobody has discussed any alternatives. FIDO2 isn't even necessarily universally acclaimed in the infosec space - Why such a focus on devices that cost money? I have 2FA enabled on my phone with a free open source TOTP app

Seems that Fedora also has no SOP in place for requisitions or funding devices for its members, otherwise I don't think this discussion would be taking place. Fedora should probably start there first, because once you talk about buying keys, do you also talk about buying Thinkpads and laptops that travel overseas to countries that are on US sanction lists (this is a slippery slope, but do you see where I'm going with this?)

I think mandating software 2FA at a minimum is not that big of a buy- in, anything beyond that poses major complications.

On Wed, 2022-09-14 at 02:46 -0400, Demi Marie Obenour wrote:

Because FIDO2 is not phishable.  TOTP and HOTP are.  The only other non-phishable authentication method is TLS client certificates and I would be fine with those.

I'm not entirely convinced. See this paper: https://eprint.iacr.org/2020/1298.pdf

On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:

On Wed, Sep 14 2022 at 06:58:12 AM +0000, Tommy Nguyen remyabel@gmail.com wrote:

...

I'm not entirely convinced. See this paper: https://eprint.iacr.org/2020/1298.pdf

I only read the abstract of this paper, but looks like the researchers have found that FIDO is indeed unphishable. Seems their attack relies on websites allowing downgrade to weaker forms of 2FA.

Yup. The thrust of the paper is: in the real world FIDO2 is usually deployed alongside older/weaker forms of 2FA, so an attacker can pretend to the victim that FIDO auth didn't work and convince them to try a weaker method instead, then phish that.

Which is a reasonable point, but not necessarily relevant to us. We *could* require only strong auth and not have weaker fallback methods.

On Wed, 2022-09-14 at 18:35 -0400, Simo Sorce wrote:

On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote:

...

On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:

...

On Wed, Sep 14 2022 at 06:58:12 AM +0000, Tommy Nguyen remyabel@gmail.com wrote:

...

I'm not entirely convinced. See this paper: https://eprint.iacr.org/2020/1298.pdf

I only read the abstract of this paper, but looks like the researchers have found that FIDO is indeed unphishable. Seems their attack relies on websites allowing downgrade to weaker forms of 2FA.

Yup. The thrust of the paper is: in the real world FIDO2 is usually deployed alongside older/weaker forms of 2FA, so an attacker can pretend to the victim that FIDO auth didn't work and convince them to try a weaker method instead, then phish that.

Which is a reasonable point, but not necessarily relevant to us. We *could* require only strong auth and not have weaker fallback methods.

So I have been thinking about this, how do you deal with the inevitable fact that keys get lost or stop working if there is no alternative authentication method?

I guess people can enroll 2 separate keys (if Feodra Infra will allow that), but not everyone has the means to do that.

Same way you deal with people losing their passwords or current 2FA tokens: slowly and awkwardly. Basically, have a human deal with it, and establish as best they can that the person claiming they lost their tokens really is the person who ought to have them.

Of course, if you do issue new tokens, send an alert about this to all known contact methods for the account, so if it *was* an Evil Person doing it, and the Evil Person hasn't also compromised all of those contact methods too, the Real Packager will know something funky has happened and - hopefully - reach out and get the account frozen again.

The hardcore way is to say "welp, too bad, your account's gone, create a new one and start over, including going through the maintainer process again", but that might be a bit *too* hardcore.

This is a perennial issue, though, and the weakest point of the whole FIDO2 concept overall, including in the way it's being promoted to a mass audience as password-less auth for everything. The official story is you should also enrol a backup phone or tablet or something that you keep at home, then if you lose your main phone, you can get into the system with the backup device, enrol a new main device, and unenrol the lost/stolen main device.

But if you *aren't* rich enough to have spare phones/tablets lying around the place, or you just manage to lose both, the story is basically "you go into an Apple store or call up Google or Samsung etc. and somehow convince them you are you and they will then auth a new device onto your account". So, awkward squishy human processes again.

On Wed, 14 Sept 2022 at 18:36, Simo Sorce simo@redhat.com wrote:

On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote:

...

On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:

...

On Wed, Sep 14 2022 at 06:58:12 AM +0000, Tommy Nguyen remyabel@gmail.com wrote:

...

I'm not entirely convinced. See this paper: https://eprint.iacr.org/2020/1298.pdf

I only read the abstract of this paper, but looks like the researchers have found that FIDO is indeed unphishable. Seems their attack relies on websites allowing downgrade to weaker forms of 2FA.

Yup. The thrust of the paper is: in the real world FIDO2 is usually deployed alongside older/weaker forms of 2FA, so an attacker can pretend to the victim that FIDO auth didn't work and convince them to try a weaker method instead, then phish that.

Which is a reasonable point, but not necessarily relevant to us. We *could* require only strong auth and not have weaker fallback methods.

So I have been thinking about this, how do you deal with the inevitable fact that keys get lost or stop working if there is no alternative authentication method?

Inevitable is usually about 4 to 5 emails a week to admin@fedorproject.org from someone unable to log in and saying they lost their phone, token or other things. This is out of the couple hundred accounts currently with two factor enabled.

I guess people can enroll 2 separate keys (if Feodra Infra will allow that), but not everyone has the means to do that.

Basically the system would have to enforce that you have to have a GPG key and verify that the system can decode a message from the person. Then all that security is left to how many developers set their gpg password to '123456' or 'password1' and then upload their secret keys to public websites so it is convenient for them. From relevant experience with Fedora, that number is non-zero.

On 14/09/2022 08:46, Demi Marie Obenour wrote:

The only other non-phishable authentication method is TLS client certificates and I would be fine with those.

Fedora used to have TLS client certificate authorization (in Koji), but this has been replaced by Kerberos.

since almost every laptop has a TPM.

In some countries (Russia, China and some other countries from the US export banlist) hardware TPMs are prohibited.

On ke, 14 syys 2022, Demi Marie Obenour wrote:

On 9/14/22 03:55, Vitaly Zaitsev via devel wrote:

...

On 14/09/2022 08:46, Demi Marie Obenour wrote:

...

The only other non-phishable authentication method is TLS client certificates and I would be fine with those.

Fedora used to have TLS client certificate authorization (in Koji), but this has been replaced by Kerberos.

Could Fedora turn on PKINIT or make TLS client certificate authentication an option again?

I think PKINIT support is active, otherwise you would not be able to use Anonymous PKINIT for FAST channel wrapping with OTP preauthentication.

All we need is a way to associate a trusted certificate with the user and have the trust between KDC cert and the client machine where you'd run kinit:

[1660786] 1663147221.189471: PKINIT client verified DH reply [1660786] 1663147221.189472: PKINIT client found id-pkinit-san in KDC cert: krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG [1660786] 1663147221.189473: PKINIT client matched KDC principal krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG against id-pkinit-san; no EKU check required [1660786] 1663147221.189474: PKINIT client used KDF 2B06010502030602 to compute reply key aes256-cts/1D6D [1660786] 1663147221.189475: Preauth module pkinit (17) (real) returned: 0/Success

The latter works fine, so we just need to have a certificate in the user account to use PKINIT, not Anonymous PKINIT. And since we have no direct access to FreeIPA server behind Fedora Accounts system, Fedora Accounts should be extended to allow adding a public certificate to the user's account.

Sadly, it cannot be just 'any' certificate, it has to be issued by a certificate authority that is trusted by the KDC as well. For example, by FreeIPA CA which is already ran by the Fedora project infrastructure team. An alternative is to set up certificate mapping and validating rules.

If someone from Fedora Accounts team wants to experiment with this, I can guide you what to do.

...

...

since almost every laptop has a TPM.

In some countries (Russia, China and some other countries from the US export banlist) hardware TPMs are prohibited.

Still, even a pure software FIDO2 implementation is much better than TOTP etc. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On ke, 14 syys 2022, Stephen Smoogen wrote:

On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy abokovoy@redhat.com wrote:

...

Sadly, it cannot be just 'any' certificate, it has to be issued by a certificate authority that is trusted by the KDC as well. For example, by FreeIPA CA which is already ran by the Fedora project infrastructure team. An alternative is to set up certificate mapping and validating rules.

If someone from Fedora Accounts team wants to experiment with this, I can guide you what to do.

There is no continual running Fedora Accounts 'team'. There are 2-3 system administrators split between releng, operations and continual firefighting. There are also a team of developers who are split between CentOS Stream initiatives and other work. Changes like this need to have more than just an 'oh I have finally an afternoon free where all the other crap in the build infra is actually working for once.. lets dive into IPA'

I understand all of that myself. I think what is important here is to plan to work together so that eventually we can implement this.

This whole thread is about agreeing or disagreeing whether Fedora as a project would want to have better security methods to identify and authenticate its contributors when performing tasks that have large impact.

If Fedora contributors would have had access to Fedora's FreeIPA web UI or IPA API directly, we wouldn't even need to have a conversation about PKINIT and certificates. We could have added instructions how to request and associate a certificate with your account. But since Fedora Accounts system is the frontend to Fedora Project's FreeIPA deployment, we cannot simply do that. However, FreeIPA-wise, smartcards are supported now for Kerberos authentication, so we as Fedora contributors could benefit from that.

I hope we can plan to work together on this improvement again, similar how we did with the initial rewrite of Fedora Accounts on top of FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, perhaps CPA team could consider scheduling this effort as part of the initiatives.

Let me round up methods that we have supported now or plan to add in Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to issuance of a Kerberos ticket that can be used for communicating with the rest of Fedora services: - basic password-based authentication - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an external RADIUS server for validation of a string passed as a 'password' or 'token' value - use of a certificate stored on a supported PKCS11 token (smartcard, softtoken (SoftHSMv2, NSS) or just in plain keypair files) - use of OAuth2 device authorization grant against some OAuth2 IdP (new in FreeIPA 4.9.10+) - (future) use of a FIDO2/WebAuthn token

Fedora accounts system implements the management of the first two methods right now.

As much as I enjoy better security, everyone should remember that the ones affected are either packagers who are volunteering to make spec files for software they need for something else.. or developers who only look at spec files as the last hassle they need to do before they can mark on their list 'shipped and done'. Most of them do not package/build things very often, and it takes years for them to get retrained when some change in the workflow occurs.

A particular benefit of using Kerberos authentication to Fedora services is that it does not need to change the workflow for all those things. Once you've got your ticket, it works against all the services you are allowed to access. Sure, actual process of obtaining that ticket might change -- like with 2FA token one needs to get a wrap ticket first -- but the rest is the same.

They are also the only ones around to do the work. Making workflow changes like adding certificates, tokens, etc may be needed but they are going to need a lot of documentation, continual training, and coaching to actually make function. If there is no staff or people available to do this, then the change will fail hard.

Do we have any statistics of how we stand now that Fedora Accounts is deployed for more than a year and people were enabled to use 2FA tokens through it?

On ke, 14 syys 2022, Kevin Fenzi wrote:

On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote:

...

On ke, 14 syys 2022, Stephen Smoogen wrote:

...

On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy abokovoy@redhat.com wrote:

...

Sadly, it cannot be just 'any' certificate, it has to be issued by a certificate authority that is trusted by the KDC as well. For example, by FreeIPA CA which is already ran by the Fedora project infrastructure team. An alternative is to set up certificate mapping and validating rules.

If someone from Fedora Accounts team wants to experiment with this, I can guide you what to do.

There is no continual running Fedora Accounts 'team'. There are 2-3 system administrators split between releng, operations and continual firefighting. There are also a team of developers who are split between CentOS Stream initiatives and other work. Changes like this need to have more than just an 'oh I have finally an afternoon free where all the other crap in the build infra is actually working for once.. lets dive into IPA'

I understand all of that myself. I think what is important here is to plan to work together so that eventually we can implement this.

Right and while I agree with what smooge says there, I'm definitely interested in improving things as we can. I really would prefer a detailed plan however, not 'lets enable everything we can and see what sticks'. :)

Oh, for sure 'enable everything' is not what I or others suggest either. ;)

...

This whole thread is about agreeing or disagreeing whether Fedora as a project would want to have better security methods to identify and authenticate its contributors when performing tasks that have large impact.

Yep. I'm in agreement that we want to... but there's always tradeoffs.

A few random things to mention:

• I don't think requiring FIDO2 for all packagers is tenable. It may

well be that we could get donations or funding to get hardware for all packagers, especially if we wait for the current inactive process to finish, but even so, we will run into problems of people who can't get one shipped to them or gets lost in the mail, etc. There would also be a delay "hey, you are now a packager, look for a token in the mail in the next few weeks before you can do anything"

Proven packagers seem to be a fair category to address. Also packagers responsible for security-related bits of the distribution. Compilers?

There is probably a value in defining what functions critical to have strongly authenticated and identified to the distribution at large. For example, right now even 2FA OTP requirement is not mandatory for certain package groups.

• I'd really prefer to avoid going back to certs. People have all kinds

of problems with certs. I think it would cause a lot of confusion. (Unless I am misunderstanding what use is proposed for them).

...

If Fedora contributors would have had access to Fedora's FreeIPA web UI

We actually do have external access to the web UI. We just don't advertise it much.

Ok, that's good to hear in case we need to experiment with our accounts before the Fedora Accounts UI is expanded to cover other authentication methods.

...

or IPA API directly, we wouldn't even need to have a conversation about PKINIT and certificates. We could have added instructions how to request and associate a certificate with your account. But since Fedora Accounts system is the frontend to Fedora Project's FreeIPA deployment, we cannot simply do that. However, FreeIPA-wise, smartcards are supported now for Kerberos authentication, so we as Fedora contributors could benefit from that.

What would this use of certificates do here? Authenticate you to get a kerberos ticket? Allow you to login to the account interface?

The former. I am only considering all of this to allow Kerberos authentication with stronger methods. Smartcards are more accessible these days than, say, FIDO2 tokens. A card reader cost is around 10EUR (Amazon.de gives me ~100 options of USB smartcard readers below 20EUR), a smartcard is typically your government-issued ID in many countries.

Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close enough to a lower boundary.

Anyway, using a soft-based smartcard e.g. using NSS database stored on a usb flash drive and accessible via PKCS11 could also be an option. The problem here is to attest to a server side it is protected by the client but this is a common problem to all different methods. Even storing a key-pair on your hard drive would work with Kerberos PKINIT without any problem.

CentOS folks still use certs for their koji: https://wiki.centos.org/Authentication#TLS_certificate (and thats using the same account system/ipa servers as fedora).

...

I hope we can plan to work together on this improvement again, similar how we did with the initial rewrite of Fedora Accounts on top of FreeIPA. Again, if this is deemed to be valuable to Fedora contributors, perhaps CPA team could consider scheduling this effort as part of the initiatives.

Yeah, I would like that. Perhaps we could setup a meeting soon and dicuss plans? I'm open to video meeting, but we could also do IRC to keep things more open...

I am open to it too, may be in couple weeks or so, to allow interested parties to prepare.

...

Let me round up methods that we have supported now or plan to add in Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to issuance of a Kerberos ticket that can be used for communicating with the rest of Fedora services:

• basic password-based authentication
• use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself - use of an

external RADIUS server for validation of a string passed as a 'password' or 'token' value

• use of a certificate stored on a supported PKCS11 token (smartcard, softtoken (SoftHSMv2, NSS) or just in plain keypair files)
• use of OAuth2 device authorization grant against some OAuth2 IdP (new in FreeIPA 4.9.10+)
• (future) use of a FIDO2/WebAuthn token

Fedora accounts system implements the management of the first two methods right now.

And possibly the 3rd...

What does 'device' mean in the 4th one? :)

It is part of OAuth 2.0 specifications, 'Device Authorization Grant flow' is defined by RFC 8628: https://www.rfc-editor.org/rfc/rfc8628. It is not a device in itself but rather a method for devices limited in expressive capabilities to get access to OAuth2-protected resources on behalf of a user.

We do have https pushes using oauth/oidc token right now.

That is different. Please watch our talk at the Nest for demo and explanations.

Also, once we upgrade src.fedoraproject.org/pkgs.fedoraproject.org from RHEL8 to RHEL9, it will be possible to use ecdsa-sk and ed25519-sk ssh keys and thus use FIDO2 for ssh actions if we wish.

This would be limited to SSH protocol access only. Probably OK but we want to improve on this for cases where you'd need to define higher standards on what is allowed to use to login and where. Fedora infrastructure has limited use for that for most of contributors (we are rarely getting logged to Fedora hosts ourselves) but removing a need to use passwords in sudo, for example, is a useful measure (we can achieve it already with pam_sss_gss and authentication indicators in Kerberos tickets).

...

...

As much as I enjoy better security, everyone should remember that the ones affected are either packagers who are volunteering to make spec files for software they need for something else.. or developers who only look at spec files as the last hassle they need to do before they can mark on their list 'shipped and done'. Most of them do not package/build things very often, and it takes years for them to get retrained when some change in the workflow occurs.

A particular benefit of using Kerberos authentication to Fedora services is that it does not need to change the workflow for all those things. Once you've got your ticket, it works against all the services you are allowed to access. Sure, actual process of obtaining that ticket might change -- like with 2FA token one needs to get a wrap ticket first -- but the rest is the same.

Yeah, it's much nicer when everything uses a standard thing and all the various flows stick to that. Right now our auth for commits to src.fedoraproject.org is anything but standard. https and ssh use different paths and this causes a bunch of confusion.

...

...

They are also the only ones around to do the work. Making workflow changes like adding certificates, tokens, etc may be needed but they are going to need a lot of documentation, continual training, and coaching to actually make function. If there is no staff or people available to do this, then the change will fail hard.

Do we have any statistics of how we stand now that Fedora Accounts is deployed for more than a year and people were enabled to use 2FA tokens through it?

I could try and gather some. What stats would be helpfull?

A particular argument by smooge and others was arount 'passwords or tokens being lost frequently'. I'd like to see how widespread is this problem. Can we collect stats on amount of requests to reset passwords, reset tokens, etc. for a period of a year or so?

On Thu, Sep 15, 2022 at 5:55 PM Kevin Fenzi kevin@scrye.com wrote:

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:

...

Proven packagers seem to be a fair category to address. Also packagers responsible for security-related bits of the distribution. Compilers?

Perhaps any packager who has a package in one of the critical path lists? That number (of package(r)s) may be a bit large, though, for an initial cut (as I recall, the total number of critical path packages is around 1000 in rawhide, although I have no idea how many packagers that is).

As far as I know, it's not possible to enforce otp per group is it? That would be a nice enhancement.

Especially if one would like that any enforcement be semi-automatic rather than one more manual step when adding people to groups.

...

Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close enough to a lower boundary.

Yeah, it will still be hard to require 100% of packagers, but it might be doable.

And, as has been previously pointed out, it is also possible (although depending on the implementation not as secure) to use other pkcs11 backends, including software implementations.

On Thu, Sep 15, 2022 at 6:58 PM Adam Williamson adamwill@fedoraproject.org wrote:

There's a kind of "surprising" property of the critical path list too - it contains some things you might not expect.

I was (initially) thinking of the critical-path-base list, but you are right that the critical path is in the eyes of the beholder.

Which I still would like to work on in some of my copious spare time.

If you find a source of copious spare time, please do pass it along.

Isn't peer review much better and easier solution over all? We could also require signed commits I guess.

Vít

Dne 15. 09. 22 v 20:36 Gary Buhrmaster napsal(a):

On Thu, Sep 15, 2022 at 5:55 PM Kevin Fenzi kevin@scrye.com wrote:

...

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:

...

Proven packagers seem to be a fair category to address. Also packagers responsible for security-related bits of the distribution. Compilers?

Perhaps any packager who has a package in one of the critical path lists? That number (of package(r)s) may be a bit large, though, for an initial cut (as I recall, the total number of critical path packages is around 1000 in rawhide, although I have no idea how many packagers that is).

...

As far as I know, it's not possible to enforce otp per group is it? That would be a nice enhancement.

Especially if one would like that any enforcement be semi-automatic rather than one more manual step when adding people to groups.

...

...

Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close enough to a lower boundary.

Yeah, it will still be hard to require 100% of packagers, but it might be doable.

And, as has been previously pointed out, it is also possible (although depending on the implementation not as secure) to use other pkcs11 backends, including software implementations. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Hi,

On September 16, 2022 5:03:03 PM UTC, Kevin Fenzi kevin@scrye.com wrote:

On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:

...

Isn't peer review much better and easier solution over all? We could also require signed commits I guess.

I think it would slow things down quite a lot to require peer review of every commit.

It would a bit, but it is doable. openSUSE tumbleweed works like that: every commit that is sent into the rolling distro is reviewed by the release managers. It adds some overhead and it would most certainly require dedicated reviewers and additional tooling.

I'd personally like to avoid anything where we need to support gpg. It's a mess and I think it would waste a lot of cycles explaining how to use it or help people get setup. ;( If there's some easier/more clear way to sign things that could be a option tho.

kevin

Kevin Fenzi wrote:

On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:

...

Isn't peer review much better and easier solution over all? We could also require signed commits I guess.

I think it would slow things down quite a lot to require peer review of every commit.

I'd personally like to avoid anything where we need to support gpg. It's a mess and I think it would waste a lot of cycles explaining how to use it or help people get setup. ;( If there's some easier/more clear way to sign things that could be a option tho.

Since git-2.34 (released in November of last year), ssh may be used for signing commits and/or pushes. That's likely a bit simpler than gpg.

On the other hand, if it's cached by ssh-agent and/or uses the same key used to connect to dist-git, it might not add as much to the security as we might want.

But it may be an option, in case it spurs anyone to come up with a change which improves security and doesn't add too much additional burden.

You mentioned ecdsa-sk / ed25519-sk FIDO authenticator algorithms earlier. Git ssh-signed commit/push might be useful if/when other parts of our infrastructure can make use of those key types.

On Thu, Sep 15, 2022 at 11:54:13AM -0700, Adam Williamson wrote:

On Thu, 2022-09-15 at 10:55 -0700, Kevin Fenzi wrote:

...

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:

...

Proven packagers seem to be a fair category to address. Also packagers responsible for security-related bits of the distribution. Compilers?

Well, as others noted in this thread, any packager has a lot of power. They can add a weak dep on something everyone has installed and pull their package in. Of course they likely only get to do that once.

I kinda feel like we really ought to just stick a check for this *somewhere*. An alert should pop up somewhere any time anyone adds a Supplements: line to *anything*. It's a sufficiently odd thing to do that it shouldn't happen very often, I think...

I suspect in the past the answer to this would be "Patrick probably does it already". Did we find a Patrick 2.0 yet? :D

Ha. no.

There is a hook we have that notifies people when someone adds an exclude/exclusivearch. We could make another one that checks for Suggests I suppose.

They could just add Requires tho, or add something that makes the auto dep generating scripts add a requires or suggests.

So, perhaps a CI check would be better, to check the actual produced binary package.

kevin

On Thu, Sep 15, 2022 at 04:34:08PM -0400, Demi Marie Obenour wrote:

On 9/15/22 13:55, Kevin Fenzi wrote:

...

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:

...

Proven packagers seem to be a fair category to address. Also packagers responsible for security-related bits of the distribution. Compilers?

Well, as others noted in this thread, any packager has a lot of power. They can add a weak dep on something everyone has installed and pull their package in. Of course they likely only get to do that once.

...

There is probably a value in defining what functions critical to have strongly authenticated and identified to the distribution at large. For example, right now even 2FA OTP requirement is not mandatory for certain package groups.

As far as I know, it's not possible to enforce otp per group is it? That would be a nice enhancement.

Additionally, right now, packagers commit with ssh keys or oidc tokens, in order for a 2fa setup to be effective, we would need to switch that to kerberos or the like.

SSH keys are fine.

Sure, but unless you are using ecdsa-sk or ed25519-sk keys, they aren't 2factor enabled. Your account could be using OTP, but if someone gets your ssh private key they can commit as you.

kevin

On Fri, Sep 16, 2022 at 10:29:17AM +0300, Alexander Bokovoy wrote:

One thing I want to get properly implemented in SSSD in upcoming FIDO2 support is to allow admins to filter out certain types of public SSH keys associated with the user account. E.g. get a way for administrator to say 'only FIDO2 keys and their OpenSSH equivalents (ecdsa-sk, ed25519-sk) allowed for these users' and let SSSD's sss_ssh_authorized_keys to filter all other types. Then your git server could be able to deny non-FIDO2 SSH keys on per-user base.

That would be cool.

Even better IMHO would be support for ssh certs. ie, auth with your FIDO2 key/otp and you get a ssh cert thats has a time limit / other restrictions for just pushing git commits, etc.

FreeIPA Kerberos already gives you this feature for various authentication methods[1] but it is not integrated in OpenSSH's GSSAPI support.

[1] https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy....

...

...

these days than, say, FIDO2 tokens. A card reader cost is around 10EUR (Amazon.de gives me ~100 options of USB smartcard readers below 20EUR), a smartcard is typically your government-issued ID in many countries.

Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close enough to a lower boundary.

Yeah, it will still be hard to require 100% of packagers, but it might be doable.

Solving this is a social problem. I'd like to remove technical roadblocks so that we can better focus on the solutions to social problems. Right now we aren't there on both sides.

Agreed.

...snip...

Sure. I guess we can aim last week of October. I'll write up a call for participation next week.

Thanks.

...

...

...

...

Do we have any statistics of how we stand now that Fedora Accounts is deployed for more than a year and people were enabled to use 2FA tokens through it?

I could try and gather some. What stats would be helpfull?

A particular argument by smooge and others was arount 'passwords or tokens being lost frequently'. I'd like to see how widespread is this problem. Can we collect stats on amount of requests to reset passwords, reset tokens, etc. for a period of a year or so?

We currently have 1560 tokens enrolled. (Of course some users have more than one, but most seem to have one)

In the 1 year period from 2021-07-01 to 2022-07-01 we had 87 requests to reset otp. Some of these were people who were confused and didn't actually even have a otp enabled, but it's hard to count those without going through each request.

So, it's less than 5% a year it seems like, or a request every 4days if they were evenly spaced.

Thank you. This is actually better than I expected to see. Improving technical measures and UX should help but there always will be something that is harder to deal with, anyway.

I'll also note that I think many more of them came toward the first part of that time period. We made some changes to the interface that helped a good deal. At first we had a mailto: link and got a bunch of blank emails (bots just following the link? confused users?) https://github.com/fedora-infra/noggin/issues/678

So, it might be interesting to see how things look after that change landed.

kevin

TLS client certificates is actually not a terrible idea. They're not very popular anymore, but they're supported by all major browsers (I think?) and they work.

On Wed, Sep 14 2022 at 02:08:32 PM +0200, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:

On 14/09/2022 10:01, Demi Marie Obenour wrote:

...

Still, even a pure software FIDO2 implementation is much better than TOTP etc.

I don't think so. Malware can easily steal the private key. Simple TOTP on a separate device is much better.

Well they're different threats with different solutions. Installing malware on users' computers is a lot harder than phishing them, so I'd much rather see software-based FIDO2 than TOTP on a separate device. At least I'm not aware of any malware running on my computer, but I already confessed to entering a password into a phishing website, so we know you can phish me at least. If you want to protect against *both* threats, use a security key, but you've already pushed back against requiring a hardware purchase.

It's impossible to enforce use of a separate device regardless of whether you're doing TOTP or FIDO2. I use my Yubikey only for my highest-security work account. Everything else uses a TOTP app running on-device, vulnerable to malware. (I don't want to buy a smartphone just to do TOTP: no way. A $25 security key sounds much more reasonable.)

Michael

On 9/13/22 21:37, Tommy Nguyen wrote:

On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote:

...

On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:

...

On 06/09/2022 19:49, Michael Catanzaro wrote:

...

Of course, hardware authenticators would be even more secure, and it sure seems pretty reasonable to expect that people with commit access to Fedora packages are able to purchase a $25 or 30€ security key [1][2].

I think most people would find it not reasonable for contributors to an open source project to pay any amount of cash, even $25, to gain packaging rights. That's tantamount to a membership or entrance fee.

There is a huge difference between accepting contributions from someone and trusting them with access to a vast number of people’s machines. Qubes OS accepts contributions from untrusted contributors, but it can only do so because all code is reviewed by hand before merging, so a malicious contribution simply will not be accepted. Fedora, on the other hand, lacks any means to limit the blast radius of a compromised account with packaging rights. Therefore, preventing such a compromise is critical, and hardware authenticators are currently the best means of doing so.

In the long term, Fedora should figure out how to avoid having to trust such a large number of people with such power. But for now, requiring **unphishable** 2FA is the best option I am aware of.

On Tuesday, September 6, 2022 Michael Catanzaro wrote:

Currently I do not have any 2FA enabled on my Fedora account

I have 2FA set up on my account and it works okay. You'd use `fkinit` instead of `kinit` that requires special setup[1] to work with 2FA. It doesn't work with the GOA kerberos integration. When authenticating with Fedora online services, there's a field for the token just like on any other site that supports 2FA.

because there's no way to disable it once enabled, and I'm afraid something will break, so I'm not brave enough to opt in. I highly doubt I'm alone here.

I'd guess that Infrastructure could disable it for you if you enable it and then change your mind.

[1]: https://fedoraproject.org/wiki/Infrastructure/ Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure

On Tue, Sep 6 2022 at 10:53:03 PM -0500, Maxwell G gotmax@e.email wrote:

I have 2FA set up on my account and it works okay. You'd use `fkinit` instead of `kinit` that requires special setup[1] to work with 2FA. It doesn't work with the GOA kerberos integration. When authenticating with Fedora online services, there's a field for the token just like on any other site that supports 2FA.

OK, well thanks for confirming my worst fears. :/ I'm not interested in manual use kinit or fkinit (which I've never heard of). Needs smooth integration with gnome-online-accounts.

On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote:

...

mobile device

Requires proprietary Google services.

As has already been said, that's not true. Google Authenticator is far from the only software that supports the TOTP standard.

On su, 04 syys 2022, Gary Buhrmaster wrote:

On Sun, Sep 4, 2022 at 3:52 PM Adam Williamson adamwill@fedoraproject.org wrote:

...

Well, not really. 2FA isn't a magic bullet. I would be in favor of doing this, but you can't treat any security measure as solving all your problems completely.

Nothing is a magic bullet (and most security can be bypassed with the $10 (it was $5 before inflationary increase) wrench) but passkeys (which can eliminate passwords entirely) do tend to raise the bar substantially, and those services doing authorization can require additional levels of real time identity assurance for additional levels of access (so inserting a usb token, or having your phone nearby, might let you login, but you need to provide additional something (pin, biometrics, whatever) to access things at a higher level at the time you require that (say, for this case, using PP powers)).

However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*).

FreeIPA 4.9.10+ supports integration with an external OAuth2 identity provider (IdP). It needs OAuth2 device authorization grant flow support from IdP which Ipsilon does not support but Keycloak or any of major public IdPs aside from Gitlab do support. Keycloak does support FIDO2/WebAuthn too, so FreeIPA in Fedora 36 or later can be set up to operate with WebAuthn and no passwords in your own deployments. Fedora AAA uses RHEL IdM as a backend and there this feature is coming in next minor RHEL releases.

It is not fully functional yet but for Fedora AAA use-case things are there with FreeIPA side. For Fedora users it would look like similar to the current Kerberos flow: (1) obtain an anonymous PKINIT ticket to use as a FAST channel, and (2) attempt to authenticate to Fedora KDC. If sssd-idp subpackage is installed and your Fedora AAA account is configured to use external IdP for your access authorization, then you'd be asked to visit a URL where you'd authenticate and then grant that authorization to Fedora AAA system. This IdP can be something that Ipsilon could federate to purely for the user authentication purposes.

This is not implemented in Fedora AAA yet.

You might want to watch our Nest with Fedora 2022 talk. More features are coming too, we are working on a direct FIDO2 integration in SSSD and FreeIPA, but a lot of help is needed from desktop folks as well to make it usable for login to graphical environments. GDM login is ugly right now as a message we push through PAM prompts is simply not fitting into GDM input boxes and you don't know where to go for your IdP access.

See https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.ht... for practical workshop details on how to set and use this in FreeIPA.

Nest With Fedora's talk replay is available here: https://app.hopin.com/events/nest-with-fedora-2022/replay/Um91bmR0YWJsZVJlY2... (skip to 8:55 or so to the talk's start).

Slides can be found here but the talk also has several demos: https://vda.li/talks/2022/2022-Nest-With-Fedora-FreeIPA-and-OAuth2.pdf

(*) Given that all the major tech companies are moving towards allowing (and will be encouraging) customers to use passkeys I hope we will see better integrations with FreeIPA and Ipsilon at some point.

Ipsilon is orphaned in Fedora. If not picked up, it will disappear. It would be sad but a practical issue is that upstream seem to be less active too. Not sure how it goes but given that Fedora AAA is deployed or going to be eventually deployed in a containerized way, then probably focusing on another feature rich open source IdP could be a better option.

Il 04/09/22 00:01, Adam Williamson ha scritto:

On Sat, 2022-09-03 at 13:04 -0700, Kevin Fenzi wrote:

...

On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote:

...

So, I have a probably-controversial idea for a follow-up on this.

Even after this sweep, we have 141 proven packagers. That's a lot of people who can build almost anything in Fedora.

It should be possible to check whether a provenpackager has built any package they don't have direct commit rights to in the last X months.

Should we construct that search, run it, and propose removing provenpackager status from folks who aren't using it, to cut down that set?

That policy was setup before this one for packagers. ;)

https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

Look, I'm getting old, okay? ;)

But yeah, looking at that, one 'loophole' is it doesn't check if they're actually needing *proven* packager powers - just packager powers. If a proven packager is only building packages they have explicit commit rights to, they may not need proven packager powers any more?

I sometimes use my PP powers to fix build tagging issues / updates flows caused by Bodhi glitches, but I (very) rarely use them to build someone else package.

What I mean is whatever test is done to check if someone needs to be PP doesn't assume the power is just used to build packages.

Mattia

Just very minor contribution to alrready very complex trhead.

- to remove packager status if they are not using it, is just wrong. OpenJDK was using it far years and it really did not proved itself. Now OpenJDK have policy, that once you earn any status, you remain with it. The downgrade or no longer propagated status (eg form project to project) was super confussing and made more issues then it solved. Now it is much better.

- to remove proven packager status, if they are nto using proven packagers powers, is similarly wrong. Well, if there is email with deadlnie.. then maybe... As for my case - I'm not using my proven packager powers, but once per two years, I'm bumping system JDK. And n that moment I'm using my proven packager skill heavily. So hard timeout, would again do just confussion (like negotiating proven packager status again 5 minutes before dealines)

I belive all liek thsi was already said.... Thanx all for making fedora just better and better!

J.

On 9/3/22 22:04, Kevin Fenzi wrote:

On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote:

...

So, I have a probably-controversial idea for a follow-up on this.

Even after this sweep, we have 141 proven packagers. That's a lot of people who can build almost anything in Fedora.

It should be possible to check whether a provenpackager has built any package they don't have direct commit rights to in the last X months.

Should we construct that search, run it, and propose removing provenpackager status from folks who aren't using it, to cut down that set?

That policy was setup before this one for packagers. ;)

https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

kevin

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Il 05/09/22 08:59, Brian (bex) Exelbierd ha scritto:

On Sat, Sep 3, 2022 at 9:24 PM Adam Williamson adamwill@fedoraproject.org wrote:

...

On Thu, 2022-08-18 at 17:28 -0400, Ben Cotton wrote:

...

Hello everyone!

I just completed the first run of FESCo's newly approved Inactive Packager Policy[1]. Packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the F37 final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.)

So, I have a probably-controversial idea for a follow-up on this.

I'll add one more idea/loophole to consider closing. I am a member of the packager group but no longer maintain any packages. I am active enough in other ways to not be noticed by this policy. I don't think that is right.

I'm sorry for that. The script currently searches for user activity in src.fp.o, pagure.io, Bodhi, Bugzilla and Fedora mailing lists. Can you tell me where you're active, so, maybe, I can add that place in the search pattern?

I have submitted a ticket to voluntarily give up my packager rights under this policy. However, we should probably verify that a packager actually has at least one package or is a proven packager as a part of this policy. I realize that it is very hard to know how long someone has not had any packages, so this could result in a request to validate to a person who is temporarily without a package during the period when the script is run, however I think this is a reasonable edge case to resolve manually.

regards,

bex

I don't agree with that. If a user haven't got any commit right to any package, they don't need to be in the packager group, that's exactly the scope of this policy. Maybe they left years ago, their commit rights were removed, but they never have been removed from packagers.

Mattia