The code in GitHub is very trustworthy as commit hashes uniquely identify the code and the code can be verified to not be malicious. However, the code can directly only be used in very few places - even simple NPM modules need to be separately packaged as a distributable.
Distributables, or builds, on the other hand are not trustworthy at all. There is nothing confirming that they match the code they are said to match - they could contain just about anything and most people would not even notice. The only way to use code safely from github is to always build it yourself, which has other problems.
This obviously cannot be solved when GitHub is not the one building the code - but now with the advent of Actions, GitHub can also be the system that does the build. So my question is that is there any way to publish artifacts in such a manner that it would be verifiable that these artifacts were produced exactly by this commit sha, which contains the entire contents of the actions workflow as well?
Uploading “release assets” is not verified in any way, so there’s no way to know what produced a binary that is attached to a release. Uploading packages to GitHub Packages is likewise not verified, although there is some magic going on there I think? In any case, GitHub Packages does not support simple tarballs as releases, but instead would need to be wrapped in some package managers package. Uploading artifacts during an actions build *might* be secure - I have yet to verify it, but it might be that “publish” plugin that it uses ensures that no other action could ever produce artifacts for a different action than itself. However, artifacts are stored for 90 days only, there is no REST API to access them and they are pretty well hidden in the actions so not really a solution.
What would be needed would be a place where build outputs / releases / packages could be stored tied to the hash of the git commit that produced them.