Continuum
  1. Continuum
  2. CONTINUUM-1200

Password Characters Not Supported in SCM Checkout

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1-alpha-1
    • Fix Version/s: 1.2
    • Component/s: SCM
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      Certain characters are not supported for the password for an SCM checkout. For instance if a ')' is the first character, then the command fails. This is because the password is provided as a CLI parameter, and is not surrounded by quotes. Obviously, adding quotes might break other passwords, so it would be best to pass the password along some other way.

        Issue Links

          Activity

          Hide
          Dan Tran added a comment -

          did you try to configure your scm url using | separator ?

          http://maven.apache.org/scm/scm-url-format.html

          Show
          Dan Tran added a comment - did you try to configure your scm url using | separator ? http://maven.apache.org/scm/scm-url-format.html
          Hide
          Stephen Duncan Jr added a comment -

          In the scenario being used, no password info is in the scm url. The password was provided when authenticating to download the POM from subversion.

          Show
          Stephen Duncan Jr added a comment - In the scenario being used, no password info is in the scm url. The password was provided when authenticating to download the POM from subversion.
          Hide
          Brent N Atkinson added a comment - - edited

          This is also true when specifying SCM username/pass in the release plugin functionality. The general problem is that commands are run using a command shell. Username and password are concatenated into these commands without protecting the command interpreter from special characters, if present. This is a security vulnerability as well. Because my password is inserted directly into a shell command, I can use a specially crafted username or password to do some really nasty things.

          Unfortunately, because continuum uses the shell, any solution will raise portability concerns. For instance, if we assume bash we can use the special $'' quoting feature:

          svn --username $'it\'s cool' --password $'but don\'t try this in tcsh or in window\'s'

          However, this is not portable across all target platforms.

          Perhaps it would be possible to detect the shell that the continuum is running in by executing carefully crafted commands on startup. Once the shell is detected, the proper procedure could be chosen for escaping. For instance, if there is support for bash's quoting style, use it in combination with escaping single quotes in passwords with a backslash. If using windows, use an appropriate scheme, tcsh another, etc.

          Another alternative is to allow continuum administrators to configure the shell as part of setup. Yet another would be don't bake in the commands at all, allow the administrators to edit configuration files with the commands.

          At the very least, I think securing it is a wise choice. The easiest short term fix would probably be to use double quotes and escape double quotes present in the values with a backslash. This would clear up the security issue, and would support most special characters which would be significantly better than the current solution. The only big problem would be parameter expansion in values that contained $ (or double-% on windows). You could approach this with one of the techniques above, or you could simply detect problem values and give the user feedback that their password is not supported.

          Show
          Brent N Atkinson added a comment - - edited This is also true when specifying SCM username/pass in the release plugin functionality. The general problem is that commands are run using a command shell. Username and password are concatenated into these commands without protecting the command interpreter from special characters, if present. This is a security vulnerability as well. Because my password is inserted directly into a shell command, I can use a specially crafted username or password to do some really nasty things. Unfortunately, because continuum uses the shell, any solution will raise portability concerns. For instance, if we assume bash we can use the special $'' quoting feature: svn --username $'it\'s cool' --password $'but don\'t try this in tcsh or in window\'s' However, this is not portable across all target platforms. Perhaps it would be possible to detect the shell that the continuum is running in by executing carefully crafted commands on startup. Once the shell is detected, the proper procedure could be chosen for escaping. For instance, if there is support for bash's quoting style, use it in combination with escaping single quotes in passwords with a backslash. If using windows, use an appropriate scheme, tcsh another, etc. Another alternative is to allow continuum administrators to configure the shell as part of setup. Yet another would be don't bake in the commands at all, allow the administrators to edit configuration files with the commands. At the very least, I think securing it is a wise choice. The easiest short term fix would probably be to use double quotes and escape double quotes present in the values with a backslash. This would clear up the security issue, and would support most special characters which would be significantly better than the current solution. The only big problem would be parameter expansion in values that contained $ (or double-% on windows). You could approach this with one of the techniques above, or you could simply detect problem values and give the user feedback that their password is not supported.
          Hide
          Olivier Lamy added a comment -

          duplicates CONTINUUM-1360.
          Can you try with trunk and reopen it if it's not fixed ?

          Show
          Olivier Lamy added a comment - duplicates CONTINUUM-1360 . Can you try with trunk and reopen it if it's not fixed ?
          Hide
          Brent N Atkinson added a comment -

          This seems to remedy the case issued on the ticket (leading paren), and it works for my case as well (contains single quote). Closed it is.

          Show
          Brent N Atkinson added a comment - This seems to remedy the case issued on the ticket (leading paren), and it works for my case as well (contains single quote). Closed it is.

            People

            • Assignee:
              Olivier Lamy
              Reporter:
              Stephen Duncan Jr
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: