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

Externals With(out) additional credentials is not clear

    XMLWordPrintable

Details

    • Improvement
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Fixed
    • subversion-plugin
    • Subversion Plugin 2.5.3

    Description

      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

      Attachments

        Issue Links

          Activity

            estyrke As far as I understand it this is exactly what the credentials system is for.
            Server A asking for authentication is different credentials then server B.
            I'm not deep enough into the details to know if it is possible to fake the server id on which the credentials are chosen .

            So when someone adds an external to EvilServer with the intention to intercept your password you get the failure 'no credential to try' without the credentials for server A and B being tried.

            When you DO need a repository over multiple servers, this is where the additional credentials option is intended for.

            renea Rene Affourtit added a comment - estyrke As far as I understand it this is exactly what the credentials system is for. Server A asking for authentication is different credentials then server B. I'm not deep enough into the details to know if it is possible to fake the server id on which the credentials are chosen . So when someone adds an external to EvilServer with the intention to intercept your password you get the failure 'no credential to try' without the credentials for server A and B being tried. When you DO need a repository over multiple servers, this is where the additional credentials option is intended for.
            tkrah Torsten Krah added a comment -

            Confusing stuff here mixed. Imho if the external is pointing to the same configured server from which the checkout did start (and where the external are already followed and checked out) the changelog generation should not fail because i did not specify the same credentials in the additional section, do we have a consensus about this particular scenario - it may be differently judged in other scenarios?

            tkrah Torsten Krah added a comment - Confusing stuff here mixed. Imho if the external is pointing to the same configured server from which the checkout did start (and where the external are already followed and checked out) the changelog generation should not fail because i did not specify the same credentials in the additional section, do we have a consensus about this particular scenario - it may be differently judged in other scenarios?

            Hi,
            Any update on this ? tkrah based on the scenario you describe, could we imagine to get a fix ? thanks a lot for your contribution on this topic (which started months ago !).

            splashnenen Alexandre Aubert added a comment - Hi, Any update on this ? tkrah based on the scenario you describe, could we imagine to get a fix ? thanks a lot for your contribution on this topic (which started months ago !).
            tkrah Torsten Krah added a comment -

            splashnenen - i wonder this myself. At least until now no one from the jenkins people involved with that has get to this and did leave some comment or proposal about it, too bad - seems to be not much interest in getting this fixed. I did not yet have a look on the code base if it would be easy or not to provide a patch - but without getting this sorted out if and how it should be fixed i won't even consider starting it.

            tkrah Torsten Krah added a comment - splashnenen - i wonder this myself. At least until now no one from the jenkins people involved with that has get to this and did leave some comment or proposal about it, too bad - seems to be not much interest in getting this fixed. I did not yet have a look on the code base if it would be easy or not to provide a patch - but without getting this sorted out if and how it should be fixed i won't even consider starting it.
            thebro Kevin Broselge added a comment - - edited

            I just merged a PR which is likely to solve this issue.

            Should be solved with versionĀ 2.15.0

            thebro Kevin Broselge added a comment - - edited I just merged a PR which is likely to solve this issue. Should be solved with versionĀ  2.15.0

            People

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

              Dates

                Created:
                Updated:
                Resolved: