Vladimir, You did not convince me at all, that hand-crafted approach is almost the same security as submodule.
I simply don't agree with that statement and I think it simply best to agree that we disagree and saying it's less secure is completely unfounded (again this is my opinion, with which you might not agree but seems there is no way we can come to an agreement). I stand by my recommendation to use submodules as "best practice" and I ask the infra to consider that as the only allowed approach when they do their tools to verify it (in case I am asked). Again, not me to decide. But my recommendation is still valid. J. On Thu, Jan 7, 2021 at 9:18 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > 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 > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
