We're continuing to integrate CCNet into our process. Like others, I sometimes see an error when all the projects try to go at vault at once. In our case we don't really want this behavior in the first place since there are project dependencies, so I'm not sweating the vault side of that.
But on to the real topic. I don't like having source control passwords in CC build files. I especially don't like it because it puts the Vault command line in its build log. The problem is we use multiple repositories here. REMEMBERLOGIN at the moment FORCES a repository choice, and then ignores any command line repository argument passed. I propose fixing this by either:
1) Allowing the CLI to use REMEMBERLOGIN w/o a repository
2) Having the CLI accept (i.e. override) the REMEMBERLOGIN settings with the command line arguments.
I can make one of these changes to the command line cs and post them here if that's useful, or if you guys think this is a worthwhile change and want to do it, even better.
Or maybe this functionality is already there and I don't see it.
Thanks,
--Max
Vault CLI change
Moderator: SourceGear
We've had other discussions of this issue and have a feature request logged to encrypt the password in the CLI. One forum user suggested creating a batch file that takes a single argument, the new password, and that has a call to the CLC with rest of the information already filled in.I don't like having source control passwords in CC build files.
Certainly, if you want to make modifications to the CLC, do so. That's why we make the code available.REMEMBERLOGIN at the moment FORCES a repository choice, and then ignores any command line repository argument passed . . .
I can make one of these changes to the command line cs and post them here if that's useful.
We may or may not incorporate this type of change, but in either case, your modification might be helpful to other users.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
This issue about multiple repositories and rememberlogin has come up in the past. Please see the thread
http://support.sourcegear.com/viewtopic.php?t=920
However, the suggested change didn't make it to the 3.1.1 release. It would be good if it gets incorporated as it is a nuisance to make modifications and deliver the customized gvault.exe everytime there is an upgrade..
http://support.sourcegear.com/viewtopic.php?t=920
However, the suggested change didn't make it to the 3.1.1 release. It would be good if it gets incorporated as it is a nuisance to make modifications and deliver the customized gvault.exe everytime there is an upgrade..
Easy and not so easy
So fixing the "overridable" settings problem is quite easy. After the call to RetrieveSession, I just added the following clumsy but workable lines:
// Override from cmd line
strURL = _args.Url != null ? _args.Url : strURL;
strUser = _args.User != null ? _args.User : strUser;
strPassword = _args.Password != null ? _args.Password : strPassword;
strRepository = _args.Repository != null ? _args.Repository : strRepository;
While I was in there, I also decided to encrypt the information in the session file using the Data Protection API from Windows. In theory, if it runs on Mono it should still work just fine, though I didn't try it. VaultCmdLineClient.cs and DataProtection.cs attached.
// Override from cmd line
strURL = _args.Url != null ? _args.Url : strURL;
strUser = _args.User != null ? _args.User : strUser;
strPassword = _args.Password != null ? _args.Password : strPassword;
strRepository = _args.Repository != null ? _args.Repository : strRepository;
While I was in there, I also decided to encrypt the information in the session file using the Data Protection API from Windows. In theory, if it runs on Mono it should still work just fine, though I didn't try it. VaultCmdLineClient.cs and DataProtection.cs attached.
- Attachments
-
- VaultCmdLineClient.txt
- updated to use DPAPI and allow command line override
- (133.49 KiB) Downloaded 834 times
-
- DataProtection.txt
- (10.34 KiB) Downloaded 629 times