1:03 a.m.
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
1:35 a.m.
Mattia Verga via devel <devel(a)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
1:54 a.m.
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/#_mainta...
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?
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
6:25 a.m.
On Wed, Feb 9, 2022, 02:54 Adam Williamson <adamwill(a)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
7:51 a.m.
On Wed, Feb 9, 2022 at 7:25 AM Ben Cotton <bcotton(a)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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
11:04 a.m.
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/#_mainta...
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
12:06 p.m.
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel
<devel(a)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.
9:01 p.m.
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel
<devel(a)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=...
So, please, make a formal FESCo proposal.
That is the way to get things moving forward.
12:39 p.m.
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(a)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
3:57 p.m.
On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
5 p.m.
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(a)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.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
5:05 p.m.
On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton <bcotton(a)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.
12:54 a.m.
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(a)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
2:39 a.m.
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(a)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
3:09 a.m.
Mattia Verga via devel <devel(a)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(a)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
5:42 a.m.
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_packager...
[2] https://mattia.fedorapeople.org/inactive-packagers/inactive_users.txt
6:11 a.m.
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_packager...
[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
6:33 a.m.
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_packager...
> [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
5 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:32 a.m.
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
5:50 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:52 a.m.
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
12:27 p.m.
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
4:38 a.m.
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
4:43 a.m.
On Fri, Feb 11, 2022 at 10:39 AM Björn Persson <Bjorn(a)xn--rombobjrn-67a.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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
6 a.m.
On Fri, Feb 11, 2022 at 10:43 AM Ian McInerney via devel
<devel(a)lists.fedoraproject.org> wrote:
On Fri, Feb 11, 2022 at 10:39 AM Björn Persson <Bjorn(a)xn--rombobjrn-67a.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?
6:54 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
7:12 a.m.
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
1:31 p.m.
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
3:12 a.m.
Il 10/02/22 22:57, Ben Cotton ha scritto:
On Thu, Feb 10, 2022 at 1:39 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
3:41 a.m.
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(a)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
They might have never even logged into src.fedoraproject.org
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:18 a.m.
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(a)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
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
5:20 a.m.
* 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?
Thanks,
Florian
5:33 a.m.
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.
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
1:24 p.m.
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.
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
4:29 a.m.
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.
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
2:37 a.m.
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
2:29 a.m.
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:
> >>>>
> >>>> 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.
> 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
5:02 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:48 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:45 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:16 a.m.
On Sat, Feb 12, 2022 at 11:46 AM Vitaly Zaitsev via devel
<devel(a)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
5:20 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:15 a.m.
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
11:48 a.m.
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_packager...
1:19 p.m.
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/de...
- 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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1:49 p.m.
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_packager...
5:06 p.m.
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."
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
12:43 p.m.
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-wit...
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
2:21 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:32 a.m.
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
4:48 a.m.
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(a)easycoding.org)
10:21 a.m.
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(a)easycoding.org)
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
10:38 a.m.
* 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"?
Emmanuel
11:40 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
11:13 a.m.
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
11:51 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
12:22 p.m.
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
12:48 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
10:51 a.m.
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
7:18 a.m.
New subject: Preventing account takeovers through expired domains (was: Do we
have any policy for disabling inactive users)
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(a)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(a)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(a)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(a)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(a)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
7:59 a.m.
New subject: Preventing account takeovers through expired domains (was: Do we
have any policy for disabling inactive users)
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(a)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
12:38 p.m.
New subject: Preventing account takeovers through expired domains
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
4 a.m.
New subject: Preventing account takeovers through expired domains
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
10 a.m.
New subject: Preventing account takeovers through expired domains
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
10:42 a.m.
New subject: Preventing account takeovers through expired domains
On Sun, Feb 20, 2022 at 4:01 PM Demi Marie Obenour
<demiobenour(a)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.
6:08 p.m.
New subject: Preventing account takeovers through expired domains
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
6:43 p.m.
New subject: Preventing account takeovers through expired domains
On Sun, Feb 20, 2022, 16:09 Adam Williamson <adamwill(a)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.
8:45 p.m.
New subject: Preventing account takeovers through expired domains
On Sun, Feb 20, 2022 at 04:43:13PM -0800, Gary Buhrmaster wrote:
On Sun, Feb 20, 2022, 16:09 Adam Williamson
<adamwill(a)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
2:34 a.m.
New subject: Preventing account takeovers through expired domains
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
9:43 a.m.
New subject: Preventing account takeovers through expired domains
On Mon, Feb 21, 2022 at 8:35 AM Alexander Bokovoy <abokovoy(a)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.
4:03 a.m.
New subject: 2FA (was: Preventing account takeovers through expired domains)
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
5:14 a.m.
New subject: 2FA (was: Preventing account takeovers through expired domains)
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
Fabio Alessandro Locati
fale.io
12:25 p.m.
New subject: Preventing account takeovers through expired domains
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
1:16 p.m.
New subject: Preventing account takeovers through expired domains
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:14 p.m.
New subject: Preventing account takeovers through expired domains
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
9:17 p.m.
New subject: Preventing account takeovers through expired domains
On Tue, Feb 22, 2022 at 2:15 AM Demi Marie Obenour <demiobenour(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
10:35 p.m.
New subject: Preventing account takeovers through expired domains
On 2/21/22 22:17, Ian McInerney via devel wrote:
On Tue, Feb 22, 2022 at 2:15 AM Demi Marie Obenour
<demiobenour(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
2:25 a.m.
New subject: Preventing account takeovers through expired domains
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:22 a.m.
New subject: Preventing account takeovers through expired domains
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?
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:03 p.m.
New subject: Preventing account takeovers through expired domains
On Mon, Feb 21, 2022 at 7:17 PM Vitaly Zaitsev via devel
<devel(a)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.
3:24 a.m.
New subject: Preventing account takeovers through expired domains
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:33 a.m.
New subject: Preventing account takeovers through expired domains
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
12:23 p.m.
New subject: Preventing account takeovers through expired domains
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
--
Sincerely,
Demi Marie Obenour (she/her/hers)
3:53 p.m.
New subject: Preventing account takeovers through expired domains
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
4:54 p.m.
New subject: Preventing account takeovers through expired domains
On Tue, Feb 22, 2022 at 9:54 PM Kevin Fenzi <kevin(a)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....).
3:33 a.m.
New subject: Preventing account takeovers through expired domains
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).
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:58 a.m.
New subject: Preventing account takeovers through expired domains
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
12:10 p.m.
New subject: Preventing account takeovers through expired domains
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:
1. 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.
2. 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
11:18 a.m.
New subject: 2FA (was: Preventing account takeovers through expired domains)
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
10:48 a.m.
New subject: Preventing account takeovers through expired domains
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
735
days inactive
804
days old
91 comments
23 participants
participants (23)
-
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