> 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? >
What credentials are you talking about? IMHO, there should not be any ASF credentials available for a Jenkins job unless it is explicitly given by the workflow author to particular step. If you are aware of any credentials that are available for such a job - again, I urge you to reach out to secur...@apache.org as this is (as you correctly diagnosed) a huge security threat. By default all CI jobs should have "read only" credentials that should at most be able to mess with the artifacts of that particular job and nothing else. None of the artifacts generated by such a build should be made available to users. Even if you look at the release policy of ASF all relese artifacts should be built on the machines controlled by the release manager. This is a strict requirement of the release process: http://www.apache.org/legal/release-policy.html#owned-controlled-hardware So as long as such an ASF CI job cannot modify the repository and modify the code in a permanent way, it is far less of a threat. The problem with the issue solved by the INFRA is that it could permanently modify the ASF-owned repository (and thus reach the users!) without anyone noticing. This is the real issue. That does not scale. > Of course. And it is not needed as long the CI jobs have no write credentials to the repository unless explicitly given for a specific step - see above. > > That is why I say a malicious Maven Plugin can render havoc at ASF > Not as long as the build cannot write to the github repository and modify code. > Jenkins, and it could make > silent modifications to the ASF repositories. > Please report that to INFRA if you know how. to do it This is a serious security threat and IMHO it should be immediately stopped. > > The same goes for PIP and other dependencies. > Not if they have no credentials to modify the repo (if it's not - please report it to INFRA) > Vladimir > -- +48 660 796 129
