Show a warning in workflow runs suspect of building in the publish job

[webknjaz]

Previously, I didn't know if it's possible to detect. However, I just occurred to me that this can be inferred from the environment state. I think that we should be able to inspect the presence of other actions being checked out on disk to see if there's anything beyond pypa/gh-action-pypi-publish and actions/download-artifact present in the actions cache directory.

[webknjaz]

I just realized that it's as simple as detecting the presence of .git/ in CWD. Somebody downloading artifacts from another job wouldn't use actions/checkout and so there wouldn't be a Git repository in the first place. #363 is what inspired me with this idea.

[webknjaz]

I just realized that it's as simple as detecting the presence of .git/ in CWD.

Another tell could be the presence of anything besides dist/ (or the packages-dir value).

[Spacetown]

I think this is a bad idea. Publishing can contain several things like creating a GH release and adding a tag. Uploading to PyPI is only one part of the process and I wouldn't force the user to do this in several jobs.

[webknjaz]

This is necessary to be secure by default. So I'm limiting footguns. It's already stated in the README that those configs are unsupported. This will just add a more prominent warning. People tend to abuse what's available in ways that compromise security and I don't want to encourage that. I might make it opt out with an explicit confirmation of the consequences, though.
This project is security-sensitive, while the maintenance resources are limited, which is why I'm going to keep making such unpopular improvements.

[Spacetown]

Some workflows need to be allowed, e.g. the download of the Artifacts. If the opt out would be by specifying the tasks with an explicit commit hash I'm fine.

[webknjaz]

That's an action, not a workflow. We can't see the list of steps programmatically, which is why I'm looking at ways of infer possible insecure uses from the env. Having a download step, followed by an upload step is the only thing I declared supported. Anything else either has regular disadvantages or is straight up dangerous. In general, keeping everything else in separate jobs will work for anyone. So that's what I'm settling on. And the planned reusable workflow will be separate anyway.

[Spacetown]

Using several jobs will work but can be error-prone. E.g. the condition needs to be the same in every job to not have an incomplete release.
You can advise how to write the workflow but shouldn't dictate it.

[copilot-swe-agent]

@webknjaz I hit the following errors while trying to work on issue #324.

• Branch creation is blocked due to repository rules
• Branch name restrictions apply (must match regex ***) due to repository rules

Note

• To learn about managing repository rules, head to the GitHub Docs.

After resolving these issues, you can ask me to try again by unassigning and then reassigning the issue to me again.