It's all about the answers!

Ask a question

RTC command line interface - password encryption

M Kevin McHugh (1557) | asked Jun 11 '13, 10:56 a.m.
   The documentation I've found so far is unclear and the forum searches provide answers that, while correct, are far too specific to provide a clear example of how password encryption works.  So, the question is this....

   How do I ... provide a userid/password one (1) time, ever, have it stored encrypted, and use it later for any script.

   To flip it around, I NEVER want to put a userid/password pair in clear text in ANY script.

   I am willing to create a cache, once (ever), ... but then want to always reference the cache from a script no matter how many times the script is run.

   The documentation and forum answers seem to hint that the first time a script is run, it must provide authentication in clear text and then subsequent commands can use the cache.

4 answers

permanent link
Sridevi Sangaiah (59179) | answered Jun 12 '13, 1:06 a.m.
Hi Kevin,

Run "scm login" from a command prompt. "scm login" stores the credentials along with the repository url and repository id in a file named repositories.txt file which can be found under $HOME/.jazz-scm. These credentials (password is encrypted) will be maintained in the repositories.txt file until 'scm logout' command is run. So it would be available across different runs of your build script and hence you need not have to specify the credentials in your script. If your build script doesn't configure the CLI's configuration directory location (by setting the SCM_CONFIG_DIRECTORY environment variable or by specifying the --config command line option) then you can stop here else follow further. If your build script specifies the config directory location then copy the repositories.txt file found under $HOME/.jazz-scm to the config directory location specified in the build script.

Hope this helps!


Rachel Biderman commented Dec 20 '13, 2:46 p.m.

The need is to have an offline PWD file ready (like we create using JBE build engine) and use this file to login to scm as well  , otherwise it means during scm login command we must always type the password when executing a scm command the first time.

Is there a WorkItem enhancement for this or shall i submit one?

Shashikant Padur commented Feb 23 '14, 11:13 p.m.

permanent link
Josh Crawford (984615) | answered Jun 11 '13, 11:51 a.m.
 Hi Kevin,  I believe the closest thing available at this time is explained in the following post which describes where the -c option on scm login stores the cached pwd.

At this time there isn't a way that I am aware of to store the login information to a file like the JBE does for continual re-use.  

permanent link
David Lafreniere (4.8k7) | answered Oct 10 '18, 10:25 a.m.
-You would use 'scm login --generatePasswordFile <path_to_file>' to first generate the password file.
-Then once generated, this file can be re-used at any time using 'scm login --password-file <path_to_file>'.

Note: This password file is encrypted, and thus we do not allow users to create it by 'hand' (which would defeat the purpose of encoding it in the first place).

permanent link
Ana Lopez-Mancisidor (25648966) | answered Jun 20 '14, 4:22 a.m.
did you find any way to solve this issue until the Enhancement Request is implemented?

The -c option does not prevent the user to enter at least the password manually at the first login (which makes script automation useless) because it does no automatically takes the value from the repositories.txt file.

The other option of having a clear password with -P password means having to write a clear password and it goes against security policies.

Did you find any way to reference the repositories.txt file as the place to read the password from with the -P option of the lscm login command?


Rachel Biderman commented Jun 22 '14, 1:15 a.m.

We solved it by having a local file with the PWD - you can have it encrypted as well if you want.

We wrote a utility which handles the scm commands, so this utility first reads the PWD file and performs the login according to it.
The main thing we earn by this is if the user's PWD has changed, we dont need to re-compile our utility, since it is dynamic.
Not perfect, but better than changing it all the time. 

Your answer

Register or to post your answer.