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

credential ID accepts a too narrow set of characters

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • credentials-plugin
    • None

      It seems that there is hardcoded format enforcement for credentials ID which is very limiting for no clear technical reasons. See https://github.com/jenkinsci/credentials-plugin/blob/master/src/main/java/com/cloudbees/plugins/credentials/impl/BaseStandardCredentials.java#L206

      The current regex is [a-zA-Z0-9_.-]+ which prevents people from using logical names like "user@host".

      The current pattern allows only for simple characters which can normally exist in the username, making impossible to use some kind of safe separator when adding IDs.

      This requests for enlarging set of allowable characters and also to document the restriction pattern in the UI, so people would know what they can use.

      Please note that I would not mind raising a PR myself for addressing this but first I need some feedback regarding which are the real limitations regarding the ID. Sadly the source code does not indicate any reasons why this regex was added in the first place. 

          [JENKINS-45254] credential ID accepts a too narrow set of characters

          Sorin Sbarnea added a comment -

          jglick, can we extent the list of allowed characters for IDs with things like "@", ":", maybe even "/" ? These seem to be the more likely to be desired.

          Sorin Sbarnea added a comment - jglick , can we extent the list of allowed characters for IDs with things like "@", ":", maybe even "/" ? These seem to be the more likely to be desired.

          Jesse Glick added a comment -

          stephenconnolly may be able to comment on whether there is any particular reason for the current restrictions. AFAIK credentials IDs are not used as filename components, unlike say Item.name.

          Jesse Glick added a comment - stephenconnolly may be able to comment on whether there is any particular reason for the current restrictions. AFAIK credentials IDs are not used as filename components, unlike say Item.name .

          Stephen Connolly added a comment - https://github.com/jenkinsci/credentials-plugin/blob/master/docs/user.adoc#credentials-ids

          Sorin Sbarnea added a comment -

          stephenconnolly Thanks for illuminating us regarding why this limitation was introduced. Still, I think that it does not make sense to keep such a (very) narrow limitation just with the idea that we may encounter some limitations in the future, with an unnamed system. As well this system may require numeric ID! .... so this approach would not help at all.

          I would not have raise this bug if I could have found at least one character that could be used as a separator between username and hostname on credential names. Ideally this should be the @.

          Sorin Sbarnea added a comment - stephenconnolly Thanks for illuminating us regarding why this limitation was introduced. Still, I think that it does not make sense to keep such a (very) narrow limitation just with the idea that we may encounter some limitations in the future, with an unnamed system. As well this system may require numeric ID! .... so this approach would not help at all. I would not have raise this bug if I could have found at least one character that could be used as a separator between username and hostname on credential names. Ideally this should be the @.

          I am open to expanding the regex, but I would prefer some evidence that an additional character is likely going to work across a good number of enterprise vaults, e.g. : hashicorp, cyberark, etc

          If the enterprise vault uses a numeric ID, well the integration will likely have to match based on a side property metadata in the backing store rather than on numeric ID as migrating from the internal store to the external store would carry too much risk.

          ACK that one could argue the same for the current alpha-num id, but with an alphanum id there is the convenience from the ID used by jenkins matching the ID in the vault, which I think is worthy of the restriction.

           

          Stephen Connolly added a comment - I am open to expanding the regex, but I would prefer some evidence that an additional character is likely going to work across a good number of enterprise vaults, e.g. : hashicorp, cyberark, etc If the enterprise vault uses a numeric ID, well the integration will likely have to match based on a side property metadata in the backing store rather than on numeric ID as migrating from the internal store to the external store would carry too much risk. ACK that one could argue the same for the current alpha-num id, but with an alphanum id there is the convenience from the ID used by jenkins matching the ID in the vault, which I think is worthy of the restriction.  

          Stephen Connolly added a comment - - edited

          If I look at hashicorp vault: https://www.vaultproject.io/docs/commands/read-write.html

          Seems like they are using an url component like name as the identifier, so that may barf if you try to do

          vault write secret/user@host \
              value=itsasecret

          or maybe it won't... also unclear if it would barf over

          vault write secret/user/host \
              value=itsasecret

          In any case, if hashicorp allows for nested names it is more likely that the "path" part of the name would be used to associate a jenkins context store with the hashicorp vault path prefix...

          So I don't think you can use either {{ / }} or {{ \ }} as the separator (plus IIRC cyberark uses {{ \ }} for some special meaning, but it's over a year since I wrote the integration for that)

          Stephen Connolly added a comment - - edited If I look at hashicorp vault: https://www.vaultproject.io/docs/commands/read-write.html Seems like they are using an url component like name as the identifier, so that may barf if you try to do vault write secret/user@host \ value=itsasecret or maybe it won't... also unclear if it would barf over vault write secret/user/host \ value=itsasecret In any case, if hashicorp allows for nested names it is more likely that the "path" part of the name would be used to associate a jenkins context store with the hashicorp vault path prefix... So I don't think you can use either {{ / }} or {{ \ }} as the separator (plus IIRC cyberark uses {{ \ }} for some special meaning, but it's over a year since I wrote the integration for that)

          Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

          Stephen Connolly added a comment - Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

            Unassigned Unassigned
            ssbarnea Sorin Sbarnea
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: