Description
GitHub code scanning tool reports we don't pin Istio dependency
The problem is in the scripts/install/istioctl_install.sh:31
We don't pin it indeed.
By "pinning" I mean using some sort of cryptographic hash to uniquely identify the version.
As we're not using any standard dependency management tool, but we're just downloading the binary from the release page, we can't just "pin" it declaratively.
What we can do though is to extend the scripts/install/istioctl_install.sh script to verify the download file digest.
The question is how we then store the digest.
I vote for extending the versions.yaml file in the following way:
currently:
istio: "1.26.4"
after changes
`istio: "1.26.4@bd9844087a51e8429823579a40a8cfa9da20268dd368151a24be910eebcd1445"
In this way, it's clear the version is "pinned" and we have to handle the digest in every place we're using the value.
Feel free to propose another solution though, if there is a better one or this one can't be implemented.
Reasons
Reduce the risk of "supply-chain-attack".
No response
Acceptance Criteria
See also
#2645
Description
GitHub code scanning tool reports we don't pin Istio dependency
The problem is in the
scripts/install/istioctl_install.sh:31We don't pin it indeed.
By "pinning" I mean using some sort of cryptographic hash to uniquely identify the version.
As we're not using any standard dependency management tool, but we're just downloading the binary from the release page, we can't just "pin" it declaratively.
What we can do though is to extend the
scripts/install/istioctl_install.shscript to verify the download file digest.The question is how we then store the digest.
I vote for extending the
versions.yamlfile in the following way:currently:
istio: "1.26.4"after changes
`istio: "1.26.4@bd9844087a51e8429823579a40a8cfa9da20268dd368151a24be910eebcd1445"
In this way, it's clear the version is "pinned" and we have to handle the digest in every place we're using the value.
Feel free to propose another solution though, if there is a better one or this one can't be implemented.
Reasons
Reduce the risk of "supply-chain-attack".
No response
Acceptance Criteria
See also
#2645