Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-29079

Externals With(out) additional credentials is not clear

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • subversion-plugin
    • 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

          [JENKINS-29079] Externals With(out) additional credentials is not clear

          Rene Affourtit created issue -
          Rene Affourtit made changes -
          Description Original: The current way of authentification for external references in a project is not clear.
          See the extended discussion in [JENKINS-22542|https://issues.jenkins-ci.org/browse/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.
          New: The current way of authentification for external references in a project is not clear.
          See the extended discussion in [JENKINS-22542|https://issues.jenkins-ci.org/browse/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
          Manuel Recena Soto made changes -
          Assignee New: Manuel Recena Soto [ recena ]
          Manuel Recena Soto made changes -
          Environment Original: subversion plugin 2.5 New: Subversion Plugin 2.5.3
          Manuel Recena Soto made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]
          Manuel Recena Soto made changes -
          Labels New: UX
          Torsten Krah made changes -
          Link New: This issue is related to JENKINS-22542 [ JENKINS-22542 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 163947 ] New: JNJira + In-Review [ 181442 ]
          Kevin Broselge made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Kevin Broselge made changes -
          Assignee Original: Manuel Recena Soto [ recena ] New: Kevin Broselge [ thebro ]
          Kevin Broselge made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]

            thebro Kevin Broselge
            renea Rene Affourtit
            Votes:
            19 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated:
              Resolved: