Include yarn.lock in distributed files

[rethab]

Hey 👋

Would it be possible to add yarn.lock to the files in package.json?

In a world where supply chain security becomes more prevalent, it would be nice to be able to track exactly what the action was built on. For example, if I wanted to know what libraries were used in release v1.4.0 I'd have to look at the history of package.json in order to know what content was used to create this release.

This happens because, the way this action is released (create separate branch, move only some of the files) makes it difficult to trace back what the release was built on.

If yarn.lock was included in the files in package.json, and it would be included in the distributed files (tar.gz) and therefore, it would be possible to take a tag (e.g. v1.4.0), look at the yarn.lock and know what exact versions of libraries were used.

I'm happy to create a PR if you agree.

Thanks

[tibdex]

If yarn.lock was included in the files in package.json, and it would be included in the distributed files (tar.gz) and therefore, it would be possible to take a tag (e.g. v1.4.0), look at the yarn.lock and know what exact versions of libraries were used.

If the goal is to ensure supply chain security, adding the yarn.lock to the released files would not be enough. Indeed, if you don't trust the release script, you could imagine it ignoring the yarn.lock and bundling other deps in the released files instead.

the way this action is released (create separate branch, move only some of the files) makes it difficult to trace back what the release was built on.

This action is released using https://github.com/DylanVann/publish-github-action/tree/v1.1.49, you can inspect the code there and, once you trust it (it's bootstrapped so you can apply the same logic to inspect its released files), you can then trust that the released files of all actions using publish-github-action have not been tempered with.

One way to trace back a release to the yarn.lock at the time of the build is to look at this list and look for the workflow that started just before the tag creation. For instance, for v1.5.1, which was released on Dec 05 2021, the corresponding workflow is this one and it ran on commit cd81e4c.

[rethab]

I know this is not a tamper-proof solution, but at least it gives me some way of knowing what was included. Looking at the actions surely works, but I'm looking for an automated solution that gives me most of what I want with minimal effort :)

In particular, I'm not looking to ensure nobody has fiddled with the release script and thereby included a malicious dependency. And I am aware that tags could be updated to point to something completely different. What I am looking for is knowing what version of what is included such that I can tell if there is a vulnerability in this action.

[tibdex]

I consider the current process simple and secure and I'm not willing to spend time working on or reviewing something to change this. I'm thus closing this.