SCM credentials: alternates to plain-text storage on disk?

Hi,

It's my understanding that TeamCity stores SCM credentials in cleartext on disk. Is this correct?

I would much prefer to send my credentials (or at least my password) every time I submitted a remote job, so that I could avoid having to store any sensitive data on the TeamCity server. This is particularly important since the TeamCity server presumably ends up storing passwords for all the different participants in a project, so whoever has sufficient access to that machine has access to all those passwords.

To the best of my knowledge, I never entered my svn password into TeamCity's UI. So, that must mean that it picked it up from my IntelliJ settings when I connected from IntelliJ. This, in turn, presumably means that the only reason that TeamCity needs this data is to perform the delayed commit. It would seem that TeamCity could just keep that data in memory for the duration of the test runs, and then throw away the information after the run, instead of actually persisting it to disk.

Thoughts?

-Patrick

6 comments
Comment actions Permalink

Just to clarify, from what I can tell, I don't think that there would even be a usability issue with changing things to not store passwords on the TeamCity server. Since IntelliJ is already storing my password on my client machine (which I'm ok with, since I control the machine), the credentials are always available when jobs are fired off anyways.

Also, I'd prefer a solution other than having TeamCity just encrypt the data on disk. Since TeamCity would need to be able to decrypt the data, that would still leave the data open to attack by a malicious machine operator.

-Patrick

0
Comment actions Permalink

Hello,

TeamCity server stores on disk passwords entered for VCS roots, for
Email/Jabber servers and user passwords if default authentication schema is
configured. We assume that TC server is hosted in secure environment and
access to the PC where TeamCity is installed is limited.

The password you are using for accessing SCM from a local machine is not
transferred to the server because the "commit" part of "delayed commit" is
done on your local PC. All passwords you are entering during login process
(in your browser or in the IntelliJ IDEA plugin) or on our web forms are
transferred by network in encrypted form (we are using asymmetric
encryption) so it is very hard to discover them.

--
Pavel Sher

"Patrick Linskey" <no_reply@jetbrains.com> wrote in message
news:13573992.1175645369210.JavaMail.itn@is.intellij.net...

Just to clarify, from what I can tell, I don't think that there would even
be a usability issue with changing things to not store passwords on the
TeamCity server. Since IntelliJ is already storing my password on my
client machine (which I'm ok with, since I control the machine), the
credentials are always available when jobs are fired off anyways.

>

Also, I'd prefer a solution other than having TeamCity just encrypt the
data on disk. Since TeamCity would need to be able to decrypt the data,
that would still leave the data open to attack by a malicious machine
operator.

>

-Patrick



0
Comment actions Permalink

The password you are using for accessing SCM from a
local machine is not
transferred to the server because the "commit" part
of "delayed commit" is
done on your local PC.


Interesting.... so does that mean that if my computer is offline by the time the tests pass, the commit will fail?

-Patrick

0
Comment actions Permalink

The password you are using for accessing SCM from

a

local machine is not
transferred to the server because the "commit"

part

of "delayed commit" is
done on your local PC.


Interesting.... so does that mean that if my computer
is offline by the time the tests pass, the commit
will fail?


That means commit will start only when your IDE becomes available
after test pass on the server. When IDE got notification that build is OK
and commit can be performed, commit will be executed from your IDE.

Regards,
KIR


-Patrick

0
Comment actions Permalink

That means commit will start only when your IDE
becomes available
after test pass on the server. When IDE got
notification that build is OK
and commit can be performed, commit will be executed
from your IDE.


That makes sense.

Have you guys thought about an option to commit from the server instead of from the client? In the build environment where I work, we have such a system, and I've gotten to like it quite a bit. I do most of my development on a laptop, and I find myself often making changes while offline or just before going offline. In our system at work, I can fire off an ant process that zips up all the changes and sends them to a test machine along with my SCM credentials. If all the tests pass (8 to 10 hours later), then the changes will be send to the SCM, even if my machine is not online.

One obvious problem with this is that my local working copy ends up being out-of-sync, whereas with the TeamCity approach, the commit happens from the working copy, so it's always up-to-date. I'm willing to deal with that problem manually. But, TeamCity could probably cover most cases of this situation, just by updating the status of the files in question the next time that the TeamCity server is in contact with the IDE. With the new shelved-changes capabilities in Selena (great feature, btw) and an automatic local-history label, you could probably even gracefully handle the case where people continued working on the same files after the checkin.

-Patrick

0
Comment actions Permalink

Have you guys thought about an option to commit from
the server instead of from the client? In the build


Please watch/vote for:
http://www.jetbrains.net/jira/browse/TW-1426

I think this task will be of high priority for us for the future release.

Kind regards,
KIR

0

Please sign in to leave a comment.