First of all, I'd like to thank @jacob-carlborg for developing and actively maintaining this action ❤️ - it's very cool and useful! I just wanted to share one small thing that's been bugging me for a while:
As can be seen from the workflow run logs, this action downloads artifacts from other repositories at the beginning of its run - something like this:
Setting up VM
Downloading disk image: https://github.com/cross-platform-actions/netbsd-builder/releases/download/v0.5.1/netbsd-10.1-x86-64.qcow2
Downloading hypervisor: https://github.com/cross-platform-actions/resources/releases/download/v0.11.0/qemu-system-x86_64-linux.tar
Downloading resources: https://github.com/cross-platform-actions/resources/releases/download/v0.11.0/resources-linux.tar
The corresponding piece of code triggering these downloads is here:
|
download(): [Promise<string>, Promise<string>, Promise<string>] { |
|
return [ |
|
this.action.downloadDiskImage(), |
|
this.action.download('hypervisor', this.operatingSystem.hypervisorUrl), |
|
this.action.download('resources', this.operatingSystem.resourcesUrl) |
|
] |
|
} |
The problem is that all releases in https://github.com/cross-platform-actions/netbsd-builder/releases and https://github.com/cross-platform-actions/resources/releases are mutable, and this repo (cross-platform-actions/action) blindly trusts the downloaded artifacts without verifying their integrity. This makes this action unpinnable: there is nothing we as consumers can do to prevent potential tampering with the downloaded artifacts from these mutable releases. I believe you wouldn't do this intentionally, but the very fact that it is possible at all and that the action wouldn't notice poses a potential risk.
There are two ways to fix this:
-
Enable immutable releases in all repositories from which this action downloads any artifacts.
-
Embed expected SHA-256 hashes in src/version.ts (which seems like a logical place, since whenever you update the version, you would also need to update the corresponding SHA-256 hashes) and verify the actual SHA-256 hash of each downloaded artifact against its expected value. (This would be the only option if immutable releases could not be used.)
For example, this is the approach taken by https://github.com/zizmorcore/zizmor-action (see support/versions and action.sh:75). However, I can imagine that in the case of https://github.com/cross-platform-actions/action, it would be inconvenient to manage the expected SHA-256 hashes for all individual files: for example https://github.com/cross-platform-actions/netbsd-builder/releases/tag/v0.5.1 has 7 assets.
I can think of a possible workaround: include another asset in each release (in https://github.com/cross-platform-actions/netbsd-builder/releases and other repos) called CHECKSUMS.txt, which would record the SHA-256 hashes of all the actual release assets. Only the SHA-256 hash of the CHECKSUMS.txt file itself would be put in src/version.ts next to each version. Whenever the action wanted to download an artifact from a specific release, it would download the asset plus CHECKSUMS.txt from the same release, check the integrity of CHECKSUMS.txt using the known SHA-256 hash first, then use it to look up the SHA-256 hash of the actual asset, and finally verify that as well.
Of course, immutable releases are probably simpler, but I still wanted to present this as an alternative solution :)
First of all, I'd like to thank @jacob-carlborg for developing and actively maintaining this action ❤️ - it's very cool and useful! I just wanted to share one small thing that's been bugging me for a while:
As can be seen from the workflow run logs, this action downloads artifacts from other repositories at the beginning of its run - something like this:
The corresponding piece of code triggering these downloads is here:
action/src/action/action.ts
Lines 292 to 298 in 13ec3be
The problem is that all releases in https://github.com/cross-platform-actions/netbsd-builder/releases and https://github.com/cross-platform-actions/resources/releases are mutable, and this repo (
cross-platform-actions/action) blindly trusts the downloaded artifacts without verifying their integrity. This makes this action unpinnable: there is nothing we as consumers can do to prevent potential tampering with the downloaded artifacts from these mutable releases. I believe you wouldn't do this intentionally, but the very fact that it is possible at all and that the action wouldn't notice poses a potential risk.There are two ways to fix this:
Enable immutable releases in all repositories from which this action downloads any artifacts.
Embed expected SHA-256 hashes in
src/version.ts(which seems like a logical place, since whenever you update the version, you would also need to update the corresponding SHA-256 hashes) and verify the actual SHA-256 hash of each downloaded artifact against its expected value. (This would be the only option if immutable releases could not be used.)For example, this is the approach taken by https://github.com/zizmorcore/zizmor-action (see
support/versionsandaction.sh:75). However, I can imagine that in the case of https://github.com/cross-platform-actions/action, it would be inconvenient to manage the expected SHA-256 hashes for all individual files: for example https://github.com/cross-platform-actions/netbsd-builder/releases/tag/v0.5.1 has 7 assets.I can think of a possible workaround: include another asset in each release (in https://github.com/cross-platform-actions/netbsd-builder/releases and other repos) called
CHECKSUMS.txt, which would record the SHA-256 hashes of all the actual release assets. Only the SHA-256 hash of theCHECKSUMS.txtfile itself would be put insrc/version.tsnext to each version. Whenever the action wanted to download an artifact from a specific release, it would download the asset plusCHECKSUMS.txtfrom the same release, check the integrity ofCHECKSUMS.txtusing the known SHA-256 hash first, then use it to look up the SHA-256 hash of the actual asset, and finally verify that as well.Of course, immutable releases are probably simpler, but I still wanted to present this as an alternative solution :)