Re: Do we have any policy for disabling inactive users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux