|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Just to clarify why externals need their own credentials.
There is a security risk in using Jenkins' credentials to checkout an external even if the external is the exact same repo as the module you are checking out.
Consider the case where a developer has commit access to /trunk/publicproject in the repo but does not have read access to /trunk/secretproject
The Jenkins admin has locked down Jenkins so that the developer cannot modify the Jenkins jobs.
With the old behaviour, the developer could just commit to /trunk/publicproject adding an svn:external to checkout /trunk/secretproject and modify the build script to tar up the external checkout and email it to themselves... ok they have left a track of what they did, but now the secret project code is no-longer secret... now consider the case where it was that the developer's computer was stolen or hacked.
You could argue that the correct way to handle that would be to give Jenkins two credentials, the first that is scoped to /trunk/publicproject and the second scoped to /trunk/secretproject... well with the old 1.x way Jenkins would just try all credentials until it found one that works... so still lost there
With 2.x you could do that but now you have to remember to use the correct credentials for the correct paths (ok, so credential domains can help there, but it does get a lot more complex... and there are cases where you cannot)
So given that most people just give Jenkins a credential that has read access everywhere, the only safe way to handle externals is to require configuring the credentials to use when checking out the external.
A valid enhancement request would be to give a checkbox (default to off) to use matching module credentials when doing a checkout of externals. That would at least make things easier for the 80% who don't need the gaping security hole fixed because of their permissive SVN server security model.