Security question

[flooie]

@casperdcl Thank you for sharing this action.

I want to ask if you considered whether someone could take over this action and inject malicious code into a project build? If so, is the safest course of action forking this project in your opinion?

[casperdcl]

well

• my account could be hacked (unlikely given my paranoia over the devastation this would cause to a bunch of widely used projects)
• if you were to fork this repo, your account could be hacked
• in any case, any aspect of GitHub/actions could be hacked

Really if you are developing a security-sensitive application I would stay well away from any cloud-based CI/CD provider and just build everything locally.

[mlissner]

I work with @flooie, so we're having some conversations about this offline, but I wonder if it's worth tweaking the readme to encourage folks to fork the repo instead of using it directly in their actions.

The description for this project says that it's "secure", but people may not realize that using it puts their trust in your diligence, honesty, paranoia, etc.

For us, there's a big difference between trusting an organization like Github to do CI/CD, and trusting somebody that just happens to have posted some code. Github has lots of skin in the game and would have hell on their shoulders if something went wrong in the Github Actions pipeline. You're just a friendly person (I think).

Would you be open to a PR recommending folks fork the repo instead of using it directly?

[casperdcl]

Hmm. Faith in my continued friendliness notwithstanding, I don't know if forking this project is more secure than using it directly. If anything, it's less secure.

• Say a new bug is discovered and fixed in SSL - I'd update the Dockerfile here to use the latest version, and anyone using the action will immediately get the fix.
• If I'm slow to notice the bug, anyone else using this action could open a PR first.

I believe this is the point of open source projects on https://github.com/marketplace/actions/ (of which this repo is a part of).

Regarding me potentially turning evil and deliberately pushing malicious code to this action (I think this is your only fear?) the result would be the same as if I accidentally pushed malicious code:

• users would notice
• anyone could open a PR to fix the issue
• anyone could ask GitHub to step in if I am unresponsive
• the more people use this project, the less likely it is that anything could go unnoticed
• by comparison, individual forks are unlikely to be reviewed or updated by anyone

I believe this is the point of open source projects.

To clarify, I think

• the probability of my account being hacked is approximately the same as the probability of any other user's account being hacked
• said probability is much higher than the probability of malicious code now or ever existing in this repo (the Dockerfile & script.sh are around 20 lines of code each so easy to review)

If you don't trust the code in this repo, then forking it won't help. If you do trust the code in this repo at a particular point in time because you have read & reviewed the code, and you would like to avoid exposing yourself to potentially harmful future changes (and future fixes), then instead of

- uses: casperdcl/deploy-pypi@v1

you could directly use the commit which you trust, currently:

- uses: casperdcl/deploy-pypi@2a65036fc8fc508613948b629e7ebb9ace717720

This should be as "safe" as forking with the added benefit of being easier to manage (and also recommended by https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions). You'd have to closely monitor the original repo for bug/security fixes and manually update the commit hash when needed. My understanding is any user who wants to do this doesn't need instructions.

You make a distinction between

• "trusting an organization like Github," and
• "trusting somebody that just happens to have posted some code."

I would strongly argue that there is a third category, which is

• "trusting somebody that regularly posts code."

This latter category is identical to "trusting somebody that regularly posts news," which aptly describes the most recent post on https://free.law/ I agree with that article - someone who regularly posts is indeed often more trustworthy than an organisation - they have more experience that the average employee of said org, yet lack a large legal team to protect them if they make a mistake, so are more likely to be very careful.

I actively develop a lot of other open source repos which are downloaded millions of times a month so if I'm a dog everyone's barked.

[mlissner]

I appreciate the lengthy reply, thank you. You're right that there's a lot to be gained by centralizing risk, and I apologize for not looking at your profile sooner.

I think we'll move away from using our fork and instead take your advice about using a commit to lock into a particular release. I wonder if there's a benefit to moving this conversation to the readme in a short section called "Trust", that'd just say, "How can you trust this action?", and then explain as above.

[casperdcl]

@mlissner @flooie thanks for your input - just released v2 of this action which adds several new features and makes things even easier to review.

[flooie]

@casperdcl thank you.