Jarek> I am proposing here is just the way Jarek>how we've done that at Airflow
Jarek, sharing the experience is awesome. No kidding. I did review Airflow actions, there are nice bits, however, I believe I do not need those. The workflows of my projects are way simpler. However, you suggested making submodules "the only supported" which sounds wrong, that is why I clarify how it can break (e.g. unreviewable diffs thanks to multi-megabyte JS dependencies, and so on). Here's the quote I refer to: Jarek>I think we found (together with Ash) even better approach with submodules. Jarek>Daniel - I know you will be working on the infra side on that - I think you Jarek>should Jarek>consider making the below submodule approach the "highly recommended" or Jarek>even Jarek>"the only supported" one. It seems to solve all the problems without Jarek>impacting the "action" workflow too much Note: I do not want to add submodules for the sole purpose of "working with GitHub Actions". Even though submodules is Git standard feature, it might interfere in strange ways with other features like Git Worktrees, JGit, and so on. I do not want to add complexity when simpler solutions are possible. ---- Jarek>This is what we found after few iterations is great balance of security and usability My key point is that the submodule-based (and git clone-based) approach is LESS secure than regular "uses: AdoptOpenJDK/install-jdk@..." + validation that all references are SHA-based For instance, there might be an Apache Yetus check, GitHub Action (does one already exist?), and so on. I agree submodules might help in certain cases (e.g. when action code is 5-10 lines, then GitHub can render diff). In the mean-time, I filed a couple of requests to allow actions I need for Calcite and JMeter: https://issues.apache.org/jira/browse/INFRA-21275, https://issues.apache.org/jira/browse/INFRA-21283. I treat this "security" issue like a recent "JUnit 4.13.1 madness". There was a security issue fixed in TemporaryFolder, and dependabots of all sorts spammed everybody while the net profit was very low as TemporaryFolder is not used often. Jarek>We are talking about GitHub Actions. Please correct me if I am wrong ASF infra supports GitHub mirrors for SVN repositories, so tying actions to submodules is the wrong path. That is SVN-based repositories can use GitHub actions which I guess Apache JMeter used before the switch to Git. Jarek>No user/contributor needs to know about them Jarek>Only those who add actions need to learn about submodules. Usually those Jarek>will be CI-masters IDEs and other tools might have their peculiarities with submodules. There are lots of "release scripts" and "release steps" that might need to be revised to account for submodules. I believe the committers/PMCs are smart enough to review the code they merge, and they can use automatic tools that ensure the actions are SHA-pinned. However, submodules and "git clone ...action" do not improve security, yet they make it harder to automatically analyze workflow.yml. Jarek>Again is the matter of 'thinking' this way I have updated the PR so it uses SHA. Could you please stop making that comment? https://github.com/apache/calcite/pull/2318 Note: if infra approves actions (which I hope happens soon), then the workaround would not be needed. The key point was to show that repo/action@sha, submodule, and git-clone based approaches have almost the same level of security. Vladimir
