Couple things about Jenkins credentials: 1. The credentials are stored encrypted in the controller and are dynamically decrypted and bound to jobs over the Jenkins remoting protocol. A malicious dependency would not be able to gain access to other credentials in Jenkins unless you're running your jobs on the controller itself (many people do this because they don't want to set up agents; if you do that, keep that Jenkins instance fully private as the security mechanisms can't do much without it due to the nature of executing arbitrary code as a feature rather than as a bug). As such, _no_ credentials are automatically injected into builds in Jenkins; the only credentials that may be pre-configured are for things like git checkout (in the job config itself), default email server settings, and any other global settings that might be configured.
2. When using gitbox URLs to checkout a repo in our Jenkins instances, these use a custom developed Jenkins plugin that doesn't require credentials (plus it's publicly accessible) while also supporting webhooks. 3. The only Jenkins agents we have that provide access to credentials which can write to ASF infrastructure that I know of are all in the websites node which have scripts and such explicitly to secure its use case (mostly via the .asf.yaml config options for your site branch). On Wed, 30 Dec 2020 at 04:42, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > Jarek>What credentials are you talking about? > > For instance, asfNexusUsername/asfNexusPassword (see > https://cwiki.apache.org/confluence/display/INFRA/Gradle+Installations ) > I assume there exists something like git-websites Jenkins node label that > has privileges to update project site ( > https://cwiki.apache.org/confluence/display/INFRA/Jenkins+node+labels ) > > Jarek>Not as long as the build cannot write to the github repository and > modify > Jarek>code. > > ASF Jenknis nodes are stateful, and they do have credentials of some kind. > On top of that, a malicious build script plugin could use developer's > credentials > to make changes to the repositories. > > Vladimir
