0

I am attempting to automate committing some files to SVN during our automated build process. Hudson does not have a tool (that works) to do this simply. I found Plugin to commit hudson build artifact which shows a second example using a simple command. The difficulty is now on obfuscating the credentials supplied.

I didn't really like the idea of building my batch into an exe -- it seemed a bit too bulky and not able to change. I was racking my brain for other ideas and coworker and I came up with this:

  • Create a new user in SVN with no privileges. I've called this user 'hudson'
  • Give hudson only the ability to read/commit to the one project in question. It cannot delete.
  • Use username/password unobfuscated. :x

Now, accessing our Hudson build server requires authentication. So, there is at least one level of implied authentication before being able to hit the unobfuscated password. If a malicious user had the ability to see this unobfuscated password then it is implicit that they have more privileges than having the unobfuscated password would grant them. Does that make sense? Is this sound? I feel really dirty for doing this, but I can't think of a simpler way to do it.

Community
  • 1
  • 1
Sean Anderson
  • 27,963
  • 30
  • 126
  • 237

1 Answers1

1

In the broadest terms, this is not a problem. However, there are several things you can do to improve it.

  • The password in question should be long and random. It's only used by a program; why should it be easy to read?
  • I generally apply small obfuscations to such password, particularly if they are not long and random for some reason (such as them being also used by humans). The reason is to prevent someone looking over my shoulder from suddenly knowing the password. Mild screening is useful anytime you're going to put a password in a script.
Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Thank you for a clear, understandable response! – Sean Anderson Apr 06 '12 at 16:04
  • Not necessarily. If you need to able to audit who commits, you lose this with commits by the "hudson" user. – Jeanne Boyarsky Apr 08 '12 at 01:30
  • The "who" in this case was "the automated build," so "hudson" would be the correct user. I'm not clear what's lost there. I would agree if hudson were committing on others' behalf, but not if it commits as part of the build process. – Rob Napier Apr 08 '12 at 01:36
  • It's supposed to commit as the automated build. With a plaintext password, a human could see it and then do commits as if it were the hudson user. – Jeanne Boyarsky Apr 09 '12 at 00:42
  • Agreed, which is the rationale for my recommendations of a long, random password with light obfuscation to prevent shoulder surfing. – Rob Napier Apr 09 '12 at 13:51