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)