I prefer constructive approach rather than criticising and complaining, and I think we found (together with Ash) even better approach with submodules.
Daniel - I know you will be working on the infra side on that - I think you should consider making the below submodule approach the "highly recommended" or even "the only supported" one. It seems to solve all the problems without impacting the "action" workflow too much. I think we have a perfect solution in Airflow that can be applied by everyone @apache and might become something easily verifiable at scanning It seems we found a way to add the actions as submodules rather than subrepo. IMHO it passes all security requirements. It's as easy as incorporating the actions before the security policy change, you do not have to copy anything, yet you keep the review "requirement" and "SHA" requirement. You can easily add any action from any source, but it forces you to review it and pin it to a specific SHA version. It looks perfect and it works for us - we are going to migrate Airflow to this approach: The PR with working POC here: https://github.com/apache/airflow/pull/13514 This seems to works perfectly: 1) It always links to particular SHA commit not branch 2) No code duplication 3) GitHub Review nicely incorporates the change code from submodules whenever submodule is updated, so it fits naturally in the review workflow. 4) Seems that we can easily make it works with Github Actions (the submodule needst to be checked out in previous step of the job). 5) It's even easier to pull new versions. 6) It is equally easy to add any external action at any time 7) Passes all the INFRA requirements re: review + SHA - without any checks I think we should enforce it on INFRA level if you want to use 3rd-party action :). Now, just to close the discussion with Vladimir. On Wed, Jan 6, 2021 at 3:02 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Jarek>Actions are usually rather small > > https://github.com/burrunan/gradle-cache-action becomes 3 megabytes of > JavaScript when compiled. > It takes a couple of minutes to build the action itself. > You do need to compile it yourself. Regardless of the way you link it (marketplace, SHA etc. it uses pre-compiled javascript. Which is another problem of course because you should do a check if the javascript comes from the sources, but this is another story. And it is invalidated by using submodule anyway. > Jarek>but judging from some recent discussions > Jarek>this is very clear from legal point of view they only care about the > Jarek>releases > > That contradicts the blocking of the third-party actions. > The actions can't perform the release, and they can't impact/augment the > release file. > They can change source code that is used to prepare release without you knowing it. Vladimir. This is even worse. > If the only thing they care is release, then actions are not a problem at > all. > My argument was about LEGAL and LICENCES. This is a different topic than SECURITY. You've changed the subject mid-discussion Vladimir.. > Legal/resolved>CAN I COPY CODE FROM STACK OVERFLOW AND CONTRIBUTE IT TO AN > ASF PROJECT? > Leval/resolved>*No*, not without contacting the original author and getting > permission from them to use the code in an Apache project under the Apache > License 2.0. > Here 100% agreement. If you read carefully what I wrote, "So as long the licence allows to copy the code, placing it in your repo has no legal implications.". You still need to check if the licence allows copying the code (This one is usually easy). But it has nothing to do with licence for redistributing the code. This is a totally different legal issue. And the stack overflow issue is about that, not about redistributing that code (which should not happen in this case). Regardless - the whole point is not valid in the 'submodule' case anyway, so let's stop here. It does not bring any value to this discussion. > > That explicitly forbids copy-paste from Stack Overflow. > In other words, the ASF repositories must not have doubtful code. > I never said that. Please re-read "So as long the licence allows to copy the code, placing it in you repo has no legal implications." > The action itself has NO extra access. > Developer grants the access by adding GITHUB_TOKEN to the yaml file. > > That is easily verifiable, and everybody can control that from the workflow > provided they use SHA > for action reference. > It is, as long as you know that's the case and it's not contradicting the documentation. Quoting your own words from the thread: > Vladimir: Once again: GITHUB_TOKEN has to be explicitly used in the YAML file. If GITHUB_TOKEN is not mentioned in the YAML, then write access is NOT possible. I do not know how long you used the GA, but I do it since very beginning of it, and neither me, nor you knew about the 'action.xml" and we thought access has to be granted via the Yaml file. I created another critical security vulnerability for it and I hope they will fix it as well. > The verification is way easier than copy-paste-subprepo dance. > There is no copy-paste subrepo. The tool does it for you. Anyway we can close the topic because submodule works perfectly well and does not require copy&paste. > You seem to assume that "almost every action would need GITHUB_TOKEN for a > good reason". > On the other hand, I assume that GITHUB_TOKEN-based actions must not be > used (or they should have extra isolation). > > There was a case that actions/checkout cached the credentials to a file, > and the file can easily be read by a Maven plugin. > That is why I say actions have virtually the same power as the build script > plugins. > This is why I opened a critical security issue to GitHub to end that madness with checkout action. I hope they will cut it. And also you can still control it in your workflow by adding 'persist-credentials' to false. Which should be added as "no-go" if missing when any kind of scanning is implemented by Infra. > > Jarek>I do not think (but correct me if I am wrong) that this is the case. > > Please check ICLA: http://www.apache.org/licenses/icla.pdf > > ICLA>7. Should You wish to submit work that is not Your original creation, > ICLA>You may submit it to the Foundation separately from any Contribution, > ICLA>identifying the complete details of its source and of any license or > other restriction... > ICLA> (including, but not limited to, related patents, trademarks, and > license agreements) > ICLA>of which you are personally aware, and conspicuously marking the work > as "Submitted on behalf of a third-party: [named here]" > > That means everybody who contributes third-party code to a repository must > perform license clearance. > You cannot push random stuff to the ASF repository even if you are a PMC. > My understanding is, It's only when you submit it to be owned by foundation and you want to submit it separately: "You may submit it to the Foundation separately from any Contribution," There are no such restrictions if you put it as part of your repo, the license allows that and there is a clear statement who owns it. This happens for example when you want to vendor-in any 3rd-party library (which also might happen from legal reasons). We've done that in the past in Airflow for example here: https://github.com/apache/airflow/tree/1.10.4/airflow/_vendor If you state the origin and licence, you do not need special clearance. I am pretty sure of that because Airflow passed all the reviews while we graduated from incubator to the TLP and those were then part of the repository. We removed them since because the licensing issues were removed in the 3rd-party libraries but I am quite sure you do not need special clearance to embed 3rd-party code as long as the licences allow and you specify the origin. This is anyhow not valid with the submodule approach, so let's stop the discussion here, it does not bring any value to the problem. > > Jarek>if I DELETE the repo, I will immediately impact > Jarek>all other projects using them > > I mean ASF-wide repositories rather than your personal ones. > Those are "airflow-" repositories not personal ones. And submodule approach invalidates the need of having separate repos at all. We can use the original repos without breaking the requirements from INFRA. > > Vladimir > -- +48 660 796 129
