It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787

question asked: Feb 16 '09, 3:16 p.m.
question was seen: 9,751 times
last updated: Feb 16 '09, 3:16 p.m.

Related questions

FAQ - How this Forum works

SCM.EXE, hiding password, where are credentials stored?

0
Ed Koezly (46●5●4) | asked Feb 16 '09, 3:16 p.m.
I'm trying to run SCM commands without having the password displayed on the command line. Related to that I have three questions.

1) Using the SCM.EXE program (from the Windows command line), upon prompting, the password is echoed as I type it. Is there a way to turn off the echo? (on Unix I'd use stty -echoe)

2) Where are credentials stored? Sometimes, but usually not, I see a .jazzcerts file which appears to be encrypted.

3) I run the following SCM login commands. I have two hosts I go to.

scm login -r https://myhost.com:9443/jazz -n hello
scm login -r https://myhost2.com:9443/jazz -n jaz

However, I'm still prompted for a password (actually three times, twice for myhost and once for myhost2) when I run other SCM commands, for example this one.
scm history -d c:\eclipse_proj\workspace HelloWorld/src/HelloWorld.java

Any ideas why I'm still prompted for a password after running the login command?

I thought the login command would store credentials so I would not have to re-login. It's as if the creditials were not stored.

Curiously, if I run the scm login command on my C: drive, I get a Java exception stack trace before the "Logged in to https://myhost:9443/jazz" message, but from a network drive, there is no exception stack trace, just the "Logged in..." message implying all is well.

These are the SCM versions.
com.ibm.team.filesystem.cli.tools, version 0.6.0.I200805202108
com.ibm.team.filesystem.cli.client, version 0.6.0.I200810082036
com.ibm.team.filesystem.cli.core, version 0.6.0.I200810082036

Thanks for any suggestions.

9 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Evan Hughes (2.4k●13●18) | answered Feb 17 '09, 5:23 p.m.
JAZZ DEVELOPER
1) Using the SCM.EXE program (from the Windows command line), upon prompting, the password is echoed as I type it. Is there a way to turn off the echo? (on Unix I'd use stty -echoe)


There's no way to turn off the echo. We're running with an old JRE, which prevents us from turning off the echo.

2) Where are credentials stored? Sometimes, but usually not, I see a .jazzcerts file which appears to be encrypted.


~/.jazz-scm/repositories - In a multiuser environment that should only be readable/writable by you.

3) I run the following SCM login commands. I have two hosts I go to.

scm login -r https://myhost.com:9443/jazz -n hello
scm login -r https://myhost2.com:9443/jazz -n jaz

However, I'm still prompted for a password (actually three times, twice for myhost and once for myhost2) when I run other SCM commands,


The password won't be saved unless you specify it on the command line.

As to being prompted multiple times: that's unexpected. If it's reproducible, could you submit a bug?

Curiously, if I run the scm login command on my C: drive, I get a Java exception stack trace before the "Logged in to https://myhost:9443/jazz" message, but from a network drive, there is no exception stack trace, just the "Logged in..." message implying all is well.


That's also unexpected. Could you post a copy of the stack trace?

e
0
permanent link
Ed Koezly (46●5●4) | answered Feb 17 '09, 8:04 p.m.
Thank you.

Entering the ID and password on the command line does get the credentials stored. Just as you said, I see them in .jazz-scm/repositories.

Just a comment: Unfortunately, the passwords are cleartext, and yes, other than administrators, I'm the only one with access to the file, it's still a risk. We'll be using LDAP and I'm uncomfortable with my network password in cleartext. I realize given open source, access to the file system, and long-term storage of keys, it seems nigh impossible to defend. We'd have to change at least one of those factors (maybe a C program wrapped around scm.exe to hide the password).
As to being prompted multiple times: that's unexpected. If it's reproducible, could you submit a bug?

I'll see if it happens to other people here. I'll also experiment at home with the Visual Studio beta since I seem to be the only one.
That's also unexpected. Could you post a copy of the stack trace?

Regarding the exception trace from SCM LOGIN when run from the C: drive but not a network drive, here's an example.
scm login -r https://myHost:9443/jazz -n jazz -u myId -P myPassword
---------- begin trace 1 ----------------
java.io.FileNotFoundException: C:\dl\cmd_line\configuration\1234913349491.log (Access is denied.)
at java.io.FileInputStream.<init>(FileInputStream.java:135)
at org.eclipse.osgi.framework.util.SecureAction.getFileInputStream(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseLog.setOutput(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseLog.setFile(Unknown Source)
at org.eclipse.core.internal.runtime.DataArea.createLocation(Unknown Source)
at org.eclipse.core.internal.runtime.DataArea.initializeLocation(Unknown Source)
at org.eclipse.core.internal.runtime.DataArea.assertLocationInitialized(Unknown Source)
at org.eclipse.core.internal.runtime.DataArea.getStateLocation(Unknown Source)
at org.eclipse.core.internal.runtime.InternalPlatform.getStateLocation(Unknown Source)
at org.eclipse.core.runtime.Plugin.getStateLocation(Unknown Source)
at org.eclipse.core.internal.resources.LocalMetaArea.<init>(LocalMetaArea.java:52)
at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:355)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(AccessController.java:246)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Unknown Source)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source)
at org.eclipse.osgi.framework.util.SecureAction.start(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(ClassLoader.java:597)
at org.eclipse.emf.ecore.plugin.EcorePlugin$Implementation.start(EcorePlugin.java:505)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(AccessController.java:246)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Unknown Source)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source)
at org.eclipse.osgi.framework.util.SecureAction.start(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(ClassLoader.java:597)
at com.ibm.team.repository.common.UUID.generate(Unknown Source)
at com.ibm.team.repository.transport.client.CertificateStore.computeAlias(CertificateStore.java:110)
at com.ibm.team.repository.transport.client.CertificateStore.enterCertificate(CertificateStore.java:166)
at com.ibm.team.repository.transport.client.CertificateStore.enterCertificates(CertificateStore.java:183)
at com.ibm.team.repository.transport.client.CertificateStore.loadCertificates(CertificateStore.java:215)
at com.ibm.team.repository.transport.client.ValidatingX509TrustManager.buildRuntimeTrustStore(ValidatingX509TrustManager.java:129)
at com.ibm.team.repository.transport.client.ValidatingX509TrustManager.<init>(ValidatingX509TrustManager.java:197)
at com.ibm.team.repository.transport.client.SecureInterruptableSocketFactory.<init>(SecureInterruptableSocketFactory.java:65)
at com.ibm.team.repository.transport.client.RemoteTeamServer.ensureInitialized(RemoteTeamServer.java:146)
at com.ibm.team.repository.transport.client.RemoteTeamServer.setCredentials(RemoteTeamServer.java:171)
at com.ibm.team.repository.client.internal.TeamRepository.<init>(TeamRepository.java:336)
at com.ibm.team.repository.client.internal.TeamRepositoryService.createSharedTeamRepository(TeamRepositoryService.java:366)
at com.ibm.team.repository.client.internal.TeamRepositoryService.getTeamRepository(TeamRepositoryService.java:91)
at com.ibm.team.repository.client.internal.TeamRepositoryService.getTeamRepository(TeamRepositoryService.java:110)
at com.ibm.team.filesystem.cli.core.util.RepoUtil.login(Unknown Source)
at com.ibm.team.filesystem.cli.client.internal.subcommands.LoginCmd.run(LoginCmd.java:108)
at com.ibm.team.filesystem.cli.core.internal.Application.run(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.Application.doStart(Unknown Source)
at com.ibm.team.filesystem.cli.core.internal.Application.start(Unknown Source)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown Source)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source)
at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source)
at org.eclipse.equinox.launcher.Main.run(Unknown Source)
Logged in to https://myhost:9443/jazz
---------- end trace 1 ----------------

Here's the log file referenced in trace 1. Why it was created with 000 permission (Windows XP), I don't know.
----------- begin log file 1, 1234913349491.log ---------------
!SESSION 2009-02-17 17:29:08.585 -----------------------------------------------
eclipse.buildId=unknown
java.fullversion=J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20080315 (JIT enabled)
J9VM - 20080314_17962_lHdSMr
JIT - 20080130_0718ifx2_r8
GC - 200802_08
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: login -r https://myhost:9443/jazz -n jazz -u myId -P myPassword
Command-line arguments: -os win32 -ws win32 -arch x86 -data @noDefault login -r https://myhost:9443/jazz -n jazz -u myId -P myPassword

!ENTRY org.eclipse.osgi 4 0 2009-02-17 17:29:10.209
!MESSAGE Error reading configuration: C:\dl\cmd_line\configuration\org.eclipse.osgi\.manager\.tmp438.instance (Access is denied.)
!STACK 0
java.io.FileNotFoundException: C:\dl\cmd_line\configuration\org.eclipse.osgi\.manager\.tmp438.instance (Access is denied.)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:243)
at org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio.lock(Unknown Source)
at org.eclipse.osgi.storagemanager.StorageManager.initializeInstanceFile(Unknown Source)
at org.eclipse.osgi.storagemanager.StorageManager.open(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.BaseStorage.initFileManager(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.BaseStorage.initialize(Unknown Source)
at org.eclipse.osgi.baseadaptor.BaseAdaptor.initializeStorage(Unknown Source)
at org.eclipse.osgi.framework.internal.core.Framework.initialize(Unknown Source)
at org.eclipse.osgi.framework.internal.core.Framework.<init>(Unknown Source)
at org.eclipse.osgi.framework.internal.core.OSGi.createFramework(Unknown Source)
at org.eclipse.osgi.framework.internal.core.OSGi.<init>(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(Unknown Source)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source)
at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source)
at org.eclipse.equinox.launcher.Main.run(Unknown Source)
----------- end log file 1, 1234913349491.log ---------------
0
permanent link
Dominic Evans (66●5●3) | answered Feb 20 '09, 10:48 a.m.
There's no way to turn off the echo. We're running with an old JRE, which prevents us from turning off the echo


http://java.sun.com/developer/technicalArticles/Security/pwordmask/

...
0
permanent link
Evan Hughes (2.4k●13●18) | answered Feb 20 '09, 2:09 p.m.
JAZZ DEVELOPER
http://java.sun.com/developer/technicalArticles/Security/pwordmask/


That won't work in environments where the backspace character isn't respected and will expose characters under when the machine is suffering high load.

e
0
permanent link
Dominic Evans (66●5●3) | answered Feb 20 '09, 5:39 p.m.
given the choice between doing nothing vs covering 80-90% of users with an inefficient but workable alternative for the short term, I know which I'd choose though :)
0
permanent link
Dominic Evans (66●5●3) | answered Feb 23 '09, 9:02 a.m.
I guess one of the (many) benefits of open source is that I can just grab the client source from here and fix it myself :)
0
permanent link
Ed Koezly (46●5●4) | answered Feb 24 '09, 6:07 p.m.
I guess one of the (many) benefits of open source is that I can just grab the client source from here and fix it myself :)


Thanks for the replies.

My workaround, on Windows, is a VBS script that pops up an IE message box (that some clever person on the web figured out) and then calls SCM. I won't use the SCM LOGIN command in order to avoid storing the cleartext password.

By the way, I don't see the SCM command source in the 33,000 files in the RTC client source. Although I have to follow a lengthy bureaucratic process to modify third-party code, I was tempted to change it to read obfuscated passwords in the repositories file and then write a another program to populate repositories.
0
permanent link
Dominic Evans (66●5●3) | answered Feb 25 '09, 4:09 a.m.
the commandline interface is very weird java, in that it is technically an eclipse-backed set of rich client interface plugins! slightly heavyweight :)

imo, have a peek at the files here and you might find what you're looking for 


unzip -l TeamConcert-Source-1.0.1.zip | grep com.ibm.team.filesystem.feature.cli | grep src.zip

    91099  10-24-08 14:28   source/rtc/eclipse/plugins/com.ibm.team.filesystem.feature.client.source_0.7.0.I200810071938-07J-7zA55S855SA5DM/src/com.ibm.team.filesystem.client.daemon_0.7.0.I200810082036/src.zip

   612000  10-24-08 14:28   source/rtc/eclipse/plugins/com.ibm.team.filesystem.feature.client.source_0.7.0.I200810071938-07J-7zA55S855SA5DM/src/com.ibm.team.filesystem.client_0.7.0.I200810082036/src.zip

   637320  10-24-08 14:28   source/rtc/eclipse/plugins/com.ibm.team.filesystem.feature.client.source_0.7.0.I200810071938-07J-7zA55S855SA5DM/src/com.ibm.team.filesystem.common_0.7.0.I200810082036/src.zip
0
permanent link
Ed Koezly (46●5●4) | answered Mar 19 '09, 9:51 a.m.
Thanks for the pointers on finding command line code.

With RTC version 1.0.1.1, exception traces are not showing and it no longer prompts for the password multiple times. This is good.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.