Jarek>One comment about PIP/NPM packages - it's a very different level of threat Jarek>IMHO.
It is different, however, it is way more serious. That is why it is wrong to make such a disruption for GitHub Actions while we keep the door open for NPM/PIP/Maven/Ant/... issues. Jarek>Installing and even running commands via PIP does not expose GITHUB_TOKEN (and this is the real threat). It at most exposes the local build Running PIP at the ASF Jenkins instance (e.g. https://ci-beam.apache.org/ ) exposes ASF credentials to a malicious PIP package. Does that mean every upgrade of a PIP/NPM package must be analyzed by infra? That does not scale. Jarek>Github Actions runners are fully isolated and managed (and monitored) Jarek>explicitly by the GitHub team so that each job is isolated Here's what I said: "A compromise of a single build script plugin...". Note: I mean regular build systems like Apache Maven, Apache Ant, Gradle, etc, etc. They all have non-trivial code, and they all have external plugins. Even Apache Maven requires non-Apache plugins to build itself. On top of that, Maven lacks the in-core ability to verify the integrity of the artifacts it downloads. There's no way to pin a dependency (plugin or runtime dependency) to a checksum. That is why I say a malicious Maven Plugin can render havoc at ASF Jenkins, and it could make silent modifications to the ASF repositories. The same goes for PIP and other dependencies. Does that mean the next step is to forbid all non-ASF build systems and the corresponding plugins? Vladimir
