On 08.06.2013 01:58, Friedrich Brunzema wrote:
> Thinking about it some more, I agree with not putting the code
> collaborator settings with the TSVN settings. [It was still fun to
> do, as it made me remember MFC stuff that I had not seen for 10
> years].
>
> What really needs to be persisted is the two user names and passwords
> (with the passwords encrypted). Thanks to Stefan for upgrading the
> CStringsUtils - its really where that code belongs!
>
> I don't like the idea putting the usernames into SVN properties and
> the passwords in an .ini file, as this separates the info. I would
> much rather like to keep these code collaborator settings all
> together.
>
> So lets go, as Stefan suggested with a standard windows .ini file
> located in the %appdata%\TortoiseSvn that stores the 4 aforementioned
> parameters. This means that its a per-windows user setting. If the
> collabgui.exe file is found in the standard location (x86) and (x64),
> then the Add to Code Collaborator menu item is shown when right
> clicking the revisions in the LogDialog. No app found, no menu item.
> [If it is not in the standard location, they are out of luck] If the
> .ini file does not exist, the user is prompted with a Modal Dialog
> that lets him/her enter the data. The dialog is not shown if the
> .ini file exists, unless the user presses control when invoking the
> menu. That way the user has a way to update the usernames and
> encrypted passwords.
looks good.
But just to clarify: %appdata% is not per-windows but per-user: it's the
roaming profile for each user.
And if you ask for usernames/passwords with a dialog when it's first
needed, then there's no need to have an ini file at all: you can just
store that in the registry as you do now.
> Unfortunately, the unencrypted passwords along with the usernames are
> passed on the command line to collabgui - which is a bad design.
> Using tools like Sysinternals Process explorer lets you see the
> commandline, exposing the passwords. But I agree that it is better
> to do due diligence when storing passwords - ie encrypt them. I will
> point this out to the Code Collaborator authors and ask them for a
> better way to do this.
Just to be clear: it's not really bad. If you have the rights to read
another processes command line then you also have the rights to decrypt
the data from e.g. the registry where you store it encrypted.
If a bad app makes it that far on your system, then it could do much
more and worse.
It's only bad because it's visible in plain text with standard tools.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3057627
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-06-11 16:27:56 CEST