GitHub Workflows security hardening

[sashashura]

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted. It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

[welcome[bot]]

BOOM! Your first PR with us, thank you so much! Someone will take a look at it shortly.

Please keep in mind that:

• if this constitutes a breaking change, it might take quite a while for this to get merged; we try to emulate the Laravel release cycle as much as possible, so developers can upgrade both software once; this means a new big release every ~6 months;
• even if it's a non-breaking change, it might take a few days/weeks for the PR to get merged; unless it's a no-brainer, we like to have some community feedback on new features, before we merge them; this leads to higher-quality code, in the end; we learnt this the hard way :-)
• not all PRs get merged; sometimes we just have to hold out new features, to keep the packages lean; sometimes we don't include features that only apply to niche use cases;
• we're not perfect; if you think we're wrong, call us out on it; but in a kind way :-) we all make mistakes, best we learn from them and build better software together;

Thank you!

-- Justin Case The Backpack Robot

[pxpm]

In-te-res-ting!! 🤩 Thanks @sashashura !

Did you happen to run the scorecard tool on our repo ? Can you share the results?

Cheers

[sashashura]

I didn't. BTW, I just removed projects: write permission because it is not need. I missed that you use a separate token.

[sashashura]

Just for the reference these are the current permissions one of the workflows runs with:

[tabacitu]

Oh that's interesting @sashashura , thanks! Sure, sounds like a sensible change, let's give it a try 💪

Wouldn't our add-to-project action need write access to issues, though? 👀 To move them to a certain project? 🤷‍♂️

[welcome[bot]]

WHOOP-WHOOP! Congrats, your first PR on this repo has officialy been merged.

You should also receive an email inviting you to the Community Members team. That's where we, commited community members, debate new features and decide what's in the Backpack roadmap. Feel free to ignore the invitation if you're not interested :-)

If you want to help out the community in other ways, you can:

• give your opinion on other Github Issues & PRs;
• chat with others in the Gitter Chatroom (usually for quick help: How do I do X);
• answer Backpack questions on Stackoverflow; you get points, people get help; you can subscribe to the backpack-for-laravel tag by adding a new filter; that will send you emails when new questions come up with our tag;

Again. Thank you for the PR. You are a wonderful person. Keep 'em coming :-) Cheers!

-- Justin Case The Backpack Robot

P.S. Help in the Backpack community is rewarded with free Backpack commercial licenses. It's the least we can do. If you feel you've helped the community with PRs, help & other stuff, please apply for free licenses and mention this PR. You scratch my back, I scratch your back. Thank you!

[sashashura]

Oh that's interesting @sashashura , thanks! Sure, sounds like a sensible change, let's give it a try 💪

Wouldn't our add-to-project action need write access to issues, though? 👀 To move them to a certain project? 🤷‍♂️

You don't need it because you are using a dedicated secrets.ADD_TO_PROJECT_PAT token for that.