Stream: git-wasmtime

Topic: wasmtime / issue #2775 Move the "Subscribe to Label" work...

Wasmtime GitHub notifications bot (May 12 2026 at 00:54):

vados-cosmonic commented on issue #2775:

This is an incredibly old PR, but just want to note that pull_request_target is basically ""unsafe at any speed".

Was doing a quick check for it in this repo in light of some recent compromises, and found this so figured I'd leave a note for past-Bjorn (and it seems you never actually needed this I guess!)

Wasmtime GitHub notifications bot (May 12 2026 at 10:24):

bjorn3 commented on issue #2775:

My understanding is that pull_request_target is no less safe than the schedule trigger that is already used provided that you don't use template interpolation with the github variable (which this workflow doesn't) and don't run any code from a checkout of the PR (which this workflow doesn't either as it doesn't checkout any code at all, rather it uses the api to get just a list of files that changed). All pull_request_target based compromises I'm aware of violated one of those two requirements. FWIW the upstream labeler action does suggest using pull_request_target, so it should be safe against malicious inputs.

In any case I'm not a maintainer, so I don't get to decide if pull_request_target will be used or not.

Wasmtime GitHub notifications bot (May 12 2026 at 11:10):

vados-cosmonic commented on issue #2775:

I think you're right in that there's probably no point in discussing it (neither of us are maintainers) -- but just to be note, pull_request_target and schedule do not have the same risk profile there are limitations to schedule like only triggering workflows that exist on the default branch. pull_request_target is much harder to hold correctly.

In general the GH docs are pretty clear on how dangerous pull_request_target can be -- and many times it's pull_request_target + a combination of modified workflow files, etc.

My point was here that it seemed we could have been waiting for pull_request_target to implement this -- and just wanted to voice some opposition. If it can be done with schedule only that would be much more preferable.

Wasmtime GitHub notifications bot (May 12 2026 at 11:16):

bjorn3 commented on issue #2775:

there are limitations to schedule like only triggering workflows that exist on the default branch.

Right, forgot about that. That does indeed make pull_request_target more dangerous.

If it can be done with schedule only that would be much more preferable.

The only reason I would have liked pull_request_target is that it allows immediately labeling PRs rather than getting a notification about labeled PRs 15+ min later.

Wasmtime GitHub notifications bot (May 12 2026 at 11:32):

vados-cosmonic commented on issue #2775:

The only reason I would have liked pull_request_target is that it allows immediately labeling PRs rather than getting a notification about labeled PRs 15+ min later.

Ahhh this is a good point... I wonder if there is another way to do this now.

I asked AI and it looks like a combination of pull_request and workflow_run could theoretically work (haven't tried it though -- and making sure the workflow_run workflow is safe would also be a slight hiccup I think)

Wasmtime GitHub notifications bot (May 13 2026 at 11:09):

bjorn3 closed issue #2775:

https://github.com/bytecodealliance/wasmtime/blob/8bb1f8adc9e544010427fb5062f54a25cd3441ca/.github/workflows/subscribe-to-label.yml#L1-L10

Back when it was introduced, pull_request_target didn't exist yet.

Last updated: Jun 01 2026 at 09:49 UTC