[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN Security

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-07-16 15:38:02 CEST

On Jul 16, 2005, at 7:34 AM, Ben Collins-Sussman wrote:
>
> Translation: "SVN has all the features I want, but they're not
> implemented in a way that's convenient for my corporate bias. I
> guess the features don't exist, then."
>

Calvin: I apologize for my overly hostile, overly rude response. I
shouldn't have been so hot-headed when I wrote that.

The problem is: I think your posts have been quite provocative and
bordering on "trolling".

Your first mail begins by asking a question that could have been
answered by merely skimming the documentation. Instead of reading
the docs, you boldly claim that subversion is "missing a critical
feature." Actually, no, you simply decided to jump to a wrong
conclusion without reading documentation.

Then, you use bad terminology to describe the feature you're looking
for. Rather than ask, "can subversion can control permissions on
individual files?", you accuse subversion of having no "security".
It may have just been a simple language misunderstanding... but to a
native english speaker, saying that software "lacks security" sounds
like you're accusing the product of being "insecure", which is a
pretty large insult. Again, this was probably just a translation
problem.

But then you go on to saying that you don't want to "pollute your
environment" with apache. This again sounds like a troll... is
something wrong with apache? 70% of all websites run apache, and yet
it "pollutes" your system? If I renamed apache to "super-deluxe-
subversion-server 7.8", would you use it then? Many people run
apache *just* as a dedicated subversion server -- running alongside
existing webservers -- but listening on a different port number.
Both the book and FAQ talk about this. Next time, just come right
out and ask: "can I run apache alongside IIS?"

Later on, you complain that SVN "forces" you to learn apache, that
the per-directory permissions are "just too difficult to understand",
and that our implementation of the feature isn't "decent". This is
not constructive criticism, it just sounds like laziness. Per-
directory permissions is an inherently complex feature, and you're
going to have to learn how to set them up, whether you're using
apache or svnserve as your server. But somehow you assume that
apache is "hard", and that when we eventually teach svnserve to do
per-directory permissions, it will be "easy". Guess what: we're
working on that adding that feature to svnserve feature right now,
and it's sharing code with apache. The exact same file that defines
ACLs for apache is going to be used by svnserve as well. It's not
going to be any "easier" to understand. If you have a specific
suggestion to make the syntax more friendly, we'd like to hear about it.

Finally, in your last mail, you make the classic troll statement:
"if your software had feature X, it would a killer app." It sounds
like blackmail, like you're threatening to not use the software
unless we quickly change it to your liking. There's a strange sort
of hubris in that phrasing. I think you're trying to say, "adding
path-based permissions to svnserve would be good thing" (which
everyone already agrees with!), but instead it comes off like a
haughty demand, rather than a helpful suggestion.

In any case, I hope Subversion works out well for you. Many people
use it every day, and have no problems configuring path-based
permissions. If you read the book and have specific, constructive
criticisms, or simply need help understanding things, please feel
free to ask this list.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 16 15:39:35 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.