search

snapcrafters / mattermost-desktop

A community-maintained package to easily install Mattermost Desktop on Linux
https://snapcraft.io/mattermost-desktop/
MIT License
11 stars 7 forks source link

docs: update snapcraft.yaml to include more detailed metadata #88

Closed jnsgruk closed 1 year ago

jnsgruk commented 1 year ago

Replacement for #87 - the branch randomly became protected, so I was unable to push more commits :man_shrugging:

jnsgruk commented 1 year ago

@merlijn-sebrechts might be worth adjusting the protected branch settings so they only apply to candidate :)

In fact - I need to push a change here and can't - I'll wait on the branch not being protected.

merlijn-sebrechts commented 1 year ago

Oh, wow, you should not be allowed to create new branches on this repo :scream:

jnsgruk commented 1 year ago

Hah, okay well feel free to close this, and I'll open from a fork - would you prefer that?

merlijn-sebrechts commented 1 year ago

Yes, create a fork please.

I modified the permissions, so it should now suggest to create a fork when you edit using the web ui and disallow you from creating a new branch. Can you check this?

merlijn-sebrechts commented 1 year ago

Snapcrafters had "maintainer" permissions instead of "write" permissions. As a result, they could bypass some branch protection features and access some settings of the repos.

To give some context, because this might seem draconian:

Creating new branches is a common way to steal repository secrets and gain unauthorized access to a repository. I locked this down specifically to prevent such attacks. We also use an Environment locked to the candidate branch as a second layer of defense against stealing these secrets.

Permissions and security for GitHub actions and Secrets is quite difficult to get right, and it's made worse by

As we just saw, these permissions are hard to get right, and we were "saved" right now by the fact we had two layers of defense (Disallow creating new branches + Using Environments for secrets). As a result, I think we need to keep it like this. This protects us against both configuration errors (like this one) and actual GitHub vulnerabilities. People have been able to find many vulnerabilities in GitHub actions, and I want to avoid such a vulnerability giving people access to our large userbase.