fix: update transfer-issue.yml

[spc-28]

Description

Addresses /ti command permission errors by using secrets.GH_TOKEN instead of secrets.GITHUB_TOKEN (limited to current repo only).

Issue: #344

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[Shurtu-gal]

@spc-28 this might work but it was done like this in #342 probably due to security reason or due to it not working with GH_TOKEN as well.

[spc-28]

@Shurtu-gal then i think we should try, GitHub App token that is more secure and organization managed, but requires one time GitHub App setup by org admins

[Shurtu-gal]

I don't understand how does that manage to make this more secure?

[Shurtu-gal]

I don't understand how does that manage to make this more secure?

[spc-28]

Like instead of using a token tied to a specific account or user, we use an org owned app that only has the permissions we define and doesn’t depend on any user and can be installed to any repo
And also currently i think both GITHUB_TOKEN and GH_TOKEN have permission/scope limitations causing this transfer issue

[Shurtu-gal]

GH_TOKEN has the requisite permission but the workflow itself becomes a large attack surface.

[spc-28]

While reviewing the workflow, I noticed a few areas where we could add some safeguards.
For example, at the moment anyone can trigger the /ti command, if a random user comments /ti on any issue in a repo, the workflow runs without checking whether they’re authorized to do so.

There are a few other similar points as well. They’re not major issues right now, but addressing them could help make the workflow more secure and future proof.

Let me know what you think.