On 29.08.2014 21:25, DARKGuy . wrote:
> Hello again Brane,
>
> I guess it deneds more on who manages the server in this case. In
> mine, I needed to set up a simple, portable SVN server in my work
> computer, which, by enterprise policies, makes my whole C: drive
> available to my manager and tech support staff, and because I greatly
> dislike this kind of access, if the case of someone random copying the
> files from my computer, they wouldn't get the repository passwords so
> easily at least.
>
> In my solution, the passwords to encrypt the "passwd" file can be
> hardcoded (though I know it isn't a good idea, but it's better than
> plain text passwords...) inside the DLL file and made harder to read
> unless they use a decompiler or other kind of tools, which aren't very
> known to that kind of people in my country, and that makes me feel
> safer.
There is one place in Subversion where we use the Windows CryptoAPI to
store encrypt passwords on disk: in the client's credentials store. We
rely on the CryptoAPI to select the encryption key based on the
credentials of the user who's running the client (i.e., the key is
user-specific, not hard-coded in the code), and we never write the
unencrypted representation to disk.
I think a similar, Windows-specific option in svnserve would be OK.
Implementing something like that does require changes in svnserve, as
well as creating a separate tool to manage a password file with
encrypted entries; and the admin would have to take care to always run
the password manager with the same credentials as svnserve, but it's
trivial to check that at run time to prevent mistakes.
-- Brane
Received on 2014-08-30 12:28:15 CEST