On Thu, Jan 5, 2012 at 2:42 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Wed, Jan 4, 2012 at 02:58, Paul Burba <ptburba_at_gmail.com> wrote:
>> Mike Pilato and I have been kicking around some ideas on server
>> dictated configuration recently and have put our thoughts into a wiki
>> (full disclosure: this wiki was initially based on Hyrum's thoughts on
>> the subject in https://svn.apache.org/repos/asf/subversion/trunk/notes/repos-dictated-config)
>> :
>>
>> http://wiki.apache.org/subversion/ServerDictatedConfiguration
>>
>> We're at a point where it's time to solicit some wider feedback, so
>> please have a look at the wiki and follow-up here with any concerns,
>> thoughts, suggestions, etc..
>>
> I think most of use-cases can be solved by existing mechanism without
> inventing something new:
> 1. auto-props
> TortoiseSVN already has 'tsvn:auto-props' property [1]. Which used to
> automatically set properties for added files. It would be nice if
> Subversion core support this property.
>
> 2. ignores
> We can add svn:global-ignores property to define global (recursive) ignore mask.
The approach TortoiseSVN and some other clients take does work pretty
nicely but I also think they reveal the short comings in using
properties. For convenience, TortoiseSVN does not force you to set
these properties on every folder and instead will walk to the root of
your WC to find them, but then this also exposes the problem that if
you did not checkout the folder that has those properties you are back
to square one. That is why I believe it makes sense for SVN to
support it natively using an approach something like described in the
wiki. Or at least weigh that approach versus using properties within
the repository. Perhaps properties are the way to add the deferred
feature of supporting overrides based on path?
> 3. store-plaintext-passwords
> Since most used of platforms already supports password encryption
> (Windows, MacOS, KDE, GNOME) I think we can safely just change to do
> not store plaintext by default.
You must not spend time working with Unix users. The options we
provided are good, but do not seem to be enough and there is no way to
enforce policies where they have to be used. It also does nothing to
help things like automated build processes and scripts that need to
run on Unix and cannot interact with a keyring.
I do not pretend to have an answer though. Making plain text off by
default might be a start. I think some people might object to adding
"security theater" by using something like AES encryption to obfuscate
plain text passwords but I think some of our users would appreciate
that option over plain text. It seems like we could possibly add an
option for the user to provide some salt when configuring and building
the binaries as well. I am guessing this could be read from the
strings in the compiled library but it would still provide a small
measure of additional obfuscation that someone would need to know.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-01-05 21:03:35 CET