Just being paranoid here: do we have any policy / automatism for disabling "power" users (in packager group or like) which have been inactive for long time?
I'm no security expert, but an inactive user account may be hacked without noticing and if such account have powers like being in the packager group may inject bad things in the distribution. I also imagine the case where a user no more use their email address and that become available to someone else. The new user may easily reset the password and gain access to the old Fedora account (provided that the old user didn't use 2fa).
Does it make sense to start thinking to prune inactive packagers without waiting someone to start the "unresponsive maintainer policy"? Maybe a script could check user activities in src.fedoraproject.org and send a warning email if no activity is made in one year?
Mattia
Mattia Verga via devel devel@lists.fedoraproject.org writes:
Just being paranoid here: do we have any policy / automatism for disabling "power" users (in packager group or like) which have been inactive for long time?
I'm no security expert, but an inactive user account may be hacked without noticing and if such account have powers like being in the packager group may inject bad things in the distribution. I also imagine the case where a user no more use their email address and that become available to someone else. The new user may easily reset the password and gain access to the old Fedora account (provided that the old user didn't use 2fa).
Does it make sense to start thinking to prune inactive packagers without waiting someone to start the "unresponsive maintainer policy"? Maybe a script could check user activities in src.fedoraproject.org and send a warning email if no activity is made in one year?
Sounds like a good idea to me and waiting for a year of inactivity is imho a reasonable amount of time, if we give them enough time to respond *and* also provide a way to reactivate a deactivated account.
Cheers,
Dan
On Wed, 2022-02-09 at 07:03 +0000, Mattia Verga via devel wrote:
Just being paranoid here: do we have any policy / automatism for disabling "power" users (in packager group or like) which have been inactive for long time?
Yes.
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaini... https://pagure.io/fesco/issue/2549 (ticket where the policy was approved)
The audit described there was done once last February after the policy was approved. It does not seem to have been done when F35 branched, though (unless the audit turned up no further dormant provenpackagers and thus no mail was sent). Ben, I guess it should be done now for F36 branching? And added to some TODO list, if it was really missed last time?
On Wed, Feb 9, 2022, 02:54 Adam Williamson adamwill@fedoraproject.org wrote:
The audit described there was done once last February after the policy
was approved. It does not seem to have been done when F35 branched, though (unless the audit turned up no further dormant provenpackagers and thus no mail was sent). Ben, I guess it should be done now for F36 branching? And added to some TODO list, if it was really missed last time?
Way ahead of you. It was missed last time, so I added it to the schedule. Coincidentally, today is the day I do it.
https://fedorapeople.org/groups/schedule/f-36/f-36-pm-tasks.html
On Wed, Feb 9, 2022 at 7:25 AM Ben Cotton bcotton@redhat.com wrote:
It was missed last time,
Now that I've had my coffee I want to correct my use of the passive voice. *I* missed it last time. Carry on.
Il 09/02/22 08:54, Adam Williamson ha scritto:
On Wed, 2022-02-09 at 07:03 +0000, Mattia Verga via devel wrote:
Just being paranoid here: do we have any policy / automatism for disabling "power" users (in packager group or like) which have been inactive for long time?
Yes.
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaini... https://pagure.io/fesco/issue/2549 (ticket where the policy was approved)
That is referring to provenpackagers only. I'd like this to be extended to users in packagers group also.
For example, if someone pulls from src.fedoraproject.org a list of users in the packagers group which have been inactive for a long time, check if their email is inactive and if it has been made available for claiming, then they claim the email and reset the Fedora account password to gain access in that account...
Mattia
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
That is referring to provenpackagers only. I'd like this to be extended to users in packagers group also.
Given that provenpackagers are group that can do the most potential damage, that process arguably covers the users in the true "power" group in your initial email. Users not in the provenpackagers group have a relatively small blast radius.
Perhaps that list of users to "ping" once a release should be extended to eventually include those whose packages are in the @core or @critical-path-base groups, but I would not be at all surprised if most of those people are not already provenpackagers, so they are already covered.
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
That is referring to provenpackagers only. I'd like this to be extended to users in packagers group also.
FWIW, the last time this came up, there was a vague idea to require a yearly resigning of the CLA (or something equivalent, but the CLA signing was already in there).
However, no one made a formal proposal to (I think) FESCo to approve such a new process.
Perhaps you should start that process with a formal (proposed) process to FESCo. The provenpackager process might provide a reasonable starting point for proposed changes to policy;
https://pagure.io/fesco/issue/2549
I will note that (as previously documented) there was a proposal over 10 years ago:
https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=Jes...
So, please, make a formal FESCo proposal. That is the way to get things moving forward.
On Thu, Feb 10, 2022 at 03:01:25AM +0000, Gary Buhrmaster wrote:
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel devel@lists.fedoraproject.org wrote:
That is referring to provenpackagers only. I'd like this to be extended to users in packagers group also.
Ben,
since you have the script handy, could you check how many (non-pp) packagers would be reported as inactive pretty please? Maybe with the inactivility threshold raised to 1 year instead of 0.5 y.
I think that if we disabled completely inactive accounts after a year or two, this would be reasonable from security perspective. There are many many packages which are now maintained by other people so packagers can effectively maintain co-ownership without committing to a package for years.
Zbyszek
On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
since you have the script handy, could you check how many (non-pp) packagers would be reported as inactive pretty please? Maybe with the inactivility threshold raised to 1 year instead of 0.5 y.
I had to run it a second time with the listing disabled because the first time the output was too long for my terminal's scrollback. :-)
But! Of 2453 packagers, 1514 have not submitted a Koji build since at least 2021-02-11. 1311 of those have not submitted a Koji build since at least 2020-02-06. An additional 113 do not exist in Koji.
I think that if we disabled completely inactive accounts after a year or two, this would be reasonable from security perspective. There are many many packages which are now maintained by other people so packagers can effectively maintain co-ownership without committing to a package for years.
I have concerns with this approach. I would guess there's a long tail of packagers that maintain relatively few packages. These packages might not have frequent upstream releases or require new manual builds. Someone who hasn't needed to build a package in 13 months may still be active in other ways and it would be hostile to strip them of packager permission in that case. We'd want to be very careful about how we define "active" (which is a thorny question project-wide that we don't have a great answer for). We'd also want to give people the chance to say "no, I'm still here", which makes this a fairly manual process. If we were to automate it, we absolutely should have a trivial way for people to regain packager status (i.e. not have to get re-sponsored, etc).
I would support removing the 113 who don't exist in Koji. And maybe any packagers without a build over an exceedingly long period of time (say 5 years?) as a starting point.
-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis
On Thu, 2022-02-10 at 16:57 -0500, Ben Cotton wrote:
On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
since you have the script handy, could you check how many (non-pp) packagers would be reported as inactive pretty please? Maybe with the inactivility threshold raised to 1 year instead of 0.5 y.
I had to run it a second time with the listing disabled because the first time the output was too long for my terminal's scrollback. :-)
But! Of 2453 packagers, 1514 have not submitted a Koji build since at least 2021-02-11. 1311 of those have not submitted a Koji build since at least 2020-02-06. An additional 113 do not exist in Koji.
I think that if we disabled completely inactive accounts after a year or two, this would be reasonable from security perspective. There are many many packages which are now maintained by other people so packagers can effectively maintain co-ownership without committing to a package for years.
I have concerns with this approach. I would guess there's a long tail of packagers that maintain relatively few packages. These packages might not have frequent upstream releases or require new manual builds. Someone who hasn't needed to build a package in 13 months may still be active in other ways and it would be hostile to strip them of packager permission in that case. We'd want to be very careful about how we define "active" (which is a thorny question project-wide that we don't have a great answer for). We'd also want to give people the chance to say "no, I'm still here", which makes this a fairly manual process. If we were to automate it, we absolutely should have a trivial way for people to regain packager status (i.e. not have to get re-sponsored, etc).
I would support removing the 113 who don't exist in Koji. And maybe any packagers without a build over an exceedingly long period of time (say 5 years?) as a starting point.
Some may be backups for others, and do not normally create builds but collaborate to the maintenance via patches.
Simo.
On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton bcotton@redhat.com wrote:
I have concerns with this approach. I would guess there's a long tail of packagers that maintain relatively few packages. These packages might not have frequent upstream releases or require new manual builds.
There are a lot of packages in Fedora that are, for all practical purposes, "functionally stabilized" upstream. They get recompiled at the mass rebuild, but otherwise are in "if it ain't broke, don't fix it" mode (upstream and packaging). And that seems fine to me.
If we were to automate it, we absolutely should have a trivial way for people to regain packager status (i.e. not have to get re-sponsored, etc).
The question is then what are you protecting against? If you can reset your password (via email link), and then click a button that says "I'm BACK!", you return to the original concern that was raised about whether this is really the same person you think it is.
I don't have a good answer to the problem space of knowing what it means to be active or otherwise engaged given the highly distributed nature of the community (99.999% of the people I interact with on this community I never have, and likely never will, meet in person, or in any other way to know who they really are, or whether they are different now, and "On the Internet, no one knows you are a dog" (Woof?)).
Perhaps *an* approach to identify inactive packagers is for packages that have enabled release monitoring (and more probably should be), and for which new upstream releases have been identified, and the packager has not yet taken the steps to at least start to update to that new release in a reasonable timeframe (12 months?). A quick (and likely bad and incomplete) bugzilla search shows over 1000 tickets where there are upstream updates that are still in NEW status in bugzilla and had been (initially) opened over a year ago. I think that represents around 350 unique people. Those people may be otherwise active, of course, but those packages themselves look to be under maintained.
On Thu, Feb 10, 2022 at 11:05:03PM +0000, Gary Buhrmaster wrote:
On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton bcotton@redhat.com wrote:
I have concerns with this approach. I would guess there's a long tail of packagers that maintain relatively few packages. These packages might not have frequent upstream releases or require new manual builds.
There are a lot of packages in Fedora that are, for all practical purposes, "functionally stabilized" upstream. They get recompiled at the mass rebuild, but otherwise are in "if it ain't broke, don't fix it" mode (upstream and packaging). And that seems fine to me.
If we were to automate it, we absolutely should have a trivial way for people to regain packager status (i.e. not have to get re-sponsored, etc).
The question is then what are you protecting against? If you can reset your password (via email link), and then click a button that says "I'm BACK!", you return to the original concern that was raised about whether this is really the same person you think it is.
You are right, it seems hard to do this in a way that has an actual effect without offending real people. But I think we should try to find some way. With 1500+ unused accounts it is just *too easy* for someone to find a way to access one of the accounts in an unauthorized way. Essentially, if you get access to one the email accounts, you can reset the FAS password. I'd guess that a large fraction of those mail addresses are on univerisities all around the world, and somebody might do it just for kicks.
In particular, if we removed the 'packager' bit, people would still have the account and all history associated with it. If they ever want to starting doing packaging work directly (because note that they don't actually need it if they're active but somebody else is submitting the builds), I think a manual procedure where you have to e.g. open a ticket on sponsors tracker to ask to be reinstantated would be OK.
Perhaps *an* approach to identify inactive packagers is for packages that have enabled release monitoring (and more probably should be), and for which new upstream releases have been identified, and the packager has not yet taken the steps to at least start to update to that new release in a reasonable timeframe (12 months?). A quick (and likely bad and incomplete) bugzilla search shows over 1000 tickets where there are upstream updates that are still in NEW status in bugzilla and had been (initially) opened over a year ago. I think that represents around 350 unique people. Those people may be otherwise active, of course, but those packages themselves look to be under maintained.
Such "dead" packages are a problem in their own… At least we're doing much better now with orphanining unbuildable packages than a few years ago. I think a good direction here would be to automatically connect more packages to package-monitoring.
Zbyszek
Il 11/02/22 07:54, Zbigniew Jędrzejewski-Szmek ha scritto:
On Thu, Feb 10, 2022 at 11:05:03PM +0000, Gary Buhrmaster wrote:
On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton bcotton@redhat.com wrote:
I have concerns with this approach. I would guess there's a long tail of packagers that maintain relatively few packages. These packages might not have frequent upstream releases or require new manual builds.
There are a lot of packages in Fedora that are, for all practical purposes, "functionally stabilized" upstream. They get recompiled at the mass rebuild, but otherwise are in "if it ain't broke, don't fix it" mode (upstream and packaging). And that seems fine to me.
If we were to automate it, we absolutely should have a trivial way for people to regain packager status (i.e. not have to get re-sponsored, etc).
The question is then what are you protecting against? If you can reset your password (via email link), and then click a button that says "I'm BACK!", you return to the original concern that was raised about whether this is really the same person you think it is.
You are right, it seems hard to do this in a way that has an actual effect without offending real people. But I think we should try to find some way. With 1500+ unused accounts it is just *too easy* for someone to find a way to access one of the accounts in an unauthorized way. Essentially, if you get access to one the email accounts, you can reset the FAS password. I'd guess that a large fraction of those mail addresses are on univerisities all around the world, and somebody might do it just for kicks.
In particular, if we removed the 'packager' bit, people would still have the account and all history associated with it. If they ever want to starting doing packaging work directly (because note that they don't actually need it if they're active but somebody else is submitting the builds), I think a manual procedure where you have to e.g. open a ticket on sponsors tracker to ask to be reinstantated would be OK.
This is exactly my point of view. My proposal wasn't meant for kicking off anyone, I was just proposing a periodic check of who's still overseeing their account.
I'll try to write down a quick script which should expand the one from Ben by looking for any activity in the last year in src.fedoraproject.org instead of Koji, then check those users for any activity in Fedora (datagrepper?).
For the identified users with no activity, I suppose that sending one email per year asking "hey, is this still your email account and are you still engaged in Fedora packaging" would be no harm. And, if no reply is received after an adequate period (2 weeks?), removing the "packager" bit from the account would be no harm as well. I'm not proposing to delete their account.
The only issue would be how to handle packages that are maintained from such users, I think they'd need to be orphaned.
Mattia
Mattia Verga via devel devel@lists.fedoraproject.org writes:
Il 11/02/22 07:54, Zbigniew Jędrzejewski-Szmek ha scritto:
On Thu, Feb 10, 2022 at 11:05:03PM +0000, Gary Buhrmaster wrote:
On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton bcotton@redhat.com wrote:
I have concerns with this approach. I would guess there's a long tail of packagers that maintain relatively few packages. These packages might not have frequent upstream releases or require new manual builds.
There are a lot of packages in Fedora that are, for all practical purposes, "functionally stabilized" upstream. They get recompiled at the mass rebuild, but otherwise are in "if it ain't broke, don't fix it" mode (upstream and packaging). And that seems fine to me.
If we were to automate it, we absolutely should have a trivial way for people to regain packager status (i.e. not have to get re-sponsored, etc).
The question is then what are you protecting against? If you can reset your password (via email link), and then click a button that says "I'm BACK!", you return to the original concern that was raised about whether this is really the same person you think it is.
You are right, it seems hard to do this in a way that has an actual effect without offending real people. But I think we should try to find some way. With 1500+ unused accounts it is just *too easy* for someone to find a way to access one of the accounts in an unauthorized way. Essentially, if you get access to one the email accounts, you can reset the FAS password. I'd guess that a large fraction of those mail addresses are on univerisities all around the world, and somebody might do it just for kicks.
In particular, if we removed the 'packager' bit, people would still have the account and all history associated with it. If they ever want to starting doing packaging work directly (because note that they don't actually need it if they're active but somebody else is submitting the builds), I think a manual procedure where you have to e.g. open a ticket on sponsors tracker to ask to be reinstantated would be OK.
This is exactly my point of view. My proposal wasn't meant for kicking off anyone, I was just proposing a periodic check of who's still overseeing their account.
I'll try to write down a quick script which should expand the one from Ben by looking for any activity in the last year in src.fedoraproject.org instead of Koji, then check those users for any activity in Fedora (datagrepper?).
For the identified users with no activity, I suppose that sending one email per year asking "hey, is this still your email account and are you still engaged in Fedora packaging" would be no harm. And, if no reply is received after an adequate period (2 weeks?), removing the "packager" bit from the account would be no harm as well. I'm not proposing to delete their account.
I'd suggest to make it a month at least, just in case someone takes a longer vacation.
The only issue would be how to handle packages that are maintained from such users, I think they'd need to be orphaned.
That's really the only sensible option imho.
Cheers,
Dan
I've written down a script [1] to fetch users which belong to packager group and show no activity in datagrepper in a year.
It found 104 users [2].
[1] https://mattia.fedorapeople.org/inactive-packagers/find_inactive_packagers.p... [2] https://mattia.fedorapeople.org/inactive-packagers/inactive_users.txt
On Fri, Feb 11, 2022 at 11:42:19AM +0000, Mattia Verga via devel wrote:
I've written down a script [1] to fetch users which belong to packager group and show no activity in datagrepper in a year.
It found 104 users [2].
[1] https://mattia.fedorapeople.org/inactive-packagers/find_inactive_packagers.p... [2] https://mattia.fedorapeople.org/inactive-packagers/inactive_users.txt
Cool! I recognize some of those names, but time flies… I think we should agree on a procedure and start with those accounts.
Zbyszek
Il 11/02/22 13:11, Zbigniew Jędrzejewski-Szmek ha scritto:
On Fri, Feb 11, 2022 at 11:42:19AM +0000, Mattia Verga via devel wrote:
I've written down a script [1] to fetch users which belong to packager group and show no activity in datagrepper in a year.
It found 104 users [2].
[1] https://mattia.fedorapeople.org/inactive-packagers/find_inactive_packagers.p... [2] https://mattia.fedorapeople.org/inactive-packagers/inactive_users.txt
Cool! I recognize some of those names, but time flies… I think we should agree on a procedure and start with those accounts.
Zbyszek
I'll try to write a formal proposal and submit it to FESCO for approval.
I still need to figure out the discrepancies between Ben's \ src.fedoraproject.org \ Noggin count of users being into packager group (2453 \ 1787 \ 2000)
Mattia
On 11/02/2022 07:54, Zbigniew Jędrzejewski-Szmek wrote:
With 1500+ unused accounts it is just*too easy* for someone to find a way to access one of the accounts in an unauthorized way.
What they can do with this? Pushing a new update for the foo-bar package? We have Bodhi against this.
In particular, if we removed the 'packager' bit, people would still have the account and all history associated with it.
If you remove "packager" status, this user will probably leave Fedora.
Maintainers are the main value of the distribution. We shouldn't offend and forcing them to leave Fedora.
For the identified users with no activity, I suppose that sending one email per year asking "hey, is this still your email account and are you still engaged in Fedora packaging" would be no harm.
And you make life easier for potential hackers.
They will simply copy this email and send it to all Fedora contributors. Some of them will follow the link and hackers will get a lot of real working accounts.
On Sat, Feb 12, 2022 at 12:00:11PM +0100, Vitaly Zaitsev via devel wrote:
On 11/02/2022 07:54, Zbigniew Jędrzejewski-Szmek wrote:
With 1500+ unused accounts it is just*too easy* for someone to find a way to access one of the accounts in an unauthorized way.
What they can do with this? Pushing a new update for the foo-bar package? We have Bodhi against this.
Let's talk about distro security basics. All packages are "equal": any package can ship any file, and in fact any package can execute scripts *as root* during installation. Thus, if you are able to create a build that is submitted as an update (i.e. either build it for rawhide, or build it for other releases and create a bodhi update), this is enough to wreak havoc at least on machines of people who use rawhide / updates-testing.
As you certainly know, many updates don't receive any feedback, and almost all updates receive no scrutiny if they install without errors. Thus a nefarious update would have fairly high chances of going stable too. I suppose that at some point it would be noticed, and the update pulled and the account deactivated, but there is no automatic process for this.
Bodhi runs tests, but not the kinds of tests that would help in any way against a nefarious update.
In particular, if we removed the 'packager' bit, people would still have the account and all history associated with it.
If you remove "packager" status, this user will probably leave Fedora.
Maintainers are the main value of the distribution. We shouldn't offend and forcing them to leave Fedora.
We certainly don't want to push maintainers away. In fact this whole thread is primarily about striking the right balance between security and the desire not to inconvenience maintainers.
For the identified users with no activity, I suppose that sending one email per year asking "hey, is this still your email account and are you still engaged in Fedora packaging" would be no harm.
[It was actually Mattia who wrote this, not me.]
The case of "one email per year" applies to the case of accounts which are detected as inactive each year (i.e. effectively have no koji activity over many years) *and* the packager in question replies each year that they want to keep the account active. So such repeated mails should be a very rare occurence.
And you make life easier for potential hackers.
They will simply copy this email and send it to all Fedora contributors. Some of them will follow the link and hackers will get a lot of real working accounts.
Ehh, I don't think so. There are many automated emails being sent by our infra. If a hacker wants to send a phishing email, they might just as well spoof a bugzilla ticket or a pagure notification.
If we are about to downgrade an account, sending an email is the least we should do.
Zbyszek
On 12/02/2022 12:32, Zbigniew Jędrzejewski-Szmek wrote:
All packages are "equal": any package can ship any file, and in fact any package can execute scripts *as root* during installation.
True.
Thus, if you are able to create a build that is submitted as an update (i.e. either build it for rawhide, or build it for other releases and create a bodhi update), this is enough to wreak havoc at least on machines of people who use rawhide / updates-testing.
If a hacker will "updates" the foo-bar package, it will only harm users who have that package installed.
As you certainly know, many updates don't receive any feedback, and almost all updates receive no scrutiny if they install without errors.
This is another problem. We should add some kind of gamification for QA testers, like achievements.
Thus a nefarious update would have fairly high chances of going stable too. I suppose that at some point it would be noticed, and the update pulled and the account deactivated, but there is no automatic process for this.
Maybe instead of deleting user accounts or their memberships, we should keep track of such updates and block auto-stable on karma and time for them?
We certainly don't want to push maintainers away. In fact this whole thread is primarily about striking the right balance between security and the desire not to inconvenience maintainers.
From proposal:
If no activity is detected within a year, try to contact them by their account email and if no reply is received after a proper delay (1 month) proceed by removing them from the packager group.
They will need to be sponsored again. Some people are waiting for sponsorship for months.
Ehh, I don't think so. There are many automated emails being sent by our infra. If a hacker wants to send a phishing email, they might just as well spoof a bugzilla ticket or a pagure notification.
None of them require you to sign in and follow any links.
On Sat, Feb 12, 2022 at 12:50:58PM +0100, Vitaly Zaitsev via devel wrote:
Thus, if you are able to create a build that is submitted as an update (i.e. either build it for rawhide, or build it for other releases and create a bodhi update), this is enough to wreak havoc at least on machines of people who use rawhide / updates-testing.
If a hacker will "updates" the foo-bar package, it will only harm users who have that package installed.
Yes, that is true. But a typical installation has between a few hundred and a few thousand packages, and there are also users who purposefully install additional packages e.g. for QA. So such a breach would have an important impact, even if it wouldn't impact *all* packagers.
Also note that you can add Supplements:glibc and suddenly the package will be installed in additional places.
As you certainly know, many updates don't receive any feedback, and almost all updates receive no scrutiny if they install without errors.
This is another problem. We should add some kind of gamification for QA testers, like achievements.
Thus a nefarious update would have fairly high chances of going stable too. I suppose that at some point it would be noticed, and the update pulled and the account deactivated, but there is no automatic process for this.
Maybe instead of deleting user accounts or their memberships, we should keep track of such updates and block auto-stable on karma and time for them?
We are not *deleting* user accounts, the proposal is to remove the user from a group. We could do something more complicated, but that'd require introducing special logic in multiple places (koji, bodhi, probably others), and I don't see how it'd be better than the proposed solution. If this alternative solution was implemented, for the user the result would be equivalent to the proposed solution.
We certainly don't want to push maintainers away. In fact this whole thread is primarily about striking the right balance between security and the desire not to inconvenience maintainers.
From proposal:
If no activity is detected within a year, try to contact them by their account email and if no reply is received after a proper delay (1 month) proceed by removing them from the packager group.
They will need to be sponsored again. Some people are waiting for sponsorship for months.
They will not go through the normal sponsorship process, but instead something akin to a password reset (albeit public and not automated).
Ehh, I don't think so. There are many automated emails being sent by our infra. If a hacker wants to send a phishing email, they might just as well spoof a bugzilla ticket or a pagure notification.
None of them require you to sign in and follow any links.
Well, nothing *requires* you to follow links, but many of them *contain* links, and the sites behind those links will require you to log in to e.g. post a comment.
Zbyszek
On Sat, 2022-02-12 at 14:52 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, Feb 12, 2022 at 12:50:58PM +0100, Vitaly Zaitsev via devel wrote:
Thus, if you are able to create a build that is submitted as an update (i.e. either build it for rawhide, or build it for other releases and create a bodhi update), this is enough to wreak havoc at least on machines of people who use rawhide / updates-testing.
If a hacker will "updates" the foo-bar package, it will only harm users who have that package installed.
Yes, that is true. But a typical installation has between a few hundred and a few thousand packages, and there are also users who purposefully install additional packages e.g. for QA. So such a breach would have an important impact, even if it wouldn't impact *all* packagers.
Also note that you can add Supplements:glibc and suddenly the package will be installed in additional places.
Yup, we actually use this trick in openQA to get a package from an additional repo installed without changing 'real' packages or comps. It works.
As you certainly know, many updates don't receive any feedback, and almost all updates receive no scrutiny if they install without errors.
This is another problem. We should add some kind of gamification for QA testers, like achievements.
Thus a nefarious update would have fairly high chances of going stable too. I suppose that at some point it would be noticed, and the update pulled and the account deactivated, but there is no automatic process for this.
Maybe instead of deleting user accounts or their memberships, we should keep track of such updates and block auto-stable on karma and time for them?
We are not *deleting* user accounts, the proposal is to remove the user from a group. We could do something more complicated, but that'd require introducing special logic in multiple places (koji, bodhi, probably others), and I don't see how it'd be better than the proposed solution. If this alternative solution was implemented, for the user the result would be equivalent to the proposed solution.
Replying to Vitaly here: the Bodhi process is absolutely not intended to act as security review and I don't see that it really can. Someone who goes as far as taking over a dormant maintainer account to submit a nefarious package can almost certainly also arrange to have the update immediately approved (note you can set the push threshold for a non- critpath update to +1, so you need only one account to +1 it and it will be pushed stable). Even ignoring that, security review is a specialized skill and most of the people who review updates are not trained in it. Even people who *can* do security review and also file Bodhi feedback probably aren't doing a review of every update they +1, because it's a time-consuming task and they are not being paid for it.
Bodhi functions as a quality sanity check. It's absolutely not security review.
I think that while it's slightly unfortunate that this is the case, the proposal is probably necessary, and I support it. Real world supply- chain attacks are happening, regularly, and the Fedora package collection is certainly a valid target for such an attack. We should do what we can to make it more difficult to carry one out.
Gary Buhrmaster wrote:
A quick (and likely bad and incomplete) bugzilla search shows over 1000 tickets where there are upstream updates that are still in NEW status in bugzilla and had been (initially) opened over a year ago. I think that represents around 350 unique people. Those people may be otherwise active, of course, but those packages themselves look to be under maintained.
Yes, that's a bad search. Till Maas told me eight years ago that the release monitoring tickets are supposed to remain open when the packages are upgraded. Thus an open Bugzilla ticket is no indication that the package is unmaintained. You need to check what version is actually in Rawhide.
If the Bugzilla tickets should in fact not be left open, then they should be automatically closed just like they're automatically opened.
Björn Persson
On Fri, Feb 11, 2022 at 10:39 AM Björn Persson <Bjorn@rombobjörn.se> wrote:
Gary Buhrmaster wrote:
A quick (and likely bad and incomplete) bugzilla search shows over 1000 tickets where there are upstream updates that are still in NEW status in bugzilla and had been (initially) opened over a year ago. I think that represents around 350 unique people. Those people may be otherwise active, of course, but those packages themselves look to be under maintained.
Yes, that's a bad search. Till Maas told me eight years ago that the release monitoring tickets are supposed to remain open when the packages are upgraded. Thus an open Bugzilla ticket is no indication that the package is unmaintained. You need to check what version is actually in Rawhide.
If the Bugzilla tickets should in fact not be left open, then they should be automatically closed just like they're automatically opened.
I was under the impression these tickets should be handled like any other BZ tickets: you add them to the update in Bodhi when you create it, and then Bodhi will update them and autoclose them once the new version has been pushed to the stable repo.
-Ian
Björn Persson _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Feb 11, 2022 at 10:43 AM Ian McInerney via devel devel@lists.fedoraproject.org wrote:
On Fri, Feb 11, 2022 at 10:39 AM Björn Persson <Bjorn@rombobjörn.se> wrote:
Yes, that's a bad search. Till Maas told me eight years ago that the release monitoring tickets are supposed to remain open when the packages are upgraded. Thus an open Bugzilla ticket is no indication that the package is unmaintained. You need to check what version is actually in Rawhide.
If the Bugzilla tickets should in fact not be left open, then they should be automatically closed just like they're automatically opened.
I was under the impression these tickets should be handled like any other BZ tickets: you add them to the update in Bodhi when you create it, and then Bodhi will update them and autoclose them once the new version has been pushed to the stable repo.
Or, if autoclose does not happen (such as when I have failed to add the correct reference to the update) I have been closing those ticket manually when the update is pushed to stable for good bugzilla hygiene. Am I now to understand those tickets should be left open forever?
Dne 11. 02. 22 v 11:38 Björn Persson napsal(a):
Gary Buhrmaster wrote:
A quick (and likely bad and incomplete) bugzilla search shows over 1000 tickets where there are upstream updates that are still in NEW status in bugzilla and had been (initially) opened over a year ago. I think that represents around 350 unique people. Those people may be otherwise active, of course, but those packages themselves look to be under maintained.
Yes, that's a bad search. Till Maas told me eight years ago that the release monitoring tickets are supposed to remain open when the packages are upgraded. Thus an open Bugzilla ticket is no indication that the package is unmaintained. You need to check what version is actually in Rawhide.
If the Bugzilla tickets should in fact not be left open, then they should be automatically closed just like they're automatically opened.
You can add `Resovles: rhbz#1264987` in changelog and Bodhi will close them. I think this is the right approach.
Vít
Björn Persson
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 on the list, report it: https://pagure.io/fedora-infrastructure
Not quoting anyone in particular but I thought I saw it referenced in this thread (and definitely the previous thread from last year).
What's wrong with having someone "sign" the CLA every year? At work a non-disclosure is only good for two years. Is a CLA a lifetime agreement?
Thanks, Richard
On Fri, Feb 11, 2022 at 07:12:04AM -0600, Richard Shaw wrote:
Not quoting anyone in particular but I thought I saw it referenced in this thread (and definitely the previous thread from last year).
What's wrong with having someone "sign" the CLA every year? At work a non-disclosure is only good for two years. Is a CLA a lifetime agreement?
IANAL, but, yes. I think the FPCA is explaining how Fedora accepts contributions and we ask contributors to read and agree to it in the account system, it would then apply forever after.
We could ask them to review it and ack it I suppose, but I'm not sure what that would accomplish.
kevin
Il 10/02/22 22:57, Ben Cotton ha scritto:
On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
since you have the script handy, could you check how many (non-pp) packagers would be reported as inactive pretty please? Maybe with the inactivility threshold raised to 1 year instead of 0.5 y.
I had to run it a second time with the listing disabled because the first time the output was too long for my terminal's scrollback. :-)
But! Of 2453 packagers, 1514 have not submitted a Koji build since at least 2021-02-11. 1311 of those have not submitted a Koji build since at least 2020-02-06. An additional 113 do not exist in Koji.
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
https://src.fedoraproject.org/api/0/group/packager
Mattia
On 11. 02. 22 10:12, Mattia Verga via devel wrote:
Il 10/02/22 22:57, Ben Cotton ha scritto:
On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
since you have the script handy, could you check how many (non-pp) packagers would be reported as inactive pretty please? Maybe with the inactivility threshold raised to 1 year instead of 0.5 y.
I had to run it a second time with the listing disabled because the first time the output was too long for my terminal's scrollback. :-)
But! Of 2453 packagers, 1514 have not submitted a Koji build since at least 2021-02-11. 1311 of those have not submitted a Koji build since at least 2020-02-06. An additional 113 do not exist in Koji.
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
They might have never even logged into src.fedoraproject.org
Il 11/02/22 10:41, Miro Hrončok ha scritto:
On 11. 02. 22 10:12, Mattia Verga via devel wrote:
Il 10/02/22 22:57, Ben Cotton ha scritto:
On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
since you have the script handy, could you check how many (non-pp) packagers would be reported as inactive pretty please? Maybe with the inactivility threshold raised to 1 year instead of 0.5 y.
I had to run it a second time with the listing disabled because the first time the output was too long for my terminal's scrollback. :-)
But! Of 2453 packagers, 1514 have not submitted a Koji build since at least 2021-02-11. 1311 of those have not submitted a Koji build since at least 2020-02-06. An additional 113 do not exist in Koji.
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
They might have never even logged into src.fedoraproject.org
\o/ So, I think those 756 can be added to the removal list as well...
The fun is Noggin says there are 2000 users in the packager group:
https://accounts.fedoraproject.org/group/packager/
But that perfectly round number seems odd.
Mattia
* Mattia Verga via devel:
Il 11/02/22 10:41, Miro Hrončok ha scritto:
On 11. 02. 22 10:12, Mattia Verga via devel wrote:
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
They might have never even logged into src.fedoraproject.org
\o/ So, I think those 756 can be added to the removal list as well...
Why? Isn't logging into src.fedoraproject.org optional from a workflow perspective?
Thanks, Florian
Il 11/02/22 12:20, Florian Weimer ha scritto:
- Mattia Verga via devel:
Il 11/02/22 10:41, Miro Hrončok ha scritto:
On 11. 02. 22 10:12, Mattia Verga via devel wrote:
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
They might have never even logged into src.fedoraproject.org
\o/ So, I think those 756 can be added to the removal list as well...
Why? Isn't logging into src.fedoraproject.org optional from a workflow perspective?
I suppose "logging" means that src.fedoraproject.org has no knowledge about that user... so that user never pushed any commit / PR / comment.
Have I misunderstood? Does src.fedoraproject.org not recognize a user to be in the packager group if they never logged in and only pushed things by CLI?
Mattia
On Fri, Feb 11, 2022 at 11:33:13AM +0000, Mattia Verga via devel wrote:
Il 11/02/22 12:20, Florian Weimer ha scritto:
- Mattia Verga via devel:
Il 11/02/22 10:41, Miro Hrončok ha scritto:
On 11. 02. 22 10:12, Mattia Verga via devel wrote:
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
They might have never even logged into src.fedoraproject.org
\o/ So, I think those 756 can be added to the removal list as well...
Why? Isn't logging into src.fedoraproject.org optional from a workflow perspective?
I suppose "logging" means that src.fedoraproject.org has no knowledge about that user... so that user never pushed any commit / PR / comment.
I don't think just pushing a commit would log you into pagure. You need to login to the web interface for it to create/refresh your account. PR's and comments would definitely, but just pushing commits would not.
Have I misunderstood? Does src.fedoraproject.org not recognize a user to be in the packager group if they never logged in and only pushed things by CLI?
I think that is indeed the case, but I'm not 100% sure. Perhaps Pingou could chime in on this.
kevin
Il 11/02/22 20:24, Kevin Fenzi ha scritto:
On Fri, Feb 11, 2022 at 11:33:13AM +0000, Mattia Verga via devel wrote:
Il 11/02/22 12:20, Florian Weimer ha scritto:
- Mattia Verga via devel:
Il 11/02/22 10:41, Miro Hrončok ha scritto:
On 11. 02. 22 10:12, Mattia Verga via devel wrote:
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
They might have never even logged into src.fedoraproject.org
\o/ So, I think those 756 can be added to the removal list as well...
Why? Isn't logging into src.fedoraproject.org optional from a workflow perspective?
I suppose "logging" means that src.fedoraproject.org has no knowledge about that user... so that user never pushed any commit / PR / comment.
I don't think just pushing a commit would log you into pagure. You need to login to the web interface for it to create/refresh your account. PR's and comments would definitely, but just pushing commits would not.
mmm... I suppose that, even if a user only uses CLI to push a commit, pagure needs to verify its credentials and associates the commit to the user in the web UI... so pagure MUST know about the user in its database.
My guess is that those 666 users (why I wrote 756 before???!) have never interacted with src.fedoraproject.org. They may be leftovers of users in the packager group which were active before the switching to pagure. Also, I don't think that following an unresponsive maintainer procedure the user is removed from the packager group.
Anyway, I've filed a FESCO ticket at https://pagure.io/fesco/issue/2759 as a formal proposal.
Mattia
On Sat, Feb 12, 2022 at 10:29:54AM +0000, Mattia Verga via devel wrote:
Il 11/02/22 20:24, Kevin Fenzi ha scritto:
On Fri, Feb 11, 2022 at 11:33:13AM +0000, Mattia Verga via devel wrote:
Il 11/02/22 12:20, Florian Weimer ha scritto:
- Mattia Verga via devel:
Il 11/02/22 10:41, Miro Hrončok ha scritto:
On 11. 02. 22 10:12, Mattia Verga via devel wrote: > Where are those 2543 packagers come from? src.fedoraproject.org only > shows 1787 users in the packager group: > > https://src.fedoraproject.org/api/0/group/packager They might have never even logged into src.fedoraproject.org
\o/ So, I think those 756 can be added to the removal list as well...
Why? Isn't logging into src.fedoraproject.org optional from a workflow perspective?
I suppose "logging" means that src.fedoraproject.org has no knowledge about that user... so that user never pushed any commit / PR / comment.
I don't think just pushing a commit would log you into pagure. You need to login to the web interface for it to create/refresh your account. PR's and comments would definitely, but just pushing commits would not.
mmm... I suppose that, even if a user only uses CLI to push a commit, pagure needs to verify its credentials and associates the commit to the user in the web UI... so pagure MUST know about the user in its database.
I was going to say that only packagers have a shell account on src.fp.o and should thus be allowed to push, but I've quickly checked the code and you are correct, in order to determine if an user is allowed to push to a specific package, we check their access level in pagure's database (ie: are they a package admin? committer? collaborator?), so I don't think a packager that has never logged in on src.fp.o would be allowed to push a commit.
Pierre
On Fri, Feb 11, 2022 at 11:24:24AM -0800, Kevin Fenzi wrote:
On Fri, Feb 11, 2022 at 11:33:13AM +0000, Mattia Verga via devel wrote:
Il 11/02/22 12:20, Florian Weimer ha scritto:
- Mattia Verga via devel:
Il 11/02/22 10:41, Miro Hrončok ha scritto:
On 11. 02. 22 10:12, Mattia Verga via devel wrote:
Where are those 2543 packagers come from? src.fedoraproject.org only shows 1787 users in the packager group:
They might have never even logged into src.fedoraproject.org
\o/ So, I think those 756 can be added to the removal list as well...
Why? Isn't logging into src.fedoraproject.org optional from a workflow perspective?
I suppose "logging" means that src.fedoraproject.org has no knowledge about that user... so that user never pushed any commit / PR / comment.
I don't think just pushing a commit would log you into pagure. You need to login to the web interface for it to create/refresh your account. PR's and comments would definitely, but just pushing commits would not.
Have I misunderstood? Does src.fedoraproject.org not recognize a user to be in the packager group if they never logged in and only pushed things by CLI?
I think that is indeed the case, but I'm not 100% sure. Perhaps Pingou could chime in on this.
Correct on both accounts. src.fp.o has no idea who someone is until they log in via the user-interface, so the same thing applies for group membership.
Pierre
On 11/02/2022 10:41, Miro Hrončok wrote:
They might have never even logged into src.fedoraproject.org
You don't need to be logged into src.fedoraproject.org or account.fedoraproject.org to maintain packages. You can simply make commits and send them to Bodhi using CLI tools.
On 09/02/2022 18:04, Mattia Verga via devel wrote:
For example, if someone pulls from src.fedoraproject.org a list of users in the packagers group which have been inactive for a long time, check if their email is inactive and if it has been made available for claiming, then they claim the email and reset the Fedora account password to gain access in that account...
Such email will look like a phishing attempt. I think most of maintainers will just discard them.
On 09/02/2022 08:03, Mattia Verga via devel wrote:
Just being paranoid here: do we have any policy / automatism for disabling "power" users (in packager group or like) which have been inactive for long time?
Some maintainers don't have recent commits or Koji builds because other Fedora contributors maintain their packages. Do you want to delete all these users from Fedora completely?
I think this is a very bad idea. We shouldn't offend people.
I'm no security expert, but an inactive user account may be hacked without noticing and if such account have powers like being in the packager group may inject bad things in the distribution.
That's why we have Bodhi. All updates must reach a positive karma threshold or remain in testing for 7 days.
Also, I don't remember such precedents in the entire history of Fedora.
Maybe a script could check user activities in src.fedoraproject.org and send a warning email if no activity is made in one year?
You don't need to be logged into src.fedoraproject.org or account.fedoraproject.org to maintain packages. You can simply make commits and send them to Bodhi using CLI tools.
On Sat, Feb 12, 2022 at 11:46 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 09/02/2022 08:03, Mattia Verga via devel wrote:
Just being paranoid here: do we have any policy / automatism for disabling "power" users (in packager group or like) which have been inactive for long time?
Some maintainers don't have recent commits or Koji builds because other Fedora contributors maintain their packages. Do you want to delete all these users from Fedora completely?
I think this is a very bad idea. We shouldn't offend people.
I'm no security expert, but an inactive user account may be hacked without noticing and if such account have powers like being in the packager group may inject bad things in the distribution.
That's why we have Bodhi. All updates must reach a positive karma threshold or remain in testing for 7 days.
Also, I don't remember such precedents in the entire history of Fedora.
Maybe a script could check user activities in src.fedoraproject.org and send a warning email if no activity is made in one year?
You don't need to be logged into src.fedoraproject.org or account.fedoraproject.org to maintain packages. You can simply make commits and send them to Bodhi using CLI tools.
That's not true. You need to log in to src.fedoraproject.org at least *once* to get group memberships synced over (including "packager"). Without that, you can't push things to dist-git. So everybody who joined the packager group since pagure-dist-git has been a thing, and has pushed at least one commit, certainly needs to have logged in at src.fedoraproject.org at least *once*.
Fabio
Il 12/02/22 12:20, Vitaly Zaitsev via devel ha scritto:
On 12/02/2022 12:16, Fabio Valentini wrote:
That's not true. You need to log in to src.fedoraproject.org at least *once* to get group memberships synced over (including "packager").
True. But only once.
True, but even if the user interacts with pagure exclusively pushing commits via CLI, pagure will detect their activity, so we will never bother them.
Mattia
As I reported in the Fesco ticket, I've published the script to check packagers activity at https://pagure.io/find-inactive-packagers
The latest run showed 274 totally inactive packagers [1]. However, I've just realized that the activity check made by datagrepper is wrong: the current query doesn't show activity **made by** the user, but rather any message with an association to the user. That means that if anyone reports a bug which is being assigned to a user, datagrepper will report that activity. So the real count of inactive users may be well above 274.
Anyone knows how / if there's a way to correct the query to datagrepper to only show activity from a user?
Mattia
[1] https://mattia.fedorapeople.org/inactive-packagers/find_inactive_packagers_2...
On Mon, 2022-02-14 at 17:48 +0000, Mattia Verga via devel wrote:
As I reported in the Fesco ticket, I've published the script to check packagers activity at https://pagure.io/find-inactive-packagers
The latest run showed 274 totally inactive packagers [1]. However, I've just realized that the activity check made by datagrepper is wrong: the current query doesn't show activity **made by** the user, but rather any message with an association to the user. That means that if anyone reports a bug which is being assigned to a user, datagrepper will report that activity. So the real count of inactive users may be well above 274.
Anyone knows how / if there's a way to correct the query to datagrepper to only show activity from a user?
There's no standardized way to do that, no. The old fedmsg2meta system - https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/tree/devel... - more or less required that message metadata providers offer the users associated with a message as `usernames`, but it was conventional that this return all users somehow associated with or affected by the message, not just the user who most immediately 'caused' it.
The intended replacement for metadata providers is message schemas: https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema There's no hard requirement at present (AFAIK) for schemas to have any specific required properties or accessors. The `usernames` accessor is included in the example schema (likely kinda carried over from fedmsg providers), but again this is documented as "List of users affected by the action that generated this message."
Some messages do specify the username who triggered it, where that's even a thing you can identify, but it's not universal and not always the same key in the same dict in the message.
Ultimately you'd have to pick a set of message types you want to scan and which do provide the information, and code something the query the appropriate property from each message.
Il 14/02/22 20:19, Adam Williamson ha scritto:
On Mon, 2022-02-14 at 17:48 +0000, Mattia Verga via devel wrote:
As I reported in the Fesco ticket, I've published the script to check packagers activity at https://pagure.io/find-inactive-packagers
The latest run showed 274 totally inactive packagers [1]. However, I've just realized that the activity check made by datagrepper is wrong: the current query doesn't show activity **made by** the user, but rather any message with an association to the user. That means that if anyone reports a bug which is being assigned to a user, datagrepper will report that activity. So the real count of inactive users may be well above 274.
Anyone knows how / if there's a way to correct the query to datagrepper to only show activity from a user?
There's no standardized way to do that, no.
Well, I've found Bodhi messages actually have an `agent` field that reports the user who made the action, so I've changed the script to look at that. [1]
For Bugzilla, I've looked at the code of `fedora_active_user` and used that, more or less, to check latest comment made by a user. Assuming BZ email is one of the emails set in fasjson...
After these changes the count of inactive users in the packager group has grown to 875 (48 users cannot be found in BZ with the email provided by fasjson). [2]
Mattia
[1] https://pagure.io/find-inactive-packagers [2] https://mattia.fedorapeople.org/inactive-packagers/find_inactive_packagers_2...
On Wed, 2022-02-16 at 19:49 +0000, Mattia Verga via devel wrote:
Il 14/02/22 20:19, Adam Williamson ha scritto:
On Mon, 2022-02-14 at 17:48 +0000, Mattia Verga via devel wrote:
As I reported in the Fesco ticket, I've published the script to check packagers activity at https://pagure.io/find-inactive-packagers
The latest run showed 274 totally inactive packagers [1]. However, I've just realized that the activity check made by datagrepper is wrong: the current query doesn't show activity **made by** the user, but rather any message with an association to the user. That means that if anyone reports a bug which is being assigned to a user, datagrepper will report that activity. So the real count of inactive users may be well above 274.
Anyone knows how / if there's a way to correct the query to datagrepper to only show activity from a user?
There's no standardized way to do that, no.
Well, I've found Bodhi messages actually have an `agent` field that reports the user who made the action, so I've changed the script to look at that. [1]
For Bugzilla, I've looked at the code of `fedora_active_user` and used that, more or less, to check latest comment made by a user. Assuming BZ email is one of the emails set in fasjson...
Yes, this is what I said in the bit of my email you snipped:
"Some messages do specify the username who triggered it, where that's even a thing you can identify, but it's not universal and not always the same key in the same dict in the message."
Mattia Verga via devel wrote:
I also imagine the case where a user no more use their email address and that become available to someone else. The new user may easily reset the password and gain access to the old Fedora account (provided that the old user didn't use 2fa).
Here's an article about similar concerns regarding NPM:
https://therecord.media/thousands-of-npm-accounts-use-email-addresses-with-e...
An excerpt:
| Researchers said they found that 2,818 project maintainers were still | using an email address for their accounts that had an expired domain, | some of which they found on sale on sites like GoDaddy. | | The team argued that attackers could buy these domains, re-register | the maintainer’s address on their own email servers, and then reset | the maintainer’s account password and take over his npm packages.
This seems like a risk for Fedora too, unless there are routines in place to prevent it.
This particular method of account takeover could be reliably prevented, considering that expiry dates are public and domains are quarantined before they are released for registration by someone else. A program could monitor domains that are due for renewal. If a domain expires, then account recovery by email should be disabled for addresses in that domain.
The packager would then be required to authenticate with their existing credentials – or prove their identity in some way that does not rely on ownership of the email address – and set a new email address in their account. Entering the old email address again would be allowed, in case they have recovered the domain, but they would have to prove that they can receive a confirmation message regardless of whether the new address is the same as the old address.
Björn Persson
On 15/02/2022 19:43, Björn Persson wrote:
The packager would then be required to authenticate with their existing credentials – or prove their identity in some way that does not rely on ownership of the email address – and set a new email address in their account.
How? I know only one suitable option - an email signed with a previously added GPG key, but most users don't have it in their FAS accounts.
Vitaly Zaitsev via devel wrote:
On 15/02/2022 19:43, Björn Persson wrote:
The packager would then be required to authenticate with their existing credentials – or prove their identity in some way that does not rely on ownership of the email address – and set a new email address in their account.
How? I know only one suitable option - an email signed with a previously added GPG key, but most users don't have it in their FAS accounts.
Loss of an email address does not imply loss of a FAS passphrase, so in most cases they would just log in as usual. If they have lost both their passphrase and their email address, then yes, an OpenPGP key is one possible method. Theoretically an SSH key could also be used. I don't think there currently is an interface for managing a FAS account over SSH, but an ad-hoc manual method could be devised.
Björn Persson
On 16/02/2022 11:32, Björn Persson wrote:
Loss of an email address does not imply loss of a FAS passphrase, so in most cases they would just log in as usual.
We're talking about potentially hacked accounts, right? If the hacker has the password, they can easily restore this account. That's why we need another way to verify maintainer's identity.
Hello, I don't mean to jump in the midle here, and I am just tossing out an idea for consideration that doesn't address security issues pointed out really, but does discuss the non-responsive main maintainer. I note there is a difficulty in defining the criteria for determining when an (apparently) inactive packager should be removed from the packager group. Perhaps a different POV is required. What is the problem trying to be solved? Removal of inactive packagers? Or the demotion of said packager in favour for the one(s) who are supporting the package to be promoted to main. Perhaps the automation should do just that, demote primary packager (from owner to co-maintainer) if inactive for over a year and promote the main supporter for the year to be the owner from co-maintainer. Doesn’t something like that satisfy the inactivity requirement and also prevent alienating some packagers? Just bike shedding here.
Stephen
On Wed, 2022-02-16 at 11:48 +0100, Vitaly Zaitsev via devel wrote:
On 16/02/2022 11:32, Björn Persson wrote:
Loss of an email address does not imply loss of a FAS passphrase, so in most cases they would just log in as usual.
We're talking about potentially hacked accounts, right? If the hacker has the password, they can easily restore this account. That's why we need another way to verify maintainer's identity.
-- 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 on the list, report it: https://pagure.io/fedora-infrastructure
* Stephen Snow [16/02/2022 11:21] :
Perhaps the automation should dojust that, demote primary packager (from owner to co-maintainer) if inactive for over a year and promote the main supporter for the year to be the owner from co-maintainer.
Can you define "main supporter"?
Emmanuel
On Wed, 2022-02-16 at 17:38 +0100, Emmanuel Seyman wrote:
- Stephen Snow [16/02/2022 11:21] :
Perhaps the automation should do just that, demote primary packager (from owner to co-maintainer) if inactive for over a year and promote the main supporter for the year to be the owner from co-maintainer.
Can you define "main supporter"?
I was supposing in this case it is a FAS account user who is coincidentally a main packager or maintainer, and main supporter would be in this case a co-maintainer who is actively doing the maintanence instead (or maybe a FAS holder submitting PR solutions repeatedly?). Because, old accounts should be able to have reduced privileges after a certain period of inactivity I would think, but I am reluctant to advocate removing users simply for inactivity since that state can as easily change without notice to the communty necessarily.
But maybe I miss the point of the original idea, since there also seems to be a tie in to how secure the build system is which to me is a different discussion, with some overlap of functional outcome.
Stephen
Emmanuel _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote:
Hello, I don't mean to jump in the midle here, and I am just tossing out an idea for consideration that doesn't address security issues pointed out really, but does discuss the non-responsive main maintainer. I note there is a difficulty in defining the criteria for determining when an (apparently) inactive packager should be removed from the packager group. Perhaps a different POV is required. What is the problem trying to be solved? Removal of inactive packagers? Or the demotion of said packager in favour for the one(s) who are supporting the package to be promoted to main.
The former. The main issue here is a security concern: that the accounts of dormant packagers could be taken over and used for evil. So just shuffling the deckchairs of whether someone is a 'primary' or 'co' maintainer on a given package doesn't help. As long as they are allowed to submit official builds of the package, the problem remains.
On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote:
On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote:
Hello, I don't mean to jump in the midle here, and I am just tossing out an idea for consideration that doesn't address security issues pointed out really, but does discuss the non-responsive main maintainer. I note there is a difficulty in defining the criteria for determining when an (apparently) inactive packager should be removed from the packager group. Perhaps a different POV is required. What is the problem trying to be solved? Removal of inactive packagers? Or the demotion of said packager in favour for the one(s) who are supporting the package to be promoted to main.
The former. The main issue here is a security concern: that the accounts of dormant packagers could be taken over and used for evil. So just shuffling the deckchairs of whether someone is a 'primary' or 'co' maintainer on a given package doesn't help. As long as they are allowed to submit official builds of the package, the problem remains
But wouldn't be possible to move their deckchair into a sandbox?
Stephen
.
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 on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Feb 16, 2022 at 12:51:13PM -0500, Stephen Snow wrote:
On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote:
On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote:
Hello, I don't mean to jump in the midle here, and I am just tossing out an idea for consideration that doesn't address security issues pointed out really, but does discuss the non-responsive main maintainer. I note there is a difficulty in defining the criteria for determining when an (apparently) inactive packager should be removed from the packager group. Perhaps a different POV is required. What is the problem trying to be solved? Removal of inactive packagers? Or the demotion of said packager in favour for the one(s) who are supporting the package to be promoted to main.
The former. The main issue here is a security concern: that the accounts of dormant packagers could be taken over and used for evil. So just shuffling the deckchairs of whether someone is a 'primary' or 'co' maintainer on a given package doesn't help. As long as they are allowed to submit official builds of the package, the problem remains
But wouldn't be possible to move their deckchair into a sandbox?
That is what we are effectively doing. By removing them from @packager, they lose write access to packages. It is also very easy to undo. In your approach, we'd do this package-by-package. That'd be more complicated and harder to undo, and wouldn't really help with the security concerns.
Zbyszek
On Thu, 2022-02-17 at 19:22 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Feb 16, 2022 at 12:51:13PM -0500, Stephen Snow wrote:
On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote:
On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote:
Hello, I don't mean to jump in the midle here, and I am just tossing out an idea for consideration that doesn't address security issues pointed out really, but does discuss the non-responsive main maintainer. I note there is a difficulty in defining the criteria for determining when an (apparently) inactive packager should be removed from the packager group. Perhaps a different POV is required. What is the problem trying to be solved? Removal of inactive packagers? Or the demotion of said packager in favour for the one(s) who are supporting the package to be promoted to main.
The former. The main issue here is a security concern: that the accounts of dormant packagers could be taken over and used for evil. So just shuffling the deckchairs of whether someone is a 'primary' or 'co' maintainer on a given package doesn't help. As long as they are allowed to submit official builds of the package, the problem remains
But wouldn't be possible to move their deckchair into a sandbox?
That is what we are effectively doing. By removing them from @packager, they lose write access to packages. It is also very easy to undo. In your approach, we'd do this package-by-package. That'd be more complicated and harder to undo, and wouldn't really help with the security concerns.
Thanks for the explanation, and I appreciate that I was naive potentially with my simplistic question and the complexity of doing packager rights on a per package basis does seem onerous. So if I understand it correctly this is a @packager group level demotion, so no longer a packager at all, but could be easily promoted to that status if need be in the future. That would seem to be a sensible approach.
I would assume there is already a process to deal with accounts that may have been compromised.
Stephen
Zbyszek _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Just to revive this thread, there's a proposed policy discussed at https://pagure.io/fesco/issue/2759
and codified in https://pagure.io/fesco/fesco-docs/pull-request/61
If all interested parties could take a look and comment back here with any changes or concerns, FESCo can move it forward.
kevin
Vitaly Zaitsev via devel wrote:
We're talking about potentially hacked accounts, right?
In this subthread I'm talking about *preventing* account takeovers so that they don't happen in the first place. One specific method of takeover that the Fedora Project would be able to prevent.
I thought the quote I posted was perfectly clear. Evidently it wasn't. Allow me to explain the scenario step by step:
Step 1: J. Doe joins the Fedora Project using a working email address, j.doe@example.net. J. Doe gets sponsored and makes some packages. All is well so far.
Step 2: Much later, the holder of example.net stops paying the renewal fee. The registry removes the domain from DNS. j.doe@example.net ceases to exist. J. Doe forgets to update the address in their Fedora account. This has happened to 2818 NPM accounts according to the article I quoted. It can happen to Fedora accounts too.
Possible step 3: A program on a Fedora Project server notes that example.net has been deactivated. The program removes the address j.doe@example.net from J. Doe's account, or disables sending to the nonexistent address.
Question: Does step 3 happen? I suspect that this program doesn't exist. I haven't seen any mentions of it.
Step 4: The quarantine period ends. The registry releases example.net for registration.
Step 5: Malicious Mallory registers example.net, sets up a mail server and configures the alias "j.doe". Suddenly j.doe@example.net exists again, but now this address quite legitimately belongs to Mallory.
Step 6: Mallory enters J. Doe's username into https://accounts.fedoraproject.org/forgot-password/ask and clicks on "Send".
Branch 6A: If step 3 was not done, then a passphrase reset email is sent to j.doe@example.net and is received by Mallory. Mallory takes over J. Doe's account and replaces any SSH and OpenPGP keys with his own. Malicious Mallory is now a Fedora packager in the name of J. Doe, and is empowered to insert malware into J. Doe's packages.
Branch 6B: If step 3 was done, then no passphrase reset email is sent. Mallory's attack fails.
Step 7: J. Doe tries to log in.
Branch 7A: If step 3 was not done, then none of J. Doe's credentials work anymore. Mallory has control of the account and J. Doe is locked out.
Branch 7B: If step 3 was done, then the account still belongs to J. Doe. The account system tells J. Doe to enter a new email address. The system sends a verification code to this new address. This is not a passphrase reset. It's an email address verification code, which J. Doe must paste into the web interface while logged in, to prove that the address belongs to the right person. After the new address is verified, J. Doe's account works normally again.
Note that Mallory must do step 5 before step 6 for the attack to work, and the registry won't allow step 5 to happen before step 4. Therefore doing step 3 before step 4 ensures that step 6 cannot happen before step 3. That way the Fedora Project could reliably prevent this kind of attack.
I hope this explanation is clear enough to be understood. In case of TL;DR, the short version is four posts upthread from here.
So, does step 3 exist?
Björn Persson
On Sat, Feb 19, 2022 at 02:18:38PM +0100, Björn Persson wrote:
Possible step 3: A program on a Fedora Project server notes that example.net has been deactivated. The program removes the address j.doe@example.net from J. Doe's account, or disables sending to the nonexistent address.
...
Step 4: The quarantine period ends. The registry releases example.net for registration.
This means we would create the domain entering quarantine period almost like it being deactivated. That's very harsh… Based on a quick search, it seems that the quarantine varies, but is 14-40 days.
I think it'd be better to check the status weekly and only require account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ times in a row (where N=quarantine length in days).
Zbyszek
Zbigniew Jędrzejewski-Szmek wrote:
I think it'd be better to check the status weekly and only require account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ times in a row (where N=quarantine length in days).
It will be fine as long as it's done before the domain is released for registration. Let's just not make it so tight that a little unscheduled downtime can open an attack window.
Björn Persson
Il 19/02/22 19:38, Björn Persson ha scritto:
Zbigniew Jędrzejewski-Szmek wrote:
I think it'd be better to check the status weekly and only require account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ times in a row (where N=quarantine length in days).
It will be fine as long as it's done before the domain is released for registration. Let's just not make it so tight that a little unscheduled downtime can open an attack window.
But this covers just the case where a domain is expired and free to take.
I agree this would be the easiest attack vector, but what about if it's the user email only to expire and free to take? There are (at least, I'm sure there were) some free email services that expire email addresses not used for a year or so. Also, in a previous comment in this thread, someone pointed out that also email addresses from universities or other institutions can be "recycled". These are harder attack cases, but they're possible.
That's why I proposed a check against user activity rather than a check against domain or email reachability.
Mattia
On 2/20/22 05:00, Mattia Verga via devel wrote:
Il 19/02/22 19:38, Björn Persson ha scritto:
Zbigniew Jędrzejewski-Szmek wrote:
I think it'd be better to check the status weekly and only require account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ times in a row (where N=quarantine length in days).
It will be fine as long as it's done before the domain is released for registration. Let's just not make it so tight that a little unscheduled downtime can open an attack window.
But this covers just the case where a domain is expired and free to take.
I agree this would be the easiest attack vector, but what about if it's the user email only to expire and free to take? There are (at least, I'm sure there were) some free email services that expire email addresses not used for a year or so. Also, in a previous comment in this thread, someone pointed out that also email addresses from universities or other institutions can be "recycled". These are harder attack cases, but they're possible.
That's why I proposed a check against user activity rather than a check against domain or email reachability.
Mattia
I think we should also require security key-based 2fa for all packagers. Security keys are the only form of 2fa that is immune to phishing attacks. In the future, I would like to see a requirement that uploads be digitally signed, which Debian already enforces. I would also like to see certificate pinning implemented for all Fedora Project infrastructure.
On Sun, Feb 20, 2022 at 4:01 PM Demi Marie Obenour demiobenour@gmail.com wrote:
I think we should also require security key-based 2fa for all packagers.
In a previous discussion on this topic that was suggested (and at least partially rejected(*)).
Many (larger) orgs have decided that issuing hardware security keys to all their staff can eliminate entire classes of vulnerabilities.
Unfortunately, last I checked, the FAS account system did not support adding something like a FIDO2 security key to an account(**). Even if it did, I suspect not all the other parts of the system would support FIDO keys.
For a community organization such as Fedora, requiring packagers to obtain (and register) security keys would be a large step(***), and might end up adding enough impedance to the new packager process to discourage new packagers (and/or drive away some existing packagers). There is also the problem of replacement keys when they are lost/damaged(****), and they will, eventually, be lost/stolen/damaged.
All said, I agree that requiring packagers to have and register (something like) FIDO keys is a good goal.
Lastly, a question, if some of the RedHat employees on the list are at liberty to comment, does RH require hardware security keys, or other OTP technologies, to access certain apps, or are passwords considered good enough?
Gary
(*) Well, rejected might be too strong, but it was not agreed upon as a way forward.
(**) There may be alternatives, but the FIDO / U2F approach seems to be the one most are moving towards.
(***) I suppose if there was "magic money" the project could issue them to those that have been approved as new packagers.
(****) Replacement security keys are always a problem, even when the org has a direct connection to the individual.
On Sun, 2022-02-20 at 16:42 +0000, Gary Buhrmaster wrote:
Unfortunately, last I checked, the FAS account system did not support adding something like a FIDO2 security key to an account(**). Even if it did, I suspect not all the other parts of the system would support FIDO keys.
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
On Sun, Feb 20, 2022, 16:09 Adam Williamson adamwill@fedoraproject.org wrote:
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
TOTP (what the authenticator app does), is, indeed, better than nothing, but U2F (FIDO), is considered to be stronger.
On Sun, Feb 20, 2022 at 04:43:13PM -0800, Gary Buhrmaster wrote:
On Sun, Feb 20, 2022, 16:09 Adam Williamson adamwill@fedoraproject.org wrote:
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
The old account system (fas2) used to support yubikeys, but it did not support U2F. It only supported them in HOTP mode, not U2f.
The new account system is a frontend to IPA, and IPA does not currently support U2F. There's a RFE ( https://github.com/SSSD/sssd/issues/4322 ) but I don't know where it is on their roadmap. Not only does IPA need to add support, but then we would need to add support to noggin to enroll/etc.
TOTP (what the authenticator app does), is, indeed, better than nothing, but U2F (FIDO), is considered to be stronger.
Yeah.
So, as to the topic of this thread... I agree it's a possible attack vector, but it seems... like a lot more work than just coming in through the new maintainer workflow, but I do suppose there might be more scrutiny there.
When someone makes an account, basically we are saying "This person is the person who controls that email address". So, if we don't have the email address, we have to fall back on other data that was added to the account, like ssh pub key, gnupg key, etc. Or real world information, like "I know them and met them at the pub", they work for Red Hat and we can verify them, etc. In fas2 we also had a 'challenge/response' thing that someone could fill in, but not many folks did (and the new system doesn't have that anyhow).
I think some kind of keep alive ping could be worthwhile, although we have always rejected them in the past for bothering mataintainers too much.
kevin
On su, 20 helmi 2022, Kevin Fenzi wrote:
On Sun, Feb 20, 2022 at 04:43:13PM -0800, Gary Buhrmaster wrote:
On Sun, Feb 20, 2022, 16:09 Adam Williamson adamwill@fedoraproject.org wrote:
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
The old account system (fas2) used to support yubikeys, but it did not support U2F. It only supported them in HOTP mode, not U2f.
The new account system is a frontend to IPA, and IPA does not currently support U2F. There's a RFE ( https://github.com/SSSD/sssd/issues/4322 ) but I don't know where it is on their roadmap. Not only does IPA need to add support, but then we would need to add support to noggin to enroll/etc.
We (FreeIPA and SSSD teams) are working on a bit different approach right now since support of U2F in Kerberos is complicated with a need to first get a specification agreed between multiple industry participants and currently there is no one driving that work.
Instead, we are working on an ability to authenticate against OIDC when acquiring a Kerberos ticket granting ticket. This would turn the need to choose authentication method to the IdP configured and most IdPs support use of U2F tokens (as well as other mechanisms).
With this approach, id.fedoraproject.org would be able to handle authentication on its own way, not Fedora Project's KDC alone like now. After authenticated, a user would be issued with a 'normal' Kerberos TGT which then can be used to obtain service tickets to other services and authenticate to them with GSSAPI. Including, if needed, to authenticate to id.fedoraproject.org again, this time with GSSAPI.
This is not ready for general consumption but we plan to have something to submit to Rawhide in a month or so. Enrolling IPA users into this would be similar to already existing RADIUS proxy authentication path in FreeIPA.
TOTP (what the authenticator app does), is, indeed, better than nothing, but U2F (FIDO), is considered to be stronger.
Yeah.
So, as to the topic of this thread... I agree it's a possible attack vector, but it seems... like a lot more work than just coming in through the new maintainer workflow, but I do suppose there might be more scrutiny there.
When someone makes an account, basically we are saying "This person is the person who controls that email address". So, if we don't have the email address, we have to fall back on other data that was added to the account, like ssh pub key, gnupg key, etc. Or real world information, like "I know them and met them at the pub", they work for Red Hat and we can verify them, etc. In fas2 we also had a 'challenge/response' thing that someone could fill in, but not many folks did (and the new system doesn't have that anyhow).
I think some kind of keep alive ping could be worthwhile, although we have always rejected them in the past for bothering mataintainers too much.
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 on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Feb 21, 2022 at 8:35 AM Alexander Bokovoy abokovoy@redhat.com wrote:
This is not ready for general consumption but we plan to have something to submit to Rawhide in a month or so. Enrolling IPA users into this would be similar to already existing RADIUS proxy authentication path in FreeIPA.
Excellent news that there is progress!
And, yes, I do understand there are many more steps to go to get to where some of us would like to be.
Thanks.
Adam Williamson wrote:
However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
You can produce compatible OTPs with a yubikey if you want. Install yubioath-desktop. You open an app on your workstation/laptop instead of on the phone, and paste from the clipboard instead of retyping. (Still not as good as U2F of course.)
Björn Persson
Also it's possible to use gopass which is able to store the OTP seed secured by GPG and keep the GPG keys on a Yubikey to ensure their safety.
Best, Fale
On Mon, Feb 21, 2022, at 11:03, Björn Persson wrote:
Adam Williamson wrote:
However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
You can produce compatible OTPs with a yubikey if you want. Install yubioath-desktop. You open an app on your workstation/laptop instead of on the phone, and paste from the clipboard instead of retyping. (Still not as good as U2F of course.)
Björn Persson
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 on the list, report it: https://pagure.io/fedora-infrastructure
On 2/20/22 19:08, Adam Williamson wrote:
On Sun, 2022-02-20 at 16:42 +0000, Gary Buhrmaster wrote:
Unfortunately, last I checked, the FAS account system did not support adding something like a FIDO2 security key to an account(**). Even if it did, I suspect not all the other parts of the system would support FIDO keys.
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t.
On 21/02/2022 19:25, Demi Marie Obenour wrote:
FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t.
OTP is absolutely free. FIDO2 requires the purchase of a special hardware token.
On 2/21/22 14:16, Vitaly Zaitsev via devel wrote:
On 21/02/2022 19:25, Demi Marie Obenour wrote:
FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t.
OTP is absolutely free. FIDO2 requires the purchase of a special hardware token.
One must remember that anyone in the packagers group can (with a modicum of effort) get code execution on a huge number of machines, and is thus an incredibly attractive target for phishing attacks. Developing a roadmap to encourage, and eventually require, the use of hardware authenticators to submit packages is a reasonable precaution in this threat environment. A hardware authenticator could be a FIDO2 token, smart card, etc.
On Tue, Feb 22, 2022 at 2:15 AM Demi Marie Obenour demiobenour@gmail.com wrote:
On 2/21/22 14:16, Vitaly Zaitsev via devel wrote:
On 21/02/2022 19:25, Demi Marie Obenour wrote:
FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t.
OTP is absolutely free. FIDO2 requires the purchase of a special hardware token.
One must remember that anyone in the packagers group can (with a modicum of effort) get code execution on a huge number of machines, and is thus an incredibly attractive target for phishing attacks. Developing a roadmap to encourage, and eventually require, the use of hardware authenticators to submit packages is a reasonable precaution in this threat environment. A hardware authenticator could be a FIDO2 token, smart card, etc.
While it may make sense from the security standpoint, we also need to factor in the community/economic factor for Fedora contributors. Requiring the use of a hardware key then means that contributors have to spend their money to buy such a key, adding an additional hurdle for them to go through. Having to get the hardware key may also be prohibitive for contributors coming from developing countries, or who are low-income/unemployed, where they may already have a computer to use, but the added cost of a new hardware key could be a large burden.
The only viable option I see for requiring the use of hardware keys would be if RedHat (or another sponsor) provided them to packagers when needed. This is probably prohibitive to do for the entire packager group, so instead it would make more sense to focus on the group that would expose the largest amount of the distribution - the proven packager group. This set of packagers is a smaller group, and they would have shown a dedication to the community/Fedora in the past to be approved by FESCO. It would probably be easier to convince Redhat/the Fedora Council to sponsor hardware keys for that core group than the community at large should the decision to require them be made.
-Ian
-- 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 on the list, report it: https://pagure.io/fedora-infrastructure
On 2/21/22 22:17, Ian McInerney via devel wrote:
On Tue, Feb 22, 2022 at 2:15 AM Demi Marie Obenour demiobenour@gmail.com wrote:
On 2/21/22 14:16, Vitaly Zaitsev via devel wrote:
On 21/02/2022 19:25, Demi Marie Obenour wrote:
FIDO keys are significantly more secure than OTPs, and FAS should get support for them. OTPs are still phishable, whereas FIDO2 generally isn’t.
OTP is absolutely free. FIDO2 requires the purchase of a special hardware token.
One must remember that anyone in the packagers group can (with a modicum of effort) get code execution on a huge number of machines, and is thus an incredibly attractive target for phishing attacks. Developing a roadmap to encourage, and eventually require, the use of hardware authenticators to submit packages is a reasonable precaution in this threat environment. A hardware authenticator could be a FIDO2 token, smart card, etc.
While it may make sense from the security standpoint, we also need to factor in the community/economic factor for Fedora contributors. Requiring the use of a hardware key then means that contributors have to spend their money to buy such a key, adding an additional hurdle for them to go through. Having to get the hardware key may also be prohibitive for contributors coming from developing countries, or who are low-income/unemployed, where they may already have a computer to use, but the added cost of a new hardware key could be a large burden.
The only viable option I see for requiring the use of hardware keys would be if RedHat (or another sponsor) provided them to packagers when needed. This is probably prohibitive to do for the entire packager group, so instead it would make more sense to focus on the group that would expose the largest amount of the distribution - the proven packager group. This set of packagers is a smaller group, and they would have shown a dedication to the community/Fedora in the past to be approved by FESCO. It would probably be easier to convince Redhat/the Fedora Council to sponsor hardware keys for that core group than the community at large should the decision to require them be made.
-Ian
Proven packagers are definitely a good place to start, along with maintainers of core packages such as glibc. Next should be the maintainers of any package that is a dependency (either at build-time or runtime) of any package that is either (1) included in any default install or (2) used in Fedora’s own infrastructure. That leaves the Supplements: hole still open, which needs to be dealt with some other way.
On 22/02/2022 04:17, Ian McInerney via devel wrote:
The only viable option I see for requiring the use of hardware keys would be if RedHat (or another sponsor) provided them to packagers when needed.
There is another problem - the US export/sanctions policies. You can't ship such cryptographic devices to contributors in sanctioned regions.
On 22/02/2022 03:14, Demi Marie Obenour wrote:
Developing a roadmap to encourage, and eventually require, the use of hardware authenticators to submit packages is a reasonable precaution in this threat environment. A hardware authenticator could be a FIDO2 token, smart card, etc.
Who will pay for this equipment?
On Mon, Feb 21, 2022 at 7:17 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
OTP is absolutely free. FIDO2 requires the purchase of a special hardware token.
Not necessarily. Not only can some mobile devices present the needed credentials (as if they were an external hardware token), but as I recall U2F specifies a TPM(2?) chip as a possible secure processor. While I don't remember where, I think I did once see a reference to where someone had created a TPM based FIDO implementation.
But I agree there are some known problems in obtaining a $10(US) FIDO2 token.
On 23/02/2022 00:03, Gary Buhrmaster wrote:
a TPM(2?) chip as a possible secure processor.
In some countries, TPM can't be pre-installed on all new PCs/Laptops due to regulation issues.
On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote:
On Sun, 2022-02-20 at 16:42 +0000, Gary Buhrmaster wrote:
Unfortunately, last I checked, the FAS account system did not support adding something like a FIDO2 security key to an account(**). Even if it did, I suspect not all the other parts of the system would support FIDO keys.
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for *all* contributors today, as oppposed to merely infra people ?
We know that Fedora contributors have had their passwords compromised in the past [1], so not using 2FA of any kind is a risk to Fedora.
I understand these simple OTPs are not as secure as FIDO2, but they have the clear advantage of actually being supported in Fedora's auth system today. These OTPs are good enough that 1000's of companies globally use them, rather than relying on plain passwords only.
By all means have FIDO2 supported as the desired long term goal, but it feels dubious to stick with only plain passwords in the meantime. FIDO2 support requires significant dev work on a service that is not under Fedora's control and make take many many years to arrive in a form that is usable.
With regards, Daniel
[1] https://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html
On 2/22/22 06:33, Daniel P. Berrangé wrote:
On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote:
On Sun, 2022-02-20 at 16:42 +0000, Gary Buhrmaster wrote:
Unfortunately, last I checked, the FAS account system did not support adding something like a FIDO2 security key to an account(**). Even if it did, I suspect not all the other parts of the system would support FIDO keys.
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for *all* contributors today, as oppposed to merely infra people ?
I very much would support this change.
We know that Fedora contributors have had their passwords compromised in the past [1], so not using 2FA of any kind is a risk to Fedora.
I understand these simple OTPs are not as secure as FIDO2, but they have the clear advantage of actually being supported in Fedora's auth system today. These OTPs are good enough that 1000's of companies globally use them, rather than relying on plain passwords only.
By all means have FIDO2 supported as the desired long term goal, but it feels dubious to stick with only plain passwords in the meantime. FIDO2 support requires significant dev work on a service that is not under Fedora's control and make take many many years to arrive in a form that is usable.
I wholeheartedly agree with this statement.
With regards, Daniel
[1] https://lists.fedoraproject.org/pipermail/announce/2011-January/002911.html
On Tue, Feb 22, 2022 at 11:33:55AM +0000, Daniel P. Berrangé wrote:
On Sun, Feb 20, 2022 at 04:08:43PM -0800, Adam Williamson wrote:
On Sun, 2022-02-20 at 16:42 +0000, Gary Buhrmaster wrote:
Unfortunately, last I checked, the FAS account system did not support adding something like a FIDO2 security key to an account(**). Even if it did, I suspect not all the other parts of the system would support FIDO keys.
It used to support these, but the support was lost with the recent rewrite. However, it supports Google Authenticator-style OTPs. Folks with infra privileges on their accounts (like me) are already required to use these. It works fine. I preferred being able to use a yubikey so I don't always have to open an app on my phone and retype a six digit code when I need to log in to something, but that's just a minor annoyance.
Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for *all* contributors today, as oppposed to merely infra people ?
All contributors? ie, require an otp to make an account? Or did you mean all packagers? or something else?
I don't think there's any way in IPA to require otp as a requirement for group membership currently. (Please let me know if there is). Which would leave us checking after the fact and removing people without one set, which is a big pile of hassle. :(
We know that Fedora contributors have had their passwords compromised in the past [1], so not using 2FA of any kind is a risk to Fedora.
I understand these simple OTPs are not as secure as FIDO2, but they have the clear advantage of actually being supported in Fedora's auth system today. These OTPs are good enough that 1000's of companies globally use them, rather than relying on plain passwords only.
By all means have FIDO2 supported as the desired long term goal, but it feels dubious to stick with only plain passwords in the meantime. FIDO2 support requires significant dev work on a service that is not under Fedora's control and make take many many years to arrive in a form that is usable.
Enforcing otp per group also would require dev work from what I understand. :(
kevin
On Tue, Feb 22, 2022 at 9:54 PM Kevin Fenzi kevin@scrye.com wrote:
I don't think there's any way in IPA to require otp as a requirement for group membership currently. (Please let me know if there is). Which would leave us checking after the fact and removing people without one set, which is a big pile of hassle. :(
Well, should such a policy be enacted, there is the one time check for existing packagers, and then just one more step to check box to check for those that are requesting to be added to the packager group.
Not ideal, but I would expect doable (unless there is a lot more churn in the packager group than I am aware of).
Enforcing otp per group also would require dev work from what I understand. :(
Probably. Although the requirement to enforce the most restrictive requirement(s) on a user that any group requires that the user is a member of is something that is certainly desirable of better implementations (and if a group later is changed to have higher requirements, users that do not conform would need to be addressed (removal from group entirely, not getting the group authorizations, something....).
On 22/02/2022 12:33, Daniel P. Berrangé wrote:
Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for*all* contributors today, as oppposed to merely infra people ?
I like it, but many Fedora contributors won't be happy. Google said that only 10% of their users use OTP.
We need to fix Fedora's OTP implementation first. Sending password+CODE is the worst idea, I ever seen. You can't even use a password manager to auto-enter it.
My suggestions: 1. Change password entry dialog on id.fedoraproject.org with accounts.fedoraproject.org version (with a separate OTP field). 2. Kinit should ask for password and OTP code in different prompts (check how it works with SSH + OTP plugin).
On Wed, Feb 23, 2022 at 10:33:16AM +0100, Vitaly Zaitsev via devel wrote:
On 22/02/2022 12:33, Daniel P. Berrangé wrote:
Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for*all* contributors today, as oppposed to merely infra people ?
I like it, but many Fedora contributors won't be happy. Google said that only 10% of their users use OTP.
I presume you're referring to Google services like GMail, etc. I can totally understand that kind of metric for the global population in general, but I don't think the comparison is relevant or valid.
Contributing to the Fedora project comes with responsibilities, and being asked to keep your account secured with 2fa is not an unreasonable request from a project such as Fedora, whose output is consumed by a huge number of users. 2fa is a standard best practice expected from any organization that takes user account security seriously.
There are significant implications for reputational damage to Fedora if a contributor's account is compromised and that is then successfully used to compromise software and get it shipped to millions of users.
We got lucky in the past with scope of damage after an account compromise, but we should not assume that will be the case next time...
Regards, Daniel
On Wed, Feb 23, 2022 at 10:33:16AM +0100, Vitaly Zaitsev via devel wrote:
On 22/02/2022 12:33, Daniel P. Berrangé wrote:
Given that the accounts system already supports these OTPs, what is the reason for not mandating this OTP based 2FA for*all* contributors today, as oppposed to merely infra people ?
I like it, but many Fedora contributors won't be happy. Google said that only 10% of their users use OTP.
We need to fix Fedora's OTP implementation first. Sending password+CODE is the worst idea, I ever seen. You can't even use a password manager to auto-enter it.
My suggestions:
- Change password entry dialog on id.fedoraproject.org with
accounts.fedoraproject.org version (with a separate OTP field).
We have this change already done, but are waiting for a upstream ipsilon release.
- Kinit should ask for password and OTP code in different prompts (check
how it works with SSH + OTP plugin).
This is being worked on by IPA folks.
kevin
Demi Marie Obenour wrote:
Security keys are the only form of 2fa that is immune to phishing attacks.
U2F and FIDO2 are said to be immune to phishing. HOTP, TOTP and various proprietary challenge-respone protocols are not immune.
Björn Persson
Mattia Verga via devel wrote:
Il 19/02/22 19:38, Björn Persson ha scritto:
Zbigniew Jędrzejewski-Szmek wrote:
I think it'd be better to check the status weekly and only require account reconfirmation if the quarantine status is detected ⌊N / 7 - 1⌋ times in a row (where N=quarantine length in days).
It will be fine as long as it's done before the domain is released for registration. Let's just not make it so tight that a little unscheduled downtime can open an attack window.
But this covers just the case where a domain is expired and free to take.
Correct. I'm not saying it would be a panacea.
I agree this would be the easiest attack vector, but what about if it's the user email only to expire and free to take? There are (at least, I'm sure there were) some free email services that expire email addresses not used for a year or so. Also, in a previous comment in this thread, someone pointed out that also email addresses from universities or other institutions can be "recycled". These are harder attack cases, but they're possible.
Do these services and institutions publish lists of expired email addresses and dates when they will be recycled? In that case they could be handled the same way as expired domains.
That's why I proposed a check against user activity rather than a check against domain or email reachability.
Doing one does not prevent doing the other.
Disabling inactive user accounts makes sense because abandoned accounts are more likely targets for takeover. It can be expected to reduce the risk somewhat, but it's not a reliable way to prevent takeovers entirely. Zbigniew said that some registries use quarantine times as short as 14 days. You can't disable packagers just because they take a two-week vacation.
Monitoring for expired domains is a reliable way to eliminate one attack vector, but not other attack vectors. Other countermeasures against other attack vectors are also needed. Existence of other attack vectors is not a valid argument against eliminating one attack vector.
Björn Persson
-
Adam Williamson -
Alexander Bokovoy -
Ben Cotton -
Björn Persson -
Dan Čermák -
Daniel P. Berrangé -
Demi Marie Obenour -
Emmanuel Seyman -
Fabio Alessandro Locati -
Fabio Valentini -
Florian Weimer -
Gary Buhrmaster -
Ian McInerney -
Kevin Fenzi -
Mattia Verga -
Miro Hrončok -
Pierre-Yves Chibon -
Richard Shaw -
Simo Sorce -
Stephen Snow -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek