torchi: Remove unprivileged access to ciflow

[seemethere]

Removes the ability for users who are unprivileged to apply ciflow labels to PRs. This is a potential security risk since it allows for the following workflow:

• Users submits benign PR
• Maintainer approves workflows to be run
• User modifies PR to include malicious code in workflows triggered by ciflow
• User uses @pytorchbot label ciflow/<bleh> to apply ciflow labels

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
torchci	✅ Ready (Inspect)	Visit Preview	Feb 24, 2025 7:01pm

[atalman]

lgtm

[huydhn]

IMO, we could consider removing @pytorchbot label altogether after this. This mechanism is built to allow people without write permission to add ciflow label, which turns out to be a loophole that folks can exploit. If you already have write access, it's easier to just add the label directly into the PR.

[ZainRizvi]

IMO, we could consider removing @pytorchbot label altogether after this. This mechanism is built to allow people without write permission to add ciflow label, which turns out to be a loophole that folks can exploit. If you already have write access, it's easier to just add the label directly into the PR.

@huydhn we still have other classes of labels like "topic: ..." and "release notes:...". Edit: They are used regularly (example)

[malfet]

IMO it does not solve the underlying if user pushes malitious change after someone adds ciflow/ label. Bot should not create tags if workflows are not approved

[huydhn]

@huydhn we still have other classes of labels like "topic: ..." and "release notes:...". Actually, do people manually add those using pytorchbot...?

Good point, there might be folks without write permission trying to add these labels, but it's probably rare because these labels are mostly added automatically or added by the reviewer. Given the issue today, it makes sense to reduce the attack surface by removing @pytorchbot label. But that's up to discussion.

[ZainRizvi]

@huydhn we still have other classes of labels like "topic: ..." and "release notes:...". Actually, do people manually add those using pytorchbot...?

Good point, there might be folks without write permission trying to add these labels, but it's probably rare because these labels are mostly added automatically or added by the reviewer. Given the issue today, it makes sense to reduce the attack surface by removing @pytorchbot label. But that's up to discussion.

As per clickhouse, in the past 4 weeks these labels were added 140 times by folks who's author_association was not MEMBER (204 if you include MEMBER)

[huydhn]

Hmm, there is also keep-going which has legit use. So, it seem that we won't be able to remove @pytorchbot label then.

[zxiiro]

@huydhn we still have other classes of labels like "topic: ..." and "release notes:...". Actually, do people manually add those using pytorchbot...?

Good point, there might be folks without write permission trying to add these labels, but it's probably rare because these labels are mostly added automatically or added by the reviewer. Given the issue today, it makes sense to reduce the attack surface by removing @pytorchbot label. But that's up to discussion.

As per clickhouse, in the past 4 weeks these labels were added 140 times by folks who's author_association was not MEMBER (204 if you include MEMBER)

For my understanding, I think MEMBER is someone who has explicitly been added to either the GitHub org or the repo with some level of permissions. Do regular contributors eventually become MEMBERs?

(I can't imagine very many drive by contributors will even know the ciflow labels exist.)

[seemethere]

Closed with:

• [bots] Check for permissions when syncing ciflow #6328