-
Improvement
-
Resolution: Fixed
-
Major
-
Subversion Plugin 2.5.3
The current way of authentification for external references in a project is not clear.
See the extended discussion in JENKINS-22542
We specify Credentials to use for check out. With these credentials you have complete (read-only) access to the project and its externals. (project and externals are in the same repository).
Why do we need to specify these same credentials again just to get the change log?
For security? but the check out is already successful.
Dave (our evil developer) can add an external to SecretProjectC to projectA.
Dave can no longer do a complete checkout locally as he has no access to projectC.
When the build server has access (svn user Jenkins with global read only access)
Now the build server can access SecretProjectC (because another external in projectA requires the additional credentials).
So you rely on having configured exluded svn user Jenkins from secret projects.
In which case the checkout already fails, as this requires additional credentials which Dave (hopefully) cannot configure in the build server.
I suggest to
1: remove the need for additional credentials when all items in a project require the same credentials.
2: Make he selection of credentials a drop down without the need to type the realm (as the realm is already encoded in the credentials.
Edit: second option removed as the 'encoded realm' is only a comment
- is related to
-
JENKINS-22542 Subversion polling not work with externals or variables in URL - E200015: No credential to try.
-
- Resolved
-
2: Make he selection of credentials a drop down...
The comment added (...) is entirely optional and has no meaning besides UI use (...)
During my investigations I found that out too,
I assumed that because the comment is an exact match of the credential domain, the domain was encoded in the credential. However, this is a value which can be modified by the user and is not suitable for looking up credentials for a specific domain.
1: My 'problem' is that in subversion 2.4.x we needed to specify only one set of credential, but now we need to re-specify the same credentials.
in a way which is not clear enough judging by the number of issues being reported
(29237, 29225, 29211, just judging by the descriptions)(Edit, I stand corrected, these are separate issues)The described route to hijacking still exists (and will always exist when there is a single with global read-only access).
I'm wondering what the added security is.
Yes, when 'dave' adds an external to DavesFakeServer he should not receive the company credentials.
But what happens during a check-out? (the actual check out is successful)
...