Very simple. Submodule are a standard git feature and provide automated compliance with https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions
* submodules allow you to perform code review before the merge. You get links to the exact version of the code being brought in, when you pull changes you see the diff of changes. This is all part of the standard GitHub PR review process. This helps with "Audit the source code of the action" point from the "hardening" doc. * SHA of the commit is embedded in your repo (that's how submodules work). There is no way around that, this is part of submodule specification. This is an automated way of fulfilling the "Pin actions to a full length commit SHA" This comes 'for free' with submodule approach. SHA commit is stored in the git-tree (and Github uses it to show links that allow reviewing the code of the very version you bring in the repo and the diff). The proposal you gave is simply 'poor man's copy' of doing the same thing that submodule does (it effectively runs git clone under the hood same as your custom command), but it is less secure by default: * No SHA commit. In your example, you made the very security mistake by linking to `v1` branch that the change from INFRA was trying to prevent. You MUST use commit SHA. Even after all the discussions we had you do not "automatically" think this way, so imagine people who have not been in the discussion. Of course, one could use SHA commit in the checkout command as well, but it is optional and not enforceable. The sheer fact that you have not done it in your example, shows that submodule providing it out-of-the-box (and without thinking about it) is a better approach. * No support for Github-integrated code review. GitHub support for submodules provides an easy way for reviewer to see the exact code being added. This is an absolute requirement that the code of the action is audited by the maintainer before Action is used, and the "custom" solution will not be supporting reviewers in any way with that J. On Thu, Jan 7, 2021 at 5:39 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Jarek>What we propose: > Jarek>.gitmodules > > What is the purpose of git submodules here? > However, that suggests there's a way easier workaround (see PR > https://github.com/apache/calcite/pull/2318 ). > Action repository can be cloned right before the action is used. > No submodules needed, and the workaround works. > > Before: > > - uses: AdoptOpenJDK/install-jdk@v1 > with: > impl: openj9 > version: '8' > architecture: x64 > > After: > > - name: Prepare Actions > run: | > git clone -c advice.detachedHead=false --branch v1 --depth 1 > https://github.com/AdoptOpenJDK/install-jdk.git > ./build/.actions/install-jdk > - uses: ./build/.actions/install-jdk > with: > impl: openj9 > version: '8' > architecture: x64 > > Vladimir > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
