You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Perry E. Metzger" <pe...@wasabisystems.com> on 2002/04/15 21:02:30 UTC
ssh based access?
I've been lurking for quite some time, following subversion
development with interest. One issue that is big for the folks over in
NetBSD (my open source project poison of choice) is secure access to
the source repository. Currently, we do all our access to our CVS
repository via ssh, and people are very happy with ssh as a transport
mechanism. There is probably a lot of resistance to opening up other
holes on the main source repository.
I realize that extracting Apache and such from the process would be
very hard, but would it be difficult to make the standard tools able
to operate through port forwarded ssh connections the way that CVS
happily operates via CVS_RSH=ssh based connections?
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Philip Martin <ph...@codematters.co.uk>.
William Uther <wi...@cs.cmu.edu> writes:
> > As it stands ra_dav likes to open two sessions. This might be a lose
> > once you start talking about two SSHs and two mod_dav_svn harnesses.
> > I'm not sure what it uses those two sessions for, but it might need
> > to be turned off.
>
> Knowing what these two sessions are for would be useful.
Taking 'svn diff -rN:M' as an example, the client sends a request for
the differences between the two revsions. This uses one of the
sessions which remains open for the whole transaction. As the response
is processed, the client then needs to retrieve the full text for one
of the revisions so that it has something to which it can apply the
difference. Retrieving the fulltext takes place over the second
session while processing the diff response from the first
session. It's all part of making the client stream-like: svn doesn't
need to cache the entire diff, which could be huge, it simply
processes each file as it receives it.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by William Uther <wi...@cs.cmu.edu>.
On 18/4/02 12:31 PM, "Mark Benedetto King" <bk...@answerfriend.com> wrote:
>> I believe Apache can be run using inetd (although it is deprecated?). See
>> <http://httpd.apache.org/docs/mod/core.html#servertype>. This will be our
>> version of the cvs server.
>
> The "please don't make me install apache-2.0 in order to use svn" request
> seems reasonable enough to me. If that's the case, apache is right out,
> run as-if-from-inetd or not. But does that mean *any* harness for mod_dav_svn
> would be unacceptable? I'm not sure. It might not be *too* hard to slap
> together a minimal harness for mod_dav_svn, for those that refuse to install
> apache.
I had the same thoughts. I started looking at apache as that harness not
because it was a great idea, but because it was already there. It would
allow you to get something up and running quickly. It would be great to
write a more minimal harness for mod_dav_svn - but it should be done last,
not first.
[snip implementation details]
>> you use the supplied rsh-cmd and auth info to start up apache on the remote
>> host in the same way inetd used to. This gives you a connection to apache
>> over ssh. You make a new ne_session from your socket and the path in the
>> URI.
>
> As it stands ra_dav likes to open two sessions. This might be a lose
> once you start talking about two SSHs and two mod_dav_svn harnesses.
> I'm not sure what it uses those two sessions for, but it might need
> to be turned off.
Knowing what these two sessions are for would be useful. Can ra_dav be
modified to use a single session? Again, this is a nice improvement, but
technically optional. It could be left till other stuff is finished.
>> You now have a secure http connection to the remote machine. ssh is the
>> only aperture - this is not the same as running your own instance of apache
>> on an unprivileged port. You do what ra_dav currently does over the http
>> connection using the ne_session.
>
> Yes, but you are still running apache, and you've gone and modified ra_dav
> and/or neon.
Well, you're running apache for the proof of concept. Once it is running
with apache, another harness could be written for mod_dav_svn. Yes, this
would require a modification to neon. It wouldn't require a huge mod to
neon - just a new, more flexible, API for creating a session.
I don't think you need huge mods to ra_dav. You'd just create ra_pipe that
shared code with ra_dav. Shared code is good - less work to do, fewer
hiding places for bugs.
> I'm not sure that feature is so much deprecated as discouraged because of
> apache's startup overhead. I could easily be wrong about that, though.
It used to be discouraged, but the docs now say: (in red) "Inetd mode is no
longer recommended and does not always work properly. Avoid it if at all
possible."
The "does not always work properly" worries me a little.
> Because of the "Hippocratic Principle" mentioned in HACKING, I had
> planned on going ahead and implementing a new wire protocol. They're
> really not that hard, and this one is simple. Or would be simple, if
> not for the callbacks *shudder* :-).
I'm not sure that one of xml or http-over-a-socket is necessarily likely to
do more harm than the other. They simply attach in different places.
You're going to have to make the attachment clean in either case.
> It does seem rather inelegant to have two protocols when
> really what is needed is transport abstraction, though.
>
> What do you think?
I don't think. It hurts.
I'm not going to have time to implement this, so I'm going to stop wasting
bandwidth now.
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Mark Benedetto King <bk...@answerfriend.com>.
On Thu, Apr 18, 2002 at 11:38:44AM -0400, William Uther wrote:
> Hi,
> Was wandering home in an inebriated haze last night thinking about this...
Well, I was sober, but I still had many of the same ideas.
>
> People have been talking about ra_pipe. Someone mentioned putting a
> wrapper around the xml parts of svn to make it. Someone else mentioned they
> thought this would be pretty easy, but there were a few details to work out.
> BUT, doesn't svn already have a pipe protocol - it's called http/webdav. We
> want to replace the transport layer, not the protocol layer.
Yes.
>
> I don't know apache/neon that well. Does the following make any sense?
>
> I believe Apache can be run using inetd (although it is deprecated?). See
> <http://httpd.apache.org/docs/mod/core.html#servertype>. This will be our
> version of the cvs server.
The "please don't make me install apache-2.0 in order to use svn" request
seems reasonable enough to me. If that's the case, apache is right out,
run as-if-from-inetd or not. But does that mean *any* harness for mod_dav_svn
would be unacceptable? I'm not sure. It might not be *too* hard to slap
together a minimal harness for mod_dav_svn, for those that refuse to install
apache.
> Then you need to modify neon to create an ne_session from an already open
> socket.
Or modify neon to be able to create the connection via a callback mechanism,
instead of through socket()/connect(). I'm not sure this is an option,
and if it isn't, this approach would require an overhaul to ra_dav to
use neon via an abstraction.
>
> Finally, you define a new URI type:
> pipe:/rsh-cmd:user,password/host/rest/of/path/. When you get one of these
Because of the need for very rich syntax, and because of the frailty of
the URL validators, I've been thinking:
pipe://pipe-name/rest/of/path
Where "pipe-name" is looked up in the user's config to map to the relevant
stuff, of which there could be quite a bit, for certain pipe technologies.
One thing that is necessary is the actual repos-URL to use on the remote
side of the house.
> you use the supplied rsh-cmd and auth info to start up apache on the remote
> host in the same way inetd used to. This gives you a connection to apache
> over ssh. You make a new ne_session from your socket and the path in the
> URI.
As it stands ra_dav likes to open two sessions. This might be a lose
once you start talking about two SSHs and two mod_dav_svn harnesses.
I'm not sure what it uses those two sessions for, but it might need
to be turned off.
> You now have a secure http connection to the remote machine. ssh is the
> only aperture - this is not the same as running your own instance of apache
> on an unprivileged port. You do what ra_dav currently does over the http
> connection using the ne_session.
Yes, but you are still running apache, and you've gone and modified ra_dav
and/or neon.
>
> It is kinda ugly. It relies upon deprecated features in apache. It
I'm not sure that feature is so much deprecated as discouraged because of
apache's startup overhead. I could easily be wrong about that, though.
> assumes that svn can use "keep alive" stuff to do the entire transation over
> one ne_session. It doesn't require defining a new wire protocol.
AFAICT, svn already uses keep-alive, but it also uses more than one
session, as mentioned above. You're right that we wouldn't need a new
wire protocol, and that might be a big enough win to argue that the
changes to neon and/or ra_dav in order to take this approach would
be worth it.
Because of the "Hippocratic Principle" mentioned in HACKING, I had
planned on going ahead and implementing a new wire protocol. They're
really not that hard, and this one is simple. Or would be simple, if
not for the callbacks *shudder* :-).
It does seem rather inelegant to have two protocols when
really what is needed is transport abstraction, though.
What do you think?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Apr 18, 2002 at 08:15:05PM +0200, Peter Mathiasson wrote:
> On Thu, Apr 18, 2002 at 01:35:53PM -0400, Scott Lenser wrote:
> > machine to be encrypted. It could just be my general lack of understanding of
> > exactly how certificates are done, but I gave up after I add made what I thought
> > was a valid certificate and compiled apache with ssl support and then went to
> > try it and got nothing. Non-ssl connections could be used fine. I think any
>
> Subversion does not yet support verification of certificates, so using
> ssl (directly) with it is quite useless. If you need SSL right now, I
> would recommend tunneling it using stunnel (www.stunnel.org).
While it may not support server or client cert verification, it does support
SSL. That will prevent snooping, even if it might not prevent MITM or
similar attacks.
In other words, SVN *can* be used with SSL *today*. We just have some more
work to do, to increase the authentication security.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Peter Mathiasson <pe...@mathiasson.nu>.
On Thu, Apr 18, 2002 at 01:35:53PM -0400, Scott Lenser wrote:
> machine to be encrypted. It could just be my general lack of understanding of
> exactly how certificates are done, but I gave up after I add made what I thought
> was a valid certificate and compiled apache with ssl support and then went to
> try it and got nothing. Non-ssl connections could be used fine. I think any
Subversion does not yet support verification of certificates, so using
ssl (directly) with it is quite useless. If you need SSL right now, I
would recommend tunneling it using stunnel (www.stunnel.org).
I've never tried Apache's SSL support using client side certificates, so
I have no idea if that's working.
Currently, with all this new software I tunnel it through stunnel and
check client side certificates. That way apache/svn/ is not exposed to
the internet, just to clients who can provide a valid certificate.
--
Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu
GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228
Re: ssh based access?
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 18 Apr 2002, Garrett Rooney wrote:
> On Thu, Apr 18, 2002 at 12:39:28PM -0700, Brian Behlendorf wrote:
> > On Thu, 18 Apr 2002, Garrett Rooney wrote:
> > > right now, we don't work correctly on NFS at all. berkeley db does
> > > not function correctly on an NFS filesystem, so if that's needed,
> > > we're talking about rewriting the underlying filesystem, and i don't
> > > think anyone is jumping up to do that anytime soon...
> >
> > Actually, Berkeley DB does work over NFS, you just can only use it from
> > *one* environment at once.
> >
> > http://www.sleepycat.com/docs/ref/env/remote.html
>
> yes, but this sort of defeats the purpose of sticking the repository
> on a network drive so that multiple people can access it,
Of course. That's not the only reason to use NFS, though, and it's a long
way from "[doesn't] work correctly on NFS at all". Just clarifying.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Thu, Apr 18, 2002 at 12:39:28PM -0700, Brian Behlendorf wrote:
> On Thu, 18 Apr 2002, Garrett Rooney wrote:
> > right now, we don't work correctly on NFS at all. berkeley db does
> > not function correctly on an NFS filesystem, so if that's needed,
> > we're talking about rewriting the underlying filesystem, and i don't
> > think anyone is jumping up to do that anytime soon...
>
> Actually, Berkeley DB does work over NFS, you just can only use it from
> *one* environment at once.
>
> http://www.sleepycat.com/docs/ref/env/remote.html
yes, but this sort of defeats the purpose of sticking the repository
on a network drive so that multiple people can access it, since more
than likely they will be accessing it from multiple machines, and thus
there will be multiple environments accessing the DB at once.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
>On Thu, Apr 18, 2002 at 01:35:53PM -0400, Scott Lenser wrote:
>
>>>As I see CVS used around here there are 3 basic use cases.
>>>
>>>1) private repository accessed on local storage
>>>
>>>CVS does this, SVN does this. Although am I right in thinking that the use of
>>>db means you'd have problems if this was nfs mounted storage? If so this is
>>>rather limiting for people whose $HOME is network mounted.
>>>
>>I'd put the network mounted storage into use case 2. I've seen many CVS
>>repositories that are shared amongst a group of people simply by putting
>>the repository storage on a networked file system like AFS. This gives
>>reasonable performance and the filesystem already has all the permission
>>mechanisms built in. This is a pretty convenient way to share a repository
>>but isn't really necessary as long as there is a convenient way to handle
>>use case 2.
>>
>
>right now, we don't work correctly on NFS at all. berkeley db does
>not function correctly on an NFS filesystem, so if that's needed,
>we're talking about rewriting the underlying filesystem, and i don't
>think anyone is jumping up to do that anytime soon...
>
As a matter of fact, CVS can't be used safely over NFS either, because
of locking issues. This is IIRC explicitly stated in the CVS manual,
which recommends using pserver even for case 2. True, you don't often
see the problem, but I've heard enough horror stories about silently
corrupted CVS repositories that I tend to believe the docs.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 18 Apr 2002, Garrett Rooney wrote:
> right now, we don't work correctly on NFS at all. berkeley db does
> not function correctly on an NFS filesystem, so if that's needed,
> we're talking about rewriting the underlying filesystem, and i don't
> think anyone is jumping up to do that anytime soon...
Actually, Berkeley DB does work over NFS, you just can only use it from
*one* environment at once.
http://www.sleepycat.com/docs/ref/env/remote.html
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Thu, Apr 18, 2002 at 01:35:53PM -0400, Scott Lenser wrote:
> > As I see CVS used around here there are 3 basic use cases.
> >
> > 1) private repository accessed on local storage
> >
> > CVS does this, SVN does this. Although am I right in thinking that the use of
> > db means you'd have problems if this was nfs mounted storage? If so this is
> > rather limiting for people whose $HOME is network mounted.
> >
>
> I'd put the network mounted storage into use case 2. I've seen many CVS
> repositories that are shared amongst a group of people simply by putting
> the repository storage on a networked file system like AFS. This gives
> reasonable performance and the filesystem already has all the permission
> mechanisms built in. This is a pretty convenient way to share a repository
> but isn't really necessary as long as there is a convenient way to handle
> use case 2.
right now, we don't work correctly on NFS at all. berkeley db does
not function correctly on an NFS filesystem, so if that's needed,
we're talking about rewriting the underlying filesystem, and i don't
think anyone is jumping up to do that anytime soon...
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Scott Lenser <sl...@cs.cmu.edu>.
> As I see CVS used around here there are 3 basic use cases.
>
> 1) private repository accessed on local storage
>
> CVS does this, SVN does this. Although am I right in thinking that the use of
> db means you'd have problems if this was nfs mounted storage? If so this is
> rather limiting for people whose $HOME is network mounted.
>
I'd put the network mounted storage into use case 2. I've seen many CVS
repositories that are shared amongst a group of people simply by putting
the repository storage on a networked file system like AFS. This gives
reasonable performance and the filesystem already has all the permission
mechanisms built in. This is a pretty convenient way to share a repository
but isn't really necessary as long as there is a convenient way to handle
use case 2.
> 2) repository used by small group/one person over a few machines
>
> CVS does ok here. It's a little clunky but the rsh (ssh) route works very
> well. As it currently stands SVN doesn't seem to fit. It requires someone
> to setup apache to provide the authentication and authorisation, ignoring the
> security infrastructure local to the site. If people were to run
> repositories from local workstations they would need to run a new network
> server which would need maintaining. Plus the user would have to set up
> access control themselves, which they may, or may not, be capable of doing
> securely.
>
> 3) actively maintained repository for a larger (possibly publicly) accessed
> project
>
> CVS has well known limitations here, ssh isn't the best solution, and pserver
> doesn't do too well. SVN is designed to fix them. I'm really looking
> forward to being able to replace CVS repositories which I maintain for wider
> usage with subversion when it's ready.
>
> To be as useful as CVS, subversion _must_ support usage style (2) better than
> it currently does. I don't think that any solution involving setting up
> something as apache will fly here. A streamable protocol which can be piped
> over ssh, or any other socket for that matter, which maps onto local unix
> access semantics is ideal. For me this is a 1.0 requirement, but then you're
> the developers, I'm just a user ;-).
>
I agree with the sentiment that more attention needs to be paid to use case 2.
I'm not sure that apache necessarily is excluded by this though. Personally,
I felt setting up for use case 2 was painful but not excessively so enough to
make me not want to use subversion; until I wanted the traffic to the repository
machine to be encrypted. It could just be my general lack of understanding of
exactly how certificates are done, but I gave up after I add made what I thought
was a valid certificate and compiled apache with ssl support and then went to
try it and got nothing. Non-ssl connections could be used fine. I think any
solution that approximates the amount of overhead of setting up user accounts
for everyone and setting up keys for everyone is fine, even if apache is used.
I think the comparison should be setting up cvs+accounts+ssh+keys versus
setting up apache+ssl+certificates+permissions. I don't think apache is that
bad until the permission stuff enters into it.
Perhaps, this could be taken care of simply by pointing to the appropriate
Apache HOWTO plus an example of accessing a ssl-based repository. If I
get time to look into this some more and manage to get it work, I'll write
up a little HOWTO for you. Other transport mechanisms would be nice, but I
think these can be a post-1.0 item.
> After writing all this I'm sorry that I don't have the time to offer help. I
> really hope that subversion turns out to be a success.
>
ditto.
- Scott Lenser
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by William Uther <wi...@cs.cmu.edu>.
Hi,
Was wandering home in an inebriated haze last night thinking about this...
People have been talking about ra_pipe. Someone mentioned putting a
wrapper around the xml parts of svn to make it. Someone else mentioned they
thought this would be pretty easy, but there were a few details to work out.
BUT, doesn't svn already have a pipe protocol - it's called http/webdav. We
want to replace the transport layer, not the protocol layer.
I don't know apache/neon that well. Does the following make any sense?
I believe Apache can be run using inetd (although it is deprecated?). See
<http://httpd.apache.org/docs/mod/core.html#servertype>. This will be our
version of the cvs server.
Then you need to modify neon to create an ne_session from an already open
socket.
Finally, you define a new URI type:
pipe:/rsh-cmd:user,password/host/rest/of/path/. When you get one of these
you use the supplied rsh-cmd and auth info to start up apache on the remote
host in the same way inetd used to. This gives you a connection to apache
over ssh. You make a new ne_session from your socket and the path in the
URI.
You now have a secure http connection to the remote machine. ssh is the
only aperture - this is not the same as running your own instance of apache
on an unprivileged port. You do what ra_dav currently does over the http
connection using the ne_session.
It is kinda ugly. It relies upon deprecated features in apache. It
assumes that svn can use "keep alive" stuff to do the entire transation over
one ne_session. It doesn't require defining a new wire protocol.
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by John Pybus <jo...@pybus.org>.
On Tuesday 16 Apr 2002 7:00 am, Greg Stein wrote:
> On Tue, Apr 16, 2002 at 12:15:12AM +0200, Lodewijk Voge wrote:
> > exactly. I only have my own university as a frame of reference, but I see
> > that scheme being used a lot. very light-weight and no special privileges
> > needed.
>
> "special privileges" *ARE* needed. Specifically, you need an account on the
> target machine.
>
> In normal Subversion [server] operation, users only need Apache logons
> rather than system accounts. From a security standpoint, avoiding the
> system accounts is a HUGE win.
As I see CVS used around here there are 3 basic use cases.
1) private repository accessed on local storage
CVS does this, SVN does this. Although am I right in thinking that the use of
db means you'd have problems if this was nfs mounted storage? If so this is
rather limiting for people whose $HOME is network mounted.
2) repository used by small group/one person over a few machines
CVS does ok here. It's a little clunky but the rsh (ssh) route works very
well. As it currently stands SVN doesn't seem to fit. It requires someone
to setup apache to provide the authentication and authorisation, ignoring the
security infrastructure local to the site. If people were to run
repositories from local workstations they would need to run a new network
server which would need maintaining. Plus the user would have to set up
access control themselves, which they may, or may not, be capable of doing
securely.
3) actively maintained repository for a larger (possibly publicly) accessed
project
CVS has well known limitations here, ssh isn't the best solution, and pserver
doesn't do too well. SVN is designed to fix them. I'm really looking
forward to being able to replace CVS repositories which I maintain for wider
usage with subversion when it's ready.
While they are both network accessed repositories, cases (2) and (3) are very
different in requirements. For (3) not needing system accounts is a big win,
for (2) not requiring them is a BIG loss!
In many cases what starts out as case (1) very soon becomes (2). Almost all
the repositories I started out using locally I have at some point or other
accessed remotely, it's very handy to be able to use ssh to access from a
remote site occasionally. With CVS/ssh I can do this even from outside a
firewall, and I get it all for free I don't have to setup usernames/passwords
etc, other than what is already there in my devel environment.
To be as useful as CVS, subversion _must_ support usage style (2) better than
it currently does. I don't think that any solution involving setting up
something as apache will fly here. A streamable protocol which can be piped
over ssh, or any other socket for that matter, which maps onto local unix
access semantics is ideal. For me this is a 1.0 requirement, but then you're
the developers, I'm just a user ;-).
After writing all this I'm sorry that I don't have the time to offer help. I
really hope that subversion turns out to be a success.
Yours,
John Pybus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Apr 16, 2002 at 12:15:12AM +0200, Lodewijk Voge wrote:
> Kevin Pilch-Bisson wrote:
>
> > I think the point is that if you have shell but not root access to the
> > machine, you can login and do 'cvs init', then use the resulting repository
> > remotely with CVS_RSH.
>
> exactly. I only have my own university as a frame of reference, but I see that
> scheme being used a lot. very light-weight and no special privileges needed.
"special privileges" *ARE* needed. Specifically, you need an account on the
target machine.
In normal Subversion [server] operation, users only need Apache logons
rather than system accounts. From a security standpoint, avoiding the system
accounts is a HUGE win.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Lodewijk Voge <lo...@reddwarf.xs4all.nl> writes:
> Kevin Pilch-Bisson wrote:
> > I think the point is that if you have shell but not root access to the
> > machine, you can login and do 'cvs init', then use the resulting
> > repository remotely with CVS_RSH.
>
> exactly. I only have my own university as a frame of reference, but
> I see that scheme being used a lot. very light-weight and no special
> privileges needed.
Well...
- log into server using your shell account
- svnadmin create repository in your home account
- set up Apache2 (with mod_dav_svn) in your home account :-)
- run Apache on some non-privileged port
:-) (?)
Not as "lightweight" as CVS, I admit, but still no special privileges
needed.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Lodewijk Voge <lo...@reddwarf.xs4all.nl>.
Kevin Pilch-Bisson wrote:
> I think the point is that if you have shell but not root access to the
> machine, you can login and do 'cvs init', then use the resulting repository
> remotely with CVS_RSH.
exactly. I only have my own university as a frame of reference, but I see that
scheme being used a lot. very light-weight and no special privileges needed.
Lodewijk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Marcus Comstedt <ma...@mc.pp.se>.
Ben Collins-Sussman <su...@collab.net> writes:
> Does sshd just magically know how to run cvs?
sshd runs the command it's told to run by ssh.
Try
ssh a.machine date
Instead of "date" you could use something like "cvs --server", and
that's just what cvs does. So all that's needed is that sshd is
running and that the cvs client is installed somewhere on the remote
system.
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Apr 15, 2002 at 05:03:37PM -0500, Ben Collins-Sussman wrote:
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > > Can you really run 'cvs init' over a network connection? It seems to
> > > hang when kfogel tries that. Can you give an example?
> >
> > I think the point is that if you have shell but not root access to the
> > machine, you can login and do 'cvs init', then use the resulting repository
> > remotely with CVS_RSH.
>
> I think I don't understand. If I log into a machine and use 'cvs
> init' to create a CVS repository in my home directory, that's still
> not enough. Somebody *still* has to set up inetd to answer cvs
> requests, no? Or do I totally misunderstand? Isn't there *some*
> kind of server picking up the line, which needs to be configured?
Well sshd needs to be configured. I've never actually administered this type
of setup, but I don't think it needs to be set up for each repository.
As far as pserver goes, the repository needs to be allowed in /etc/inetd.conf
(or elsewhere such as /etc/cvs-pserver.conf on debian).
> Does sshd just magically know how to run cvs?
Pretty much.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Ben Collins-Sussman <su...@collab.net> writes:
> I think I don't understand. If I log into a machine and use 'cvs
> init' to create a CVS repository in my home directory, that's still
> not enough. Somebody *still* has to set up inetd to answer cvs
> requests, no? Or do I totally misunderstand? Isn't there *some*
> kind of server picking up the line, which needs to be configured?
> Does sshd just magically know how to run cvs?
ssh is a replacement for rsh. You just remote shell the cvs server. No
inetd involved.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: ssh based access?
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: 16 April 2002 00:04
> Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
>
> > > Can you really run 'cvs init' over a network connection? It seems to
> > > hang when kfogel tries that. Can you give an example?
> >
> > I think the point is that if you have shell but not root access to the
> > machine, you can login and do 'cvs init', then use the resulting repository
> > remotely with CVS_RSH.
>
> I think I don't understand. If I log into a machine and use 'cvs
> init' to create a CVS repository in my home directory, that's still
> not enough. Somebody *still* has to set up inetd to answer cvs
> requests, no? Or do I totally misunderstand? Isn't there *some*
> kind of server picking up the line, which needs to be configured?
> Does sshd just magically know how to run cvs?
cvs runs ssh to execute 'cvs --server' on the other side. From there
you are set. You already pass the full path to the repos on the cmdline
remember? So, when sshd is running, you have an ssh account and cvs
is installed on the server, it just works.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Ben Collins-Sussman <su...@collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > Can you really run 'cvs init' over a network connection? It seems to
> > hang when kfogel tries that. Can you give an example?
>
> I think the point is that if you have shell but not root access to the
> machine, you can login and do 'cvs init', then use the resulting repository
> remotely with CVS_RSH.
I think I don't understand. If I log into a machine and use 'cvs
init' to create a CVS repository in my home directory, that's still
not enough. Somebody *still* has to set up inetd to answer cvs
requests, no? Or do I totally misunderstand? Isn't there *some*
kind of server picking up the line, which needs to be configured?
Does sshd just magically know how to run cvs?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Apr 15, 2002 at 04:47:16PM -0500, Ben Collins-Sussman wrote:
> lodewijk@reddwarf.xs4all.nl writes:
>
> > Perry E. Metzger wrote:
> >
> > > I realize that extracting Apache and such from the process would be
> > > very hard, but would it be difficult to make the standard tools able
> > > to operate through port forwarded ssh connections the way that CVS
> > > happily operates via CVS_RSH=ssh based connections?
> >
> > on a somewhat related note, using CVS over ssh I can set up a repository on
> > machines I only have a lowly shell account on. what is going to be the
> > Subversion way of achieving that? right now setting up a server is pretty
> > heavy stuff compared to 'cvs init'. will (or can, even) there be something
> > like it?
>
> Can you really run 'cvs init' over a network connection? It seems to
> hang when kfogel tries that. Can you give an example?
I think the point is that if you have shell but not root access to the
machine, you can login and do 'cvs init', then use the resulting repository
remotely with CVS_RSH.
<snip>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: ssh based access?
Posted by Ben Collins-Sussman <su...@collab.net>.
lodewijk@reddwarf.xs4all.nl writes:
> Perry E. Metzger wrote:
>
> > I realize that extracting Apache and such from the process would be
> > very hard, but would it be difficult to make the standard tools able
> > to operate through port forwarded ssh connections the way that CVS
> > happily operates via CVS_RSH=ssh based connections?
>
> on a somewhat related note, using CVS over ssh I can set up a repository on
> machines I only have a lowly shell account on. what is going to be the
> Subversion way of achieving that? right now setting up a server is pretty
> heavy stuff compared to 'cvs init'. will (or can, even) there be something
> like it?
Can you really run 'cvs init' over a network connection? It seems to
hang when kfogel tries that. Can you give an example?
Let me clarify how subversion works:
* to create a repository, you run 'svnadmin create <path>', where
PATH is some local path. It could be right in your home
directory.
* there is [currently] no way to create an svn repository over a
network connection. 'svndadmin create' just writes out a DB
environment.
* when you say "set up" a repository, I assume you mean "make it
accessible over a network". The only way to do that is to use
Apache. Then again, this is no worse than CVS's requirements. If
you don't have some kind of priviledge on the machine, you can no
sooner modify inetd to launch cvs/pserver processes than you can
modify Apache to listen for svn requests.
* if you only want to access your repository locally (via direct DB
access), then compile the ra_local module into your client.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by lo...@reddwarf.xs4all.nl.
Perry E. Metzger wrote:
> I realize that extracting Apache and such from the process would be
> very hard, but would it be difficult to make the standard tools able
> to operate through port forwarded ssh connections the way that CVS
> happily operates via CVS_RSH=ssh based connections?
on a somewhat related note, using CVS over ssh I can set up a repository on
machines I only have a lowly shell account on. what is going to be the
Subversion way of achieving that? right now setting up a server is pretty
heavy stuff compared to 'cvs init'. will (or can, even) there be something
like it?
Lodewijk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Mark Benedetto King <bk...@answerfriend.com> writes:
> You're leaving out that CVS_RSH=ssh does not create an unathenticated
> tunnel from a potentially untrusted environment into the trusted one.
>
> While you're doing your "svn up" over a port-forwarded tunnel, an
> attacker can utilize the same channel to their own nefarious ends.
>
> SSL solves this problem. So would an in-band ssh connection, like
> CVS_RSH's.
>
> If SSL isn't an option, and neither is enhancing neon to hide
> the SSH part, the best I can come up with is "ra_ssh", which
> would need some command-line support (in the same vein as
> "cvs server"). This may be more trouble than it is worth.
I don't know if it is more trouble than it is worth -- it will make
things easier for many people using SSH and CVS currently.
Perry
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Mark Benedetto King <bk...@answerfriend.com>.
On Mon, Apr 15, 2002 at 05:17:29PM -0400, Perry E. Metzger wrote:
>
> Blair Zajac <bl...@orcaware.com> writes:
> > ssh -L20123:localhost:888 username@svn.repository.org sleep 100000000
> >
> > And then access svn through the URL
> >
> > http://localhost:20123/
> >
> > The -L sets up an SSH port forward.
> >
> > You need some command on the remote system to keep ssh the ssh connection
> > alive, hence the sleep.
>
> You are supposed to use -N for that. You don't in fact need a command
> on the remote system.
Well, the specific option depends on the ssh implementation. :-)
>
> What I'm really looking for is a way to do this such that we can
> configure the proxies in the client and the localhost:20123 thing can
> get papered over (as well as having to explicitly start ssh for this.)
>
You're leaving out that CVS_RSH=ssh does not create an unathenticated
tunnel from a potentially untrusted environment into the trusted one.
While you're doing your "svn up" over a port-forwarded tunnel, an
attacker can utilize the same channel to their own nefarious ends.
SSL solves this problem. So would an in-band ssh connection, like
CVS_RSH's.
If SSL isn't an option, and neither is enhancing neon to hide
the SSH part, the best I can come up with is "ra_ssh", which
would need some command-line support (in the same vein as
"cvs server"). This may be more trouble than it is worth.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Blair Zajac <bl...@orcaware.com> writes:
> ssh -L20123:localhost:888 username@svn.repository.org sleep 100000000
>
> And then access svn through the URL
>
> http://localhost:20123/
>
> The -L sets up an SSH port forward.
>
> You need some command on the remote system to keep ssh the ssh connection
> alive, hence the sleep.
You are supposed to use -N for that. You don't in fact need a command
on the remote system.
What I'm really looking for is a way to do this such that we can
configure the proxies in the client and the localhost:20123 thing can
get papered over (as well as having to explicitly start ssh for this.)
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Blair Zajac <bl...@orcaware.com>.
"Perry E. Metzger" wrote:
>
> I've been lurking for quite some time, following subversion
> development with interest. One issue that is big for the folks over in
> NetBSD (my open source project poison of choice) is secure access to
> the source repository. Currently, we do all our access to our CVS
> repository via ssh, and people are very happy with ssh as a transport
> mechanism. There is probably a lot of resistance to opening up other
> holes on the main source repository.
>
> I realize that extracting Apache and such from the process would be
> very hard, but would it be difficult to make the standard tools able
> to operate through port forwarded ssh connections the way that CVS
> happily operates via CVS_RSH=ssh based connections?
Well, Subversion does support SSL through Apache's support of SSL.
But you could use SSH as well. Say you have an Apache 2.0/Svn server
running on port 8888 on svn.repository.org and you do not have root
access on your local machine. You would set up a SSH tunnel doing
something like:
ssh -L20123:localhost:888 username@svn.repository.org sleep 100000000
And then access svn through the URL
http://localhost:20123/
The -L sets up an SSH port forward.
You need some command on the remote system to keep ssh the ssh connection
alive, hence the sleep.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Apr 17, 2002 at 06:29:38PM +0200, Marcus Comstedt wrote:
>
> Michael Wood <mw...@its.uct.ac.za> writes:
>
> > How many passengers can you fit on a pigeon anyway? :)
>
>
> An african or a european pigeon?
I don't know.
Aaaaaaaahhhhh!!!!
:-)
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Marcus Comstedt <ma...@mc.pp.se>.
Michael Wood <mw...@its.uct.ac.za> writes:
> How many passengers can you fit on a pigeon anyway? :)
An african or a european pigeon?
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Tue, Apr 16, 2002 at 10:43:26AM -0500, Karl Fogel wrote:
[snip]
> We would certainly include new ra modules like this in the
> project, whatever kind of access they offer (unless it's
> something really silly, like libsvn_ra_passenger_pigeon). The
> more the merrier.
[snip]
How many passengers can you fit on a pigeon anyway? :)
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> * What you really want is a new ra module which operates over a stream
> connection, supports tunneling over an rsh-like agent, and doesn't
> require Apache. I would like to see this too, but it's a significant
> amount of work, and no one has stepped up to the plate for it yet. I
> don't believe the project would reject the work if it were done, though
> (particularly if a qualified developer were around to support it).
We would certainly include new ra modules like this in the project,
whatever kind of access they offer (unless it's something really
silly, like libsvn_ra_passenger_pigeon). The more the merrier.
But yes, current developer focus is on libsvn_ra_dav and mod_dav_svn.
WebDAV+DeltaV is the network protocol we *know* we're supporting,
anything else is gravy.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2002-04-15 at 19:10, Perry E. Metzger wrote:
> It will in any case be much harder to switch over the NetBSD community
> if the only mechanism available is ssl via apache.
I think the answer to your question is:
* Right now you can do it with some awful tunnel hacks, but you'll
still have to run apache for the last hop. (You can tunnel ra_dav, but
you can't tunnel ra_local, since ra_local is not a stream protocol.)
It's possible that Subversion could make this a little more transparent,
but it's never going to be ideal.
* What you really want is a new ra module which operates over a stream
connection, supports tunneling over an rsh-like agent, and doesn't
require Apache. I would like to see this too, but it's a significant
amount of work, and no one has stepped up to the plate for it yet. I
don't believe the project would reject the work if it were done, though
(particularly if a qualified developer were around to support it).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > Certs are evil. SSH doesn't require them -- it just uses naked public
> > keys -- which is one reason people like it so much.
>
> well, i'm relatively certain that we're not going to be requiring
> them, but if we want to provide the same functionality (or at least
> most of it) that you can get with cvs/ssh, then we'll need it.
Unless some sort of "via ssh" functionality comes in, thus part of my
original question.
It will in any case be much harder to switch over the NetBSD community
if the only mechanism available is ssl via apache. Apache is regarded
as large and hard to audit system, and thus unsuitable as a program
exposed to the network on a security critical machine like a central
source repository. ssh is a much narrower arpeture -- it has had bugs,
but it is much better understood from this perspective, and in
general, its one of those "you have to run it anyway" sort of
programs. An additional arpeture is frowned on.
I'll point out, btw, that when I mention subversion to security
oriented people, everyone sounds very impressed until I say
"Apache/DAV", at which point looks of terror cross their faces.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Apr 15, 2002 at 06:48:45PM -0400, Perry E. Metzger wrote:
>
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > > There are known problems with mod_deflate, and there were some
> > > problems with
> > > apache's ssl stuff until recently, but the only known ssl problem we have
> > > right now (that I am aware of), is that we don't do any
> > > certificate handling.
> >
> > the lack of certificate handling was the major problem i was refering
> > to.
>
> Certs are evil. SSH doesn't require them -- it just uses naked public
> keys -- which is one reason people like it so much.
well, i'm relatively certain that we're not going to be requiring
them, but if we want to provide the same functionality (or at least
most of it) that you can get with cvs/ssh, then we'll need it.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Peter Mathiasson <pe...@mathiasson.nu>.
On Mon, Apr 15, 2002 at 06:48:45PM -0400, Perry E. Metzger wrote:
>
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > > There are known problems with mod_deflate, and there were some
> > > problems with
> > > apache's ssl stuff until recently, but the only known ssl problem we have
> > > right now (that I am aware of), is that we don't do any
> > > certificate handling.
> >
> > the lack of certificate handling was the major problem i was refering
> > to.
>
> Certs are evil. SSH doesn't require them -- it just uses naked public
> keys -- which is one reason people like it so much.
What's the big different between client side certs and SSH keys? I mean,
you could install client side generated certs for use with your ssl
server. You install the public cert on the server, and the user has his
private cert (just like a ssh user has a public key on the server, and a
private of his own).
This is exactly how I do it currently.
--
Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu
GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Apr 16, 2002 at 11:41:17AM -0400, Perry E. Metzger wrote:
>
> Greg Stein <gs...@lyra.org> writes:
> > On Mon, Apr 15, 2002 at 10:27:17PM -0400, Perry E. Metzger wrote:
> > > Brian Behlendorf <br...@collab.net> writes:
>...
> > > > If the extra modules are stripped out, and you run only the prefork MPM,
> > > > it's pretty small.
> > >
> > > But that's not how we're running Apache for subversion.
> >
> > But that would appear to be your choice, hmm? You could definitely choose to
> > run an Apache that is configured much "smaller" on your source code
> > repository box.
>
> How? I still need to run DAV and such.
In my Apache executable right now, I have 20 builtin modules, and
mod_dav_svn is loaded dynamically. My point was that you could strip that
list down to mod_dav plus a limited few (probably mod_log_config, mod_ssl,
and maybe a mod_auth_foo for your local auth mechanism).
>...
> > Or if you don't want users to mess with ports, you could use
> > ProxyPass on your main web server and pass request thru to the
> > internal interface/port where you've got your locked-down Subversion
> > server.
>
> When I ran a security consultancy, I made so much money off of
> mentally challenged people1 who thought that proxies through the
> firewall added security it wasn't funny. "Our web server is secure! We
> have a firewall in front of it!"
>
> The web server and associated software are the most dangerous pieces
> of almost any company. I earned a very good living explaining to
> people after they'd been broken into and mutilated why the apache
> server had to be OUTSIDE the firewall.
You misunderstood me. I meant that you could run your big, bulky web server
and proxy-pass the source control back to your tighter-than-snot server and
box. This would make it appear that the source control was on the big
server.
>...
> > > > It's not like people aren't running Apache in pretty secure
> > > > production situations - it's at least secure enough for netbsd's own web
> > > > site (and openbsd's as well).
> > >
> > > Our web site is not considered a secure application. We're fully
> >
> > Why is it on the same box as the source code repository?
>
> It isn't. We don't want to run Apache on the repository box, or rely
> on Apache being secure.
Gotcha. But what makes sshd more secure than a locked down Apache? Is it
simply that Apache has not been as thoroughly reviewed? What if it was?
i.e. is there a point in the future where it is possible that Apache is
deemed secure enough?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Greg Stein <gs...@lyra.org> writes:
> On Mon, Apr 15, 2002 at 10:27:17PM -0400, Perry E. Metzger wrote:
> > Brian Behlendorf <br...@collab.net> writes:
> > > > The real problem is that Apache is very large. It has to be to do all
> > > > that it does, but that means that it is hard to secure it because you
> > > > can't audit all the relevant code. Big is bad in security.
> > >
> > > If the extra modules are stripped out, and you run only the prefork MPM,
> > > it's pretty small.
> >
> > But that's not how we're running Apache for subversion.
>
> But that would appear to be your choice, hmm? You could definitely choose to
> run an Apache that is configured much "smaller" on your source code
> repository box.
How? I still need to run DAV and such.
> Run that on some alternate port, and you'll be set.
The port number isn't the issue.
> Or if you don't want users to mess with ports, you could use
> ProxyPass on your main web server and pass request thru to the
> internal interface/port where you've got your locked-down Subversion
> server.
When I ran a security consultancy, I made so much money off of
mentally challenged people1 who thought that proxies through the
firewall added security it wasn't funny. "Our web server is secure! We
have a firewall in front of it!"
The web server and associated software are the most dangerous pieces
of almost any company. I earned a very good living explaining to
people after they'd been broken into and mutilated why the apache
server had to be OUTSIDE the firewall.
> The point is: if you want to get seriously tight with the security of the
> server, the options are there.
They aren't.
> [ and note that using apache as a proxypass thingy, you could map ssl on the
> outside to a plain http on the inside so the secure repository doesn't
> have to install ssl code ]
Oh, great. "Crunchy on the outside, chewy middle, more moving parts".
> >...
> > > It's not like people aren't running Apache in pretty secure
> > > production situations - it's at least secure enough for netbsd's own web
> > > site (and openbsd's as well).
> >
> > Our web site is not considered a secure application. We're fully
>
> Why is it on the same box as the source code repository?
It isn't. We don't want to run Apache on the repository box, or rely
on Apache being secure.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Apr 15, 2002 at 10:27:17PM -0400, Perry E. Metzger wrote:
> Brian Behlendorf <br...@collab.net> writes:
> > > The real problem is that Apache is very large. It has to be to do all
> > > that it does, but that means that it is hard to secure it because you
> > > can't audit all the relevant code. Big is bad in security.
> >
> > If the extra modules are stripped out, and you run only the prefork MPM,
> > it's pretty small.
>
> But that's not how we're running Apache for subversion.
But that would appear to be your choice, hmm? You could definitely choose to
run an Apache that is configured much "smaller" on your source code
repository box. Run that on some alternate port, and you'll be set. Or if
you don't want users to mess with ports, you could use ProxyPass on your
main web server and pass request thru to the internal interface/port where
you've got your locked-down Subversion server.
The point is: if you want to get seriously tight with the security of the
server, the options are there.
[ and note that using apache as a proxypass thingy, you could map ssl on the
outside to a plain http on the inside so the secure repository doesn't
have to install ssl code ]
>...
> > It's not like people aren't running Apache in pretty secure
> > production situations - it's at least secure enough for netbsd's own web
> > site (and openbsd's as well).
>
> Our web site is not considered a secure application. We're fully
Why is it on the same box as the source code repository? Assuming you've
split the two, then the Apache running on the SVN box is single-purpose.
> prepared (and expect) for it to be broken into and to have to recover
> it. Our code repository is a very different animal. Breakins there
> could be very bad.
Agreed. apache.org has been through that, and I sympathize with the
resulting problems.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Alex Holst <a...@area51.dk>.
Quoting Perry E. Metzger (perry@wasabisystems.com):
> It isn't a question of what we would like. In general, once an app
> gets too large you can't audit it, and Apache is way way bigger than
> you can audit.
Nonsense, it just requires more of an effort. I'm as (much more,
actually) concerned about the assurance of the software I use as the
next guy, but saying "it's too big to audit" is FUD. I agree it is a
substantial codebase, but it is not an impossible task. It helps when
someone other than the vendor is willing to testify to the quality of a
piece of software. Brian Snow's talk on "We Need Assurance" (available
as streams on the blackhat.com site) explains some of this.
I recall that OpenBSD fed patches of 1.x back to the Apache developers.
I see no reason that they won't do this with 2.0 if they decide that
Subversion takes the place of cvs.openbsd.org -- which also runs Apache.
Apache 1.3.x has greater levels of assurance attached to it than OpenSSH
currently does. Apache 2.x currently carries almost no assurance but
eventually, it will. If you require greater assurance than "almost
none", and you require it _now_ get your NetBSD code reviewers out of
bed, cause there's work to be done.
Alex
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.area51.dk/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Sean Russell <se...@germane-software.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue April 16 2002 00:09, Greg Stein wrote:
> There is nothing to support that Apache has problematic buffer overflows.
> Most of the problems over the past year or two have been related to poor
> processing rather than overflows. We've had a couple overflows on Windows,
> but that's about it.
>
> Heck, there isn't anything that says that Subversion doesn't have buffer
> overflows. New code. New problems.
His point is that it is easier to sandbox repositories with the hypothetical
ra_ssh.
Currently subversion and apache are running as a privileged user of some sort
- -- httpd, nobody, what have you. A buffer overflow exploit anywhere in the
architecture will give the attacker access to at least a shared repository.
With ra_ssh (or whatever), you open up a new possibility for sandboxing: each
user can create their own repository in their own home. Subversion processes
are run as that user, and any failure of security in the system will affect
only that user's repository.
Additionally, there is only one point of attack: the sshd daemon. To break
ra_ssh, you'd need to break sshd, because you tunnel through SSH to start the
subversion server process. SSH is a sort of firewall. With ra_dav, there
are multiple points of attack, as you've pointed out: httpd itself, mod_dav,
whatever.
> And you know... for that matter, has anybody actually audited CVS? Hoo... I
> have seen its network code. Ohmigod. I double-dare you to audit that.
Right... but the exploits of CVS are really limited, when used via SSH. In
that case, the CVS server runs as the UID of the user, and your only access
to it is through SSH. IE, if you've got that set-up, it doesn't matter if
CVS is weak, because if you have SSH access to that account you can mess with
the repository directly.
I *think* the confusion is about the nature of how ra_ssh and ra_dav would
work, on the server side. ra_ssh is all about user processes, running in
user space (except for the SSH daemon itself). ra_dav is about global
processes, running in a public space. The only way you could simulate the
sandboxing you get with ra_ssh would be to run an Apache process as each
user, local to their $HOME.
- --
|.. "To the youth of America, I say, beware of being trivialized by the
<|> commercial culture that tempts you daily. I hear you saying often
/|\ that you're not turned on by politics. The lessons of history are
/| clear and portentous. If you do not turn onto politics, politics
| will turn on you." - Ralph Nader
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8vDCrP0KxygnleI8RAtHQAJ0U84gRbp5HtXfsoILdo5ENJII/8gCfelvm
cT7jBHXhsYdZLu8XCe8aqmc=
=KQ/9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> The ra_pipe would actually not be that hard to implement.
That would be the ideal thing, I think.
> We already have the capability of doing the client side operations
> into an xml file. All that would be needed is a way to read one of
> those xml files on stdin, and apply it over ra_local. Shouldn't
> actually be much work at all. Basically just a set of expat
> handlers which call the ra_local vtable entries with the appropriate
> info from the xml file.
>
> For an example of the xml stuff, try doing svn ci --xml-file=foo.xml.
>
> The only other change can think of would be a way to get the new revnum back
> over the wire to do the post-commit rev-bumping.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
ra_pipe / xml / marshalling (was: ssh based access?)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Apr 16, 2002 at 01:51:44PM -0400, Kevin Pilch-Bisson wrote:
>...
> The ra_pipe would actually not be that hard to implement. We already have
> the capability of doing the client side operations into an xml file. All that
> would be needed is a way to read one of those xml files on stdin, and apply it
> over ra_local. Shouldn't actually be much work at all. Basically just a
> set of expat handlers which call the ra_local vtable entries with the
> appropriate info from the xml file.
>
> For an example of the xml stuff, try doing svn ci --xml-file=foo.xml.
>
> The only other change can think of would be a way to get the new revnum back
> over the wire to do the post-commit rev-bumping.
Much of the marshalling could even replicate what is being done by ra_dav
and mod_dav_svn. e.g. how we marshal 'svn log' over the wire. Just
substitute a pipe for a socket, and it is basically the same (minus all that
HTTP crap :-)
But yes: our XML stuff is an effective serialization/marshalling format
which is already in the code. It is horribly unmaintained at the moment, but
I suspect that it is going to be "darned close" if somebody cares to
concentrate on it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Apr 16, 2002 at 01:11:10PM -0400, Perry E. Metzger wrote:
>
> Karl Fogel <kf...@newton.ch.collab.net> writes:
> > Basically agree with Perry's points, though, bluntness of expression
> > aside.
>
> I'm not known for sufficient gentleness, I'm afraid. A personal failing.
>
> I know that a new RA layer is not something to do for 1.0, but what
> I'm looking for (and more or less was looking for from the start) is
> hooks in the client software to make use with ugly tunnel based hacks
> over ssh easier for the end user. Eventually we could talk about a new
> RA when things are further along.
The ra_pipe would actually not be that hard to implement. We already have
the capability of doing the client side operations into an xml file. All that
would be needed is a way to read one of those xml files on stdin, and apply it
over ra_local. Shouldn't actually be much work at all. Basically just a
set of expat handlers which call the ra_local vtable entries with the
appropriate info from the xml file.
For an example of the xml stuff, try doing svn ci --xml-file=foo.xml.
The only other change can think of would be a way to get the new revnum back
over the wire to do the post-commit rev-bumping.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Basically agree with Perry's points, though, bluntness of expression
> aside.
I'm not known for sufficient gentleness, I'm afraid. A personal failing.
I know that a new RA layer is not something to do for 1.0, but what
I'm looking for (and more or less was looking for from the start) is
hooks in the client software to make use with ugly tunnel based hacks
over ssh easier for the end user. Eventually we could talk about a new
RA when things are further along.
Perry
> Saying "we don't know of any buffer overrun bugs in Apache"
> isn't very meaningful compared with a real security audit. The more
> lines of code, the more difficult the audit. So what can we conclude?
> What we already knew: that we don't know for sure how secure
> Subversion is.
>
> Fine. But:
>
> We're not going to suddenly start writing a new RA layer. We've got
> enough to do before 1.0 as it is. Apache+Subversion is what you get
> for now, unless you can volunteer the time to make an alternative.
> (And if you choose the latter course, we're happy to help!)
>
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Perry E. Metzger" <pe...@wasabisystems.com> writes:
> actually understand the problem. If you want to ignore all that and
> just say "oh, no one has proven Apache has any more bugs, lets thumb
> our nose at those horrid security dweebs", well, you're acting like
> Microsoft.
Hee hee! I'm thinking of an obvious corrolary to Godwin's Law
http://www.tuxedo.org/jargon/html/entry/Godwin's-Law.html
now... :-)
Basically agree with Perry's points, though, bluntness of expression
aside. Saying "we don't know of any buffer overrun bugs in Apache"
isn't very meaningful compared with a real security audit. The more
lines of code, the more difficult the audit. So what can we conclude?
What we already knew: that we don't know for sure how secure
Subversion is.
Fine. But:
We're not going to suddenly start writing a new RA layer. We've got
enough to do before 1.0 as it is. Apache+Subversion is what you get
for now, unless you can volunteer the time to make an alternative.
(And if you choose the latter course, we're happy to help!)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Apr 16, 2002 at 11:31:12AM -0400, Perry E. Metzger wrote:
>
> Greg Stein <gs...@lyra.org> writes:
> > There is nothing to support that Apache has problematic buffer overflows.
>
> Let me get very very blunt right now. You want to get Microsoft's
> reputation here? Because we know what those guys are like.
>
> You don't get anywhere by putting your head in the sand. There is a
> reason that people come out with large scale security advisories all
> the time, and it is because application programmers treat the security
> issue like a giant fat joke.
Don't even attempt to go down this road. I don't need your lecturing.
I never said that I was putting my head in the sand. I never said security
doesn't matter. I simply stated that you are on unproven ground.
Apache's architecture/design takes a lot of care to avoid buffer overruns.
Most of the attacks that we see are at the application level -- crap like
CSS or not escaping shell characters or whatever. I'm happy to hear about
problems, but broad unfounded generalizations don't please me.
>...
> To you the security issues may be a giant joke ("who cares about
Don't put words in my mouth.
I do care about security, but I also feel you are overstating the
vulnerability. Yes, we have issues related to code size and the operational
user on the server. Pretty much anything we do will be subject to the "code
size and new code" issue. The user on the server is, of course, a different
matter: one system user shared by users, or per-user system users? I would
stipulate that the one-vs-many is only relevant if you have multiple
repositories with different access policies, or fine-grained access control
within a single repository. But for a single repository with a simple global
"can you write to it?" access control, then a single system user is fine.
When I said I felt you were overstating the problem, it is because I do not
believe we have issues related to the use of HTTP/SSL (iow: the choice of
HTTP/SSL is not inherently a poor choice).
>...
> Steve Bellovin did a great study a while back of CERT
> advisories. There are almost never attacks these days based on bad
> crypto. They're almost always based on buggy code. Less code being run
> means fewer places for there to be bugs.
Agreed. But the code size isn't going to magically shrink. Thus, we simply
need to mitigate the effects of the size of the code base.
ra_pipe is one approach, and would certainly make ssh tunnelling possible.
Another entirely viable alternative is a custom HTTP server whose sole
purpose is to talk to libsvn_(repos|fs). That is: you remove Apache,
mod_dav, and mod_dav_svn, then add this new chunk (which is hopefully
smaller than the former :-). Of course, this could all be coded in C or
somesuch, but I think it would be interesting to see somebody attempt to
write such a beast in Python, using the SVN/Python bindings. (or Perl or
Java or whatever)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Brian Behlendorf <br...@collab.net> writes:
> On 16 Apr 2002, Perry E. Metzger wrote:
> > CVS's overflows don't matter, because until you get past the remote
> > access method they can't be invoked.
>
> Aperture narrowing - got it. So, couldn't you run Apache on the
> repository *only* on the localhost IP address, and mandate that people
> access it only by tunnelling HTTP over an SSH tunnel?
That is what I proposed as a stopgap, but it would help a lot of the
svn client tools understood how to operate in such an environment for
the moment.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: ssh based access?
Posted by Sander Striker <st...@apache.org>.
> From: Brian Behlendorf [mailto:brian@collab.net]
> Sent: 16 April 2002 19:23
> On 16 Apr 2002, Perry E. Metzger wrote:
> > CVS's overflows don't matter, because until you get past the remote
> > access method they can't be invoked.
>
> Aperture narrowing - got it. So, couldn't you run Apache on the
> repository *only* on the localhost IP address, and mandate that people
> access it only by tunnelling HTTP over an SSH tunnel? Seems no more
> awkward than how CVS works today, and doesn't require new code to be
> written...
That combined with berkeley db replication to another box that serves
the public repository.
> Brian
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Brian Behlendorf <br...@collab.net>.
On 16 Apr 2002, Perry E. Metzger wrote:
> CVS's overflows don't matter, because until you get past the remote
> access method they can't be invoked.
Aperture narrowing - got it. So, couldn't you run Apache on the
repository *only* on the localhost IP address, and mandate that people
access it only by tunnelling HTTP over an SSH tunnel? Seems no more
awkward than how CVS works today, and doesn't require new code to be
written...
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Greg Stein <gs...@lyra.org> writes:
> There is nothing to support that Apache has problematic buffer overflows.
Let me get very very blunt right now. You want to get Microsoft's
reputation here? Because we know what those guys are like.
You don't get anywhere by putting your head in the sand. There is a
reason that people come out with large scale security advisories all
the time, and it is because application programmers treat the security
issue like a giant fat joke.
The only exception I can think of is Wietse Venema's work on Postfix
and DJB's work on qmail, and in both instances the programmer in
question came from a security background, not an application
programming background.
There are principles people writing secure software use: least
privilege, aperture narrowing, etc. Those of us who are security
conscious have been worrying about how to do good design for years and
actually understand the problem. If you want to ignore all that and
just say "oh, no one has proven Apache has any more bugs, lets thumb
our nose at those horrid security dweebs", well, you're acting like
Microsoft.
Part of the issue here is that the larger the exposed codebase, the
greater the chances of a problem. It has nothing to do with how macho
a programmer you are, how wonderful your education was, etc. It is
just an obvious principle. More lines of code, more moving parts. More
moving parts, more possible bugs. Marcus Ranum's smap/smapd mail front
ends that were used for whitehouse.gov were a couple of pages of code
each to make them auditable, and I *still* managed to find several
serious security bugs in them.
The larger the codebase talking to the network, the worse the problem
is. If you're only talking to CVS once sshd is through with you, you
just have to worry about sshd vulnerabilities, but the way things are
structured in Subversion, you have a very substantial amount of code
that is a problem.
To you the security issues may be a giant joke ("who cares about
security?") but to people who are operating system writers that use
source control and worry about people inserting trojans straight into
their release base, the repository system is a holy of holies and is
not supposed to be exposed cavalierly.
> Heck, there isn't anything that says that Subversion doesn't have buffer
> overflows. New code. New problems.
>
> And you know... for that matter, has anybody actually audited CVS? Hoo... I
> have seen its network code. Ohmigod. I double-dare you to audit that.
CVS's overflows don't matter, because until you get past the remote
access method they can't be invoked. At worst you're going to have an
insider attack you, and they have other ways to do that (i.e. by
introducing subtle bugs intentionally in otherwise "clean"
commits).
The point of trying to make sure that the remote access method is well
protected is to reduce the size of the vulnerability aperture.
> > not whether the system enforces protection if functioning
> > correctly. The nice thing about sshd is that although it is not
> > perfect, it is at least one narrow interface one has to worry
> > about (and have to run on our systems anyway).
>
> One port for subversion is not a big deal.
Yes it is. It is a whole new bunch of code you have to deal with.
> Your admins will still need the
> sshd port, but you can reduce your logins to *JUST* the admins.
My problem isn't the admin logins. The problem is bugs in sshd. Now I
have to add bugs in a much bigger program (Apache+Subversion) to bugs
in sshd.
> The devs don't need system accounts or access to the sshd port.
They don't need system accounts using rCVS either. At least not login
accounts.
> You're trading one port for another.
Nope.
> >...
> > > or, you can write ra_ssh (or ra_pipe, as people on irc were
> > > talking about, since there's no reason to require this to be used via
> > > ssh, we could use anything we can read and write to).
> >
> > That's more or less the point. We sort of need such a
> > thing. Unfortunately, I'm insufficiently skilled to do so on my own.
>
> That would be interesting, and we'd certainly accept the code, but I don't
> think it will buy you much (for your use case) relative to Subversion over
> SSL.
It would buy quite a lot.
Steve Bellovin did a great study a while back of CERT
advisories. There are almost never attacks these days based on bad
crypto. They're almost always based on buggy code. Less code being run
means fewer places for there to be bugs.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Apr 15, 2002 at 10:44:28PM -0400, Perry E. Metzger wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > > BTW, I'm perfectly happy using naked Apache as the front end for the
> > > anonymous CVS equivalent in SVN.
> >
> > well, in that case you could simple disallow commit's via ra_dav, and
> > make people log in and use ra_local for that.
>
> That won't help. The problem is things like buffer overflows in
> Apache,
There is nothing to support that Apache has problematic buffer overflows.
Most of the problems over the past year or two have been related to poor
processing rather than overflows. We've had a couple overflows on Windows,
but that's about it.
Heck, there isn't anything that says that Subversion doesn't have buffer
overflows. New code. New problems.
And you know... for that matter, has anybody actually audited CVS? Hoo... I
have seen its network code. Ohmigod. I double-dare you to audit that.
> not whether the system enforces protection if functioning
> correctly. The nice thing about sshd is that although it is not
> perfect, it is at least one narrow interface one has to worry
> about (and have to run on our systems anyway).
One port for subversion is not a big deal. Your admins will still need the
sshd port, but you can reduce your logins to *JUST* the admins. The devs
don't need system accounts or access to the sshd port.
You're trading one port for another.
>...
> > or, you can write ra_ssh (or ra_pipe, as people on irc were
> > talking about, since there's no reason to require this to be used via
> > ssh, we could use anything we can read and write to).
>
> That's more or less the point. We sort of need such a
> thing. Unfortunately, I'm insufficiently skilled to do so on my own.
That would be interesting, and we'd certainly accept the code, but I don't
think it will buy you much (for your use case) relative to Subversion over
SSL.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > BTW, I'm perfectly happy using naked Apache as the front end for the
> > anonymous CVS equivalent in SVN.
>
> well, in that case you could simple disallow commit's via ra_dav, and
> make people log in and use ra_local for that.
That won't help. The problem is things like buffer overflows in
Apache, not whether the system enforces protection if functioning
correctly. The nice thing about sshd is that although it is not
perfect, it is at least one narrow interface one has to worry
about (and have to run on our systems anyway).
The basic principle in security is that code you aren't running can't
be used to break you.
> or, you can write ra_ssh (or ra_pipe, as people on irc were
> talking about, since there's no reason to require this to be used via
> ssh, we could use anything we can read and write to).
That's more or less the point. We sort of need such a
thing. Unfortunately, I'm insufficiently skilled to do so on my own.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Apr 15, 2002 at 10:27:17PM -0400, Perry E. Metzger wrote:
> > If the extra modules are stripped out, and you run only the prefork MPM,
> > it's pretty small.
>
> But that's not how we're running Apache for subversion.
for subversion you need the core apache (which can use the prefork
MPM, for simplicity's sake), mod_dav, and mod_dav_svn. is there
anything else?
> > Perhaps the inauditability of the codebase could be
> > reconsidered?
>
> It isn't a question of what we would like. In general, once an app
> gets too large you can't audit it, and Apache is way way bigger than
> you can audit.
>
> > It's not like people aren't running Apache in pretty secure
> > production situations - it's at least secure enough for netbsd's own web
> > site (and openbsd's as well).
>
> Our web site is not considered a secure application. We're fully
> prepared (and expect) for it to be broken into and to have to recover
> it. Our code repository is a very different animal. Breakins there
> could be very bad.
>
> BTW, I'm perfectly happy using naked Apache as the front end for the
> anonymous CVS equivalent in SVN.
well, in that case you could simple disallow commit's via ra_dav, and
make people log in and use ra_local for that. it's clunky but it
works. or, you can write ra_ssh (or ra_pipe, as people on irc were
talking about, since there's no reason to require this to be used via
ssh, we could use anything we can read and write to). it probably
wouldn't be all that hard (one of the ideas someone mentioned was
just committing to xml files and sending them over the pipe to the
other side, which reads them in and applies them). it's not something
that the core developers are going to spend their time working on,
just like they're not working on alternate filesystem backends, but if
someone showed up with working code, i imagine we'd probably be able
to arrange commit access for them to do the work.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Brian Behlendorf <br...@collab.net> writes:
> > The real problem is that Apache is very large. It has to be to do all
> > that it does, but that means that it is hard to secure it because you
> > can't audit all the relevant code. Big is bad in security.
>
> If the extra modules are stripped out, and you run only the prefork MPM,
> it's pretty small.
But that's not how we're running Apache for subversion.
> Perhaps the inauditability of the codebase could be
> reconsidered?
It isn't a question of what we would like. In general, once an app
gets too large you can't audit it, and Apache is way way bigger than
you can audit.
> It's not like people aren't running Apache in pretty secure
> production situations - it's at least secure enough for netbsd's own web
> site (and openbsd's as well).
Our web site is not considered a secure application. We're fully
prepared (and expect) for it to be broken into and to have to recover
it. Our code repository is a very different animal. Breakins there
could be very bad.
BTW, I'm perfectly happy using naked Apache as the front end for the
anonymous CVS equivalent in SVN.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Brian Behlendorf <br...@collab.net>.
On 15 Apr 2002, Perry E. Metzger wrote:
> Brian Behlendorf <br...@collab.net> writes:
> > On 15 Apr 2002, Perry E. Metzger wrote:
> > > Certs are evil. SSH doesn't require them -- it just uses naked public
> > > keys -- which is one reason people like it so much.
> >
> > I'm a bit confused - what's the difference between:
>
> No certificates, just keys. No certs means no CAs. You can add access
> to a machine by editing an authorized_keys file.
Right - and for SSL I can sign my own key, creating my own cert, so I've
got the same in/security but flexibility as SSH - don't I?
> The real problem is that Apache is very large. It has to be to do all
> that it does, but that means that it is hard to secure it because you
> can't audit all the relevant code. Big is bad in security.
If the extra modules are stripped out, and you run only the prefork MPM,
it's pretty small. Perhaps the inauditability of the codebase could be
reconsidered? It's not like people aren't running Apache in pretty secure
production situations - it's at least secure enough for netbsd's own web
site (and openbsd's as well). Maybe we need a DAV module for publicfile?
:)
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Brian Behlendorf <br...@collab.net> writes:
> On 15 Apr 2002, Perry E. Metzger wrote:
> > Certs are evil. SSH doesn't require them -- it just uses naked public
> > keys -- which is one reason people like it so much.
>
> I'm a bit confused - what's the difference between:
No certificates, just keys. No certs means no CAs. You can add access
to a machine by editing an authorized_keys file.
> There is a really good reason to not need SSH anymore - no more need for
> developer login accounts on repository boxes.
We have ways of doing that without eliminating ssh.
The real problem is that Apache is very large. It has to be to do all
that it does, but that means that it is hard to secure it because you
can't audit all the relevant code. Big is bad in security.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Brian Behlendorf <br...@collab.net>.
On 15 Apr 2002, Perry E. Metzger wrote:
> Certs are evil. SSH doesn't require them -- it just uses naked public
> keys -- which is one reason people like it so much.
I'm a bit confused - what's the difference between:
[yez] 5:06pm ~ > ssh jakarta.apache.org
The authenticity of host 'jakarta.apache.org (63.251.56.142)' can't be established.
RSA1 key fingerprint is 25:f9:65:99:be:4a:2d:50:61:24:7c:24:11:ca:6a:b8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'jakarta.apache.org' (RSA1) to the list of known hosts.
brian@jakarta.apache.org's password:
and (not a real example)
[yez] 5:06pm ~ > svn checkout https://jakarta.apache.org/repos/
The authenticity of host 'jakarta.apache.org (63.251.56.142)' can't be established.
Unsigned server cert CN is "*.apache.org"
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently adding unverified server certificate for "*.apache.org"
password:
[etc]
Either your public keys are certified by a CA somewhere, or they aren't.
My understanding of all these issues may be imperfect, though.
There is a really good reason to not need SSH anymore - no more need for
developer login accounts on repository boxes.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > There are known problems with mod_deflate, and there were some
> > problems with
> > apache's ssl stuff until recently, but the only known ssl problem we have
> > right now (that I am aware of), is that we don't do any
> > certificate handling.
>
> the lack of certificate handling was the major problem i was refering
> to.
Certs are evil. SSH doesn't require them -- it just uses naked public
keys -- which is one reason people like it so much.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Apr 15, 2002 at 05:45:31PM -0400, Kevin Pilch-Bisson wrote:
> On Mon, Apr 15, 2002 at 04:30:19PM -0500, Eric Gillespie wrote:
> > Garrett Rooney <ro...@electricjellyfish.net> writes:
> >
> > > effect by using ra_dav over ssl. this is something that's relatively
> > > untested at this point, and there are known problems, but it is
> > > planned for 1.0.
>
> There are known problems with mod_deflate, and there were some problems with
> apache's ssl stuff until recently, but the only known ssl problem we have
> right now (that I am aware of), is that we don't do any certificate handling.
the lack of certificate handling was the major problem i was refering
to.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Apr 15, 2002 at 04:30:19PM -0500, Eric Gillespie wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
> > effect by using ra_dav over ssl. this is something that's relatively
> > untested at this point, and there are known problems, but it is
> > planned for 1.0.
There are known problems with mod_deflate, and there were some problems with
apache's ssl stuff until recently, but the only known ssl problem we have
right now (that I am aware of), is that we don't do any certificate handling.
>
> Eh? I have been using this setup for a few weeks with no problems.
> I allow read-only access over http but only allow write over https.
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: ssh based access?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> effect by using ra_dav over ssl. this is something that's relatively
> untested at this point, and there are known problems, but it is
> planned for 1.0.
Eh? I have been using this setup for a few weeks with no problems.
I allow read-only access over http but only allow write over https.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Greg Stein <gs...@lyra.org> writes:
> I could also maintain that using certs would *simplify* things. No more need
> for system accounts or authorized_keys(2) or setting up CVS_RSH variables or
> any of that.
>
> Six of one, half-dozen of another...
1) I don't need to give people system accounts to allow them to access
CVS via ssh.
2) I need to run sshd anyway. A new program is more code to audit.
3) authorized_keys files are a lot easier to deal with than certs.
> Yes, people have SSH infrastructures set up. And obviating those will
> definitely play a part in using SVN. I would hope that most people will
> establish a private CA for their server and then issue certs for their
> users. The server can then say "only allow people with certs issued by me"
> rather than needing to track every single user and set of keys.
That's a great way to screw yourself. Consider just what happens when
you have to deal with revoking access. You need an online list of
authorized users anyway, at which point you need to track every single
user and tracking keys becomes a trivial extension.
Kohnfelder's undergraduate thesis on certificates has spawned more
evil than one could possibly imagine. The entire idea that you could
do off-line verification based on cert signings and revocation lists
reeks of "ill thought out idea produced to get a degree", and here it
is, over twenty years later, and people still haven't figured it
out. The marketplace has, of course -- look at what happened to Certco
and company -- but folks keep believing the snake oil.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Apr 15, 2002 at 06:47:42PM -0400, Perry E. Metzger wrote:
>...
> Not at all. Among other things, ssh handles authentication with public
> keys very nicely. Doing that with SSL requires certificates and CAs --
> ssh does not. People have ssh infrastructures in place and are not
> necessarily happy about being asked to change everything around. There
> are also firewall issues.
I could also maintain that using certs would *simplify* things. No more need
for system accounts or authorized_keys(2) or setting up CVS_RSH variables or
any of that.
Six of one, half-dozen of another...
Yes, people have SSH infrastructures set up. And obviating those will
definitely play a part in using SVN. I would hope that most people will
establish a private CA for their server and then issue certs for their
users. The server can then say "only allow people with certs issued by me"
rather than needing to track every single user and set of keys.
If people don't want to switch, then they certainly have that choice. At
some point, somebody will get peeved enough with the status quo and will
develop the ra_pipe thingy and people could start tunneling via ssh. But I
will continue to regard that as subpar relative to direct SSL usage via the
HTTP connection.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Peter Mathiasson <pe...@mathiasson.nu>.
On Mon, Apr 15, 2002 at 06:47:42PM -0400, Perry E. Metzger wrote:
> Not at all. Among other things, ssh handles authentication with public
> keys very nicely. Doing that with SSL requires certificates and CAs --
> ssh does not. People have ssh infrastructures in place and are not
> necessarily happy about being asked to change everything around. There
> are also firewall issues.
You should be able to use ssh port forwarding to forward the connection
to the apache server. The apache server itself could be blocked at the
firewall.
That's (almost) how I do it currently, though I'm using stunnel instead
of ssh.
--
Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu
GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Julian Fitzell <ju...@beta4.com> writes:
> > "Much the same effect" might not be sufficient for some people. There
> > are a lot of people who are really used to using ssh.
>
> But all those people are also really used to using CVS. If they're
> going to switch version control systems, surely the secure connection
> mechanism is secondary?
Not at all. Among other things, ssh handles authentication with public
keys very nicely. Doing that with SSL requires certificates and CAs --
ssh does not. People have ssh infrastructures in place and are not
necessarily happy about being asked to change everything around. There
are also firewall issues.
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Julian Fitzell <ju...@beta4.com>.
Perry E. Metzger wrote:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
>
>>>I realize that extracting Apache and such from the process would be
>>>very hard, but would it be difficult to make the standard tools able
>>>to operate through port forwarded ssh connections the way that CVS
>>>happily operates via CVS_RSH=ssh based connections?
>>
>>i don't believe it would be possible (or at least easy) to make
>>ra_local work over ssh, like cvs does, but you could get much the same
>>effect by using ra_dav over ssl.
>
>
> "Much the same effect" might not be sufficient for some people. There
> are a lot of people who are really used to using ssh. With port
> forwarding, though, this should be doable, shouldn't it?
But all those people are also really used to using CVS. If they're
going to switch version control systems, surely the secure connection
mechanism is secondary? I mean CVS_RSH is almost transparent anyway so
people aren't really *used* to using it and SSL should be even more
transparent since it is (or will be) fully supported by the svn client.
This is all from a client perspective, of course. From a server
administrators perspective, enabling SSL is basically just a matter of
passing the appopriate flags to configure and using the right apache
directives. Hardly any harder than configuring apache in the first place.
So, yes, you have to allow the appropriate port through but I don't see
what else people would cling to about CVS_RSH...
Julian
--
julian@beta4.com
Beta4 Productions (http://www.beta4.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by "Perry E. Metzger" <pe...@wasabisystems.com>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> > I realize that extracting Apache and such from the process would be
> > very hard, but would it be difficult to make the standard tools able
> > to operate through port forwarded ssh connections the way that CVS
> > happily operates via CVS_RSH=ssh based connections?
>
> i don't believe it would be possible (or at least easy) to make
> ra_local work over ssh, like cvs does, but you could get much the same
> effect by using ra_dav over ssl.
"Much the same effect" might not be sufficient for some people. There
are a lot of people who are really used to using ssh. With port
forwarding, though, this should be doable, shouldn't it?
--
Perry E. Metzger perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Apr 15, 2002 at 05:02:30PM -0400, Perry E. Metzger wrote:
>
> I've been lurking for quite some time, following subversion
> development with interest. One issue that is big for the folks over in
> NetBSD (my open source project poison of choice) is secure access to
> the source repository. Currently, we do all our access to our CVS
> repository via ssh, and people are very happy with ssh as a transport
> mechanism. There is probably a lot of resistance to opening up other
> holes on the main source repository.
>
> I realize that extracting Apache and such from the process would be
> very hard, but would it be difficult to make the standard tools able
> to operate through port forwarded ssh connections the way that CVS
> happily operates via CVS_RSH=ssh based connections?
i don't believe it would be possible (or at least easy) to make
ra_local work over ssh, like cvs does, but you could get much the same
effect by using ra_dav over ssl. this is something that's relatively
untested at this point, and there are known problems, but it is
planned for 1.0.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
User-based SVN repositories
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Apr 15, 2002 at 06:41:26PM -0400, Kevin Pilch-Bisson wrote:
> Back to the question at hand. If your institution wished to allow peruser svn
> repositories, and so had a LoadModele dav_svn in its httpd.conf file it MIGHT
> be possible to set up a server with a .htaccess file somewhere in your
> ~/public_html directory. I don't know enough about apache configuration to
> say for sure, but maybe gstein does.
I'd say if you can get a Location block added, you should be fine.
I don't *think* .htaccess allows you to define Locations.
Pick a high port number and slap your own httpd on
there. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ssh based access?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Apr 15, 2002 at 05:02:30PM -0400, Perry E. Metzger wrote:
>
> I've been lurking for quite some time, following subversion
> development with interest. One issue that is big for the folks over in
> NetBSD (my open source project poison of choice) is secure access to
> the source repository. Currently, we do all our access to our CVS
> repository via ssh, and people are very happy with ssh as a transport
> mechanism. There is probably a lot of resistance to opening up other
> holes on the main source repository.
>
> I realize that extracting Apache and such from the process would be
> very hard, but would it be difficult to make the standard tools able
> to operate through port forwarded ssh connections the way that CVS
> happily operates via CVS_RSH=ssh based connections?
Back to the question at hand. If your institution wished to allow peruser svn
repositories, and so had a LoadModele dav_svn in its httpd.conf file it MIGHT
be possible to set up a server with a .htaccess file somewhere in your
~/public_html directory. I don't know enough about apache configuration to
say for sure, but maybe gstein does.
>
> --
> Perry E. Metzger perry@wasabisystems.com
> --
> NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~