LINCVS is a good client cvs?
which differencein between cervisia and LINCVS?
___
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com
Hello all,
Unfortunatelly one of our CVS-servers crashed. We lost a lot of data that
was stored in the CVS-tree. We tried to restore as much data as possible.
However, now we have the situation that some clients are out of sync with
the server, and when they perform a cvs-update they loose al
On Tue, Mar 26, 2002 at 02:42:57PM -0500, Dan Langille wrote:
> On Tue, 26 Mar 2002 08:45:40 -0800, Rob Helmer <[EMAIL PROTECTED]> wrote:
>
> > Hi Dan,
> >
> > What kind of interface are you looking for?
>
> A programmatic one. At present, I use cvsweb (e.g.
> http://www.freebsd.org/cgi/cvsweb
On Tue, 26 Mar 2002 13:03:52 -0800, Rob Helmer <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 26, 2002 at 02:42:57PM -0500, Dan Langille wrote:
> > On Tue, 26 Mar 2002 08:45:40 -0800, Rob Helmer <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Dan,
> > >
> > > What kind of interface are you looking for?
> >
Dan Langille writes:
>
> Yes, I don't care what the input is, but I'd like XML output. Command line
> or http is fine by me.
If you talk to a CVS server using client/server mode, much of the output
is "tagged text", which is similar to XML in concept if not syntax.
-Larry Jones
It's like SOME
--
Oliver Fischer - mailto:[EMAIL PROTECTED]
> Does anyone know of any implementations of the CVS client part of
> the client/server protocol in Perl, Python, C ( besides the CVS binary :)
> Ruby, etc. ? Java is nice, but since the core application is not
> running in a VM and it's mostly state
Hi Oliver,
Yes, a libCVS would be nice. A google search on "libcvs" turns
up some interesting results, there might be a nice starting point
somewhere.
I am seriously considering implementing an abstracted version
of the client/server protocol in Perl, I was sent a perl module that
already does
Hi Rob,
>
> Yes, a libCVS would be nice. A google search on "libcvs" turns
> up some interesting results, there might be a nice starting point
> somewhere.
>
> I am seriously considering implementing an abstracted version
> of the client/server protocol in Perl, I was sent a perl module that
> alr
The advantage of pserver is the ability to map one or more users to the same
system user on the server. The disadvantages are the need to "cvs login" and
the lack of security.
The advantages of client/server CVS using SSH is the easier usage (ie no "cvs
login") and the better security. The disa
Noel L Yap writes:
>
> Client/server CVS can easily map users if the client sent the remote user's name
> over to the server to use in its logs. Therefore, I propose that such an
> enhancement should be done (I'll even do the work if my schedule doesn't get
> overloaded).
The main problem I see
[ On Thursday, June 8, 2000 at 11:26:26 (-0400), Noel L Yap wrote: ]
> Subject: Proposal: have client CVS send remote username to server CVS
>
> The advantages of client/server CVS using SSH is the easier usage (ie no "cvs
> login") and the better security. The disadvantag
[EMAIL PROTECTED] on 06/08/2000 12:13:35 PM
>Noel L Yap writes:
>>
>> Client/server CVS can easily map users if the client sent the remote user's
name
>> over to the server to use in its logs. Therefore, I propose that such an
>> enhancement should be done (I'll even do the work if my schedul
[ On Thursday, June 8, 2000 at 12:13:35 (-0400), Larry Jones wrote: ]
> Subject: Re: Proposal: have client CVS send remote username to server CVS
>
> The main problem I see with this is that you lose all accountability --
> the client can claim to be anyone and the server will
[EMAIL PROTECTED] on 06/08/2000 04:05:49 PM
>[ On Thursday, June 8, 2000 at 11:26:26 (-0400), Noel L Yap wrote: ]
>> Subject: Proposal: have client CVS send remote username to server CVS
>>
>> The advantages of client/server CVS using SSH is the easier usage (ie no &q
[ On Thursday, June 8, 2000 at 17:27:05 (-0400), Noel L Yap wrote: ]
> Subject: Re: Proposal: have client CVS send remote username to server CVS
>
> My point was that, using this method, CVS will treat each of the many users as
> the one system user. Pserver doesn't do that.
[EMAIL PROTECTED] on 06/08/2000 10:58:20 PM
>[ On Thursday, June 8, 2000 at 17:27:05 (-0400), Noel L Yap wrote: ]
>> Subject: Re: Proposal: have client CVS send remote username to server CVS
>>
>> My point was that, using this method, CVS will treat each of the many users
Greg A. Woods writes:
>
> Many (most?) systems foolishly allow a process to regain its
> former privileges if great care is not taken, and on some I understand
> it is not even possible to prevent such re-instatement, thereby leaving
> CVS open to exploit throughout its entire body of un-audited
bject: Re: Proposal: have client CVS send remote username to server CVS
Greg A. Woods writes:
>
> Many (most?) systems foolishly allow a process to regain its
> former privileges if great care is not taken, and on some I understand
> it is not even possible to prevent such re-instat
> "GAW" == Greg A Woods <[EMAIL PROTECTED]> writes:
GAW> Ah yes, but cvs-pserver can only map to multiple different system
GAW> users if you run it as root, which no matter what anyone says is
GAW> extremely risky.
That is why
tyranny:~/cvs/src$ wc -l cvs-pserver.c
184 cvs-pserver.c
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> Pserver authentication is extremely bogus. Better authentication can
NLY> be done using SSH (if people really cared about it). If people didn't
NLY> care too much about it, they'd rely on client login as enough
NLY> authentication.
Pse
[EMAIL PROTECTED] on 2000.06.10 19:23:23
>Pserver authentication is completely adequate :) It just runs over the
>insecure channel and has unclean mixage of various subsystems in its
>current, non-nserver form.
No, it's not, it's extremely prone to replay attacks and stolen .cvspass files.
F
[ On Friday, June 9, 2000 at 10:46:43 (-0400), Larry Jones wrote: ]
> Subject: Re: Proposal: have client CVS send remote username to server CVS
>
> Greg A. Woods writes:
> >
> > Many (most?) systems foolishly allow a process to regain its
> > former privileges if grea
09:55:55 AM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Noel L Yap)
Subject: Re: Proposal: have client CVS send remote username to server CVS
[EMAIL PROTECTED] on 2000.06.10 19:23:23
>Pserver authentication is completely adequate :) It just runs over the
>insecure channel a
ED] on 06/16/2000 03:31:07 PM
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Proposal: have client CVS send remote username to server CVS
OK, I've decided to make such a patch. I'm not sure how to go about doing it,
though. I can't find wh
x27;m
> /really/ gonna do it ;-)
>
> Noel
>
> [EMAIL PROTECTED] on 06/16/2000 03:31:07 PM
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Proposal: have client CVS send remote username to server CVS
>
> OK, I've decided
000.06.21 11:43:01
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Proposal: have client CVS send remote username to server CVS
So, if I understand you correctly, you're proposing to map a single user on the
server (connecting via SSH, RSH, or whatever) to m
t by authentication software (eg
> SSH). But since I don't want to risk breaking SSH, I don't want to make the
> change in it.
>
> Noel
>
> [EMAIL PROTECTED] on 2000.06.21 11:43:01
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>
[EMAIL PROTECTED] on 2000.07.17 15:22:05
>Is there some reason I shouldn't view this as a security hole? Without
>debating
>the lack of real security in pserver mode already, an open source client >such
as
>CVS's is so easily hackable that a sensitive system becomes even more
>insecure.
>User
[EMAIL PROTECTED] on 2000.07.17 17:29:20
>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>NLY> This is one of the reasons why I decided to hack CVS instead of
>NLY> SSH. I figured a security hole in a product not meant to be
>NLY> secure was better than one in a product that was mean
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> This would only be possible if User X already had permissions
NLY> into the repository. Also, the way it stands now, CVS doesn't
NLY> have any information as to who really did the operation -- all it
NLY> records is the username as it e
> "DRP" == Derek R Price <[EMAIL PROTECTED]> writes:
I'm somewhat sleepy and my language will act accordingly :)
DRP> Is there some reason I shouldn't view this as a security hole?
DRP> Without debating the lack of real security in pserver mode
DRP> already, an open source client such as CVS
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> This is one of the reasons why I decided to hack CVS instead of
NLY> SSH. I figured a security hole in a product not meant to be
NLY> secure was better than one in a product that was meant to be
NLY> secure (even though the insecurity re
Noel L Yap wrote:
> How can an SSH server know that the SSH client hasn't been compromised and is
> sending a spoofed username?
By requiring the client to send a password known to the server or to encrypt its
connection/keys/whatever it is using the proper private key (in other words, a
private
[EMAIL PROTECTED] on 2000.07.18 14:05:01
>> How can an SSH server know that the SSH client hasn't been compromised >and
is
>> sending a spoofed username?
>
>By requiring the client to send a password known to the server or to >encrypt
its
>connection/keys/whatever it is using the proper privat
[EMAIL PROTECTED] on 2000.07.17 17:11:16
>Hm. Do you REALLY speak of scheme where:
>
>- client says 'ssh [EMAIL PROTECTED]', and says real password
>for 'cvsuser' (that's system account on server machine);
>
>- server says ok, welcome;
>
>- client says, 'oh, wait, could you please forget abou
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>> Especially while there _is_ the way to make sure that advertiser
>> really knows what he says he does.
NLY> How can an SSH server know that the SSH client hasn't been
NLY> compromised and is sending a spoofed username?
Authenticate it, o
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>> ??? You surely _have_ to demand second password, and to
>> authenticate against separate list of cvs users and I think that I
>> look stupidly trying to explain evident.
NLY> A second password isn't that much more secure than two
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>> connection/keys/whatever it is using the proper private key (in
>> other >words, a private key with a corresponding & appropriate
>> public key already known to >the server).
NLY> No, this doesn't guarantee it. For example, if the OpenSSH
[EMAIL PROTECTED] on 2000.07.18 15:36:53
>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>>> connection/keys/whatever it is using the proper private key (in
>>> other >words, a private key with a corresponding & appropriate
>>> public key already known to >the server).
>
>NLY> No, thi
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>> If OpenSSH client will always send wrong info (I mean username and
>> password here), then cvs-server will never authenticate it ;)
NLY> I think we're arguing different points here. My point is that
NLY> the OpenSSH client can send over
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> Yes, exactly. This is what happens now with pserver. Ideally,
NLY> CVS should use an environment variable REMOTE_USER that's set by
NLY> authentication software (eg SSH). But since I don't want to risk
NLY> breaking SSH, I don't want t
how you can call "valid" u/p that do not belong to
>the client. Who thinks of them as valid?
>From the top. My proposal was to have client CVS send the client username
over to the server for its use. Server CVS will still run as the server
user but will record the client username w
ED] on 2000.07.19 16:15:51
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Proposal: have client CVS send remote username to server CVS
>>>>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> Yes, exactly. This is
I think I've figured out a general solution to the problem.
When the user uses client CVS, it uses SSH to authenticate to a middle server,
then sends CVS protocol commands to it.
The middle server SSH's over to the CVS server, sets REMOTE_USER (or CVSUSER)
and forwards the CVS protoco
Noel L Yap wrote:
> 1. You wouldn't allow many-to-one user mappings at all.
As I understand it, many to one mappings in CVS already keep track (in log
messages, etc.) of the original user that logged in. My system may remain
vulnerable to many kinds of attacks, but I have more information avail
Noel L Yap wrote:
> [EMAIL PROTECTED] on 2000.07.18 14:05:01
> >> How can an SSH server know that the SSH client hasn't been compromised >and
> is
> >> sending a spoofed username?
> >
> >By requiring the client to send a password known to the server or to >encrypt
> its
> >connection/keys/whateve
Alexey Mahotkin wrote:
> > "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
> >> If OpenSSH client will always send wrong info (I mean username and
> >> password here), then cvs-server will never authenticate it ;)
>
> NLY> I think we're arguing different points here. My point is that
> NL
[EMAIL PROTECTED] on 2000.07.21 14:15:40
>> [EMAIL PROTECTED] on 2000.07.18 14:05:01
>> >> How can an SSH server know that the SSH client hasn't been compromised
>and
>> is
>> >> sending a spoofed username?
>> >
>> >By requiring the client to send a password known to the server or to
>encrypt
[EMAIL PROTECTED] on 2000.07.21 14:12:54
>> 1. You wouldn't allow many-to-one user mappings at all.
>
>As I understand it, many to one mappings in CVS already keep track (in log
>messages, etc.) of the original user that logged in. My system may remain
>vulnerable to many kinds of attacks, bu
[EMAIL PROTECTED] on 2000.07.21 14:38:26
>I think Noel is referring still to the SSH client authenticating as a
>single UNIX user but then attempting to map to many CVS users.
I'm referring to many users SSH'ing into one user. If you had a one-to-one
mapping, there wouldn't be a problem (sin
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> over to the server for its use. Server CVS will still run as the
NLY> server user but will record the client username within its logs.
NLY> For example, if I am nyap on the client and I set
NLY> CVSROOT=cvsuser@cvsserver:/home/cvsgroup/.
> "DRP" == Derek R Price <[EMAIL PROTECTED]> writes:
DRP> pserver, the originally authenticated user name is what you will
DRP> see in the logs, though you can map to a secondary user which the
DRP> CVS server will run under - convenient for file permissions,
DRP> though I would usually rathe
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>> but I'm fairly certain that even the people I trust implicitly can
>> ocassionally leave their password written down in the wrong place.
NLY> And do you also make sure that their .cvspass files can't be read
NLY> (either off the filesystem
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> How do you guarantee that CVSUSER is set properly (ie can't be
NLY> spoofed)?
Because it is verified against CVSROOT/cvspasswd file (it is extended
and improved analog of CVSROOT/passwd from stock CVS). Each cvs user
has an entry there
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
NLY> REMOTE_USER cannot be set securely by either SSH or CVS.
If that would be the case we would all be 0\/\/NeD long ago.
--alexm
> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>> I haven't studied your nserver model yet, but the conventional CVS
>> has no 2-phase authentication methods available.
NLY> IMHO, it shouldn't have any authentication. Authentication
NLY> should be left to secure software.
Please, take a
[EMAIL PROTECTED] on 2000.07.22 09:24:43
>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>>> but I'm fairly certain that even the people I trust implicitly can
>>> ocassionally leave their password written down in the wrong place.
>
>NLY> And do you also make sure that their .cvspass
[EMAIL PROTECTED] on 2000.07.22 09:23:22
>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>NLY> REMOTE_USER cannot be set securely by either SSH or CVS.
>
>If that would be the case we would all be 0\/\/NeD long ago.
What's 0\/\/NeD?
Noel
This communication is for informational pu
[EMAIL PROTECTED] on 2000.07.22 09:07:59
>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>NLY> over to the server for its use. Server CVS will still run as the
>NLY> server user but will record the client username within its logs.
>NLY> For example, if I am nyap on the client and I s
[EMAIL PROTECTED] on 2000.07.22 09:15:17
>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>NLY> How do you guarantee that CVSUSER is set properly (ie can't be
>NLY> spoofed)?
>
>Because it is verified against CVSROOT/cvspasswd file (it is extended
>and improved analog of CVSROOT/passwd
[EMAIL PROTECTED] on 2000.07.22 09:20:59
>> "DRP" == Derek R Price <[EMAIL PROTECTED]> writes:
>
>DRP> pserver, the originally authenticated user name is what you will
>DRP> see in the logs, though you can map to a secondary user which the
>DRP> CVS server will run under - convenient for f
[EMAIL PROTECTED] on 2000.07.22 10:07:10
>> "NLY" == Noel L Yap <[EMAIL PROTECTED]> writes:
>
>>> I haven't studied your nserver model yet, but the conventional CVS
>>> has no 2-phase authentication methods available.
>
>NLY> IMHO, it shouldn't have any authentication. Authentication
>NLY
Noel L Yap wrote:
> Yes, mapping several users to one system user (while CVS remembers the real
> username) is what I'm trying to achieve. I guess my proposal pushes the
> authentication responsiblity onto the client machine.
You proposal seems to push some of the chore of authentication to the
Noel L Yap wrote:
> Yes, I still think authentication stuff should be left out of CVS. Instead
> something pluggable should exist.
>
> For example, if instead of the password authentication protocol you suggest, I
> wanted to use SRP (so that the password isn't sent over the wire at all) or SSH,
Noel L Yap wrote:
> The point is that, when using pserver, CVS remembers you as the name within the
> passwd file (which usually matches the client username) even though it may run
> as some other user. Under client/server CVS, it'll remember you as the server
> username. This proposal and patc
[EMAIL PROTECTED] on 2000.07.24 17:16:40
>> Yes, mapping several users to one system user (while CVS remembers the real
>> username) is what I'm trying to achieve. I guess my proposal pushes the
>> authentication responsiblity onto the client machine.
>
>You proposal seems to push some of the
[EMAIL PROTECTED] on 2000.07.24 17:33:23
>> Yes, I still think authentication stuff should be left out of CVS. Instead
>> something pluggable should exist.
>>
>> For example, if instead of the password authentication protocol you suggest,
I
>> wanted to use SRP (so that the password isn't sen
Noel L Yap wrote:
> There might've been some misunderstanding here. After rereading my post, I
> noticed I wasn't so clear about my description of SRP. SRP does password
> authentication without ever sending the password (either in the clear or
> encrypted) over the wire. Instead, it uses AKE
Noel L Yap wrote:
> And hence my point that developers must be trusted. In fact, this is a basic
> philosophy of CVS.
I trust myself and yet I don't sleep well if I'm not making nightly tape backups.
Also, if one of my developer's passwords is compromised, we'll say without his
knowledge for p
[EMAIL PROTECTED] on 2000.07.24 18:58:03
>Have you considered using SSH, port forwarding, and pserver? I think you could
>wrap CVS in something like the following:
>
>#!/bin/sh
>ssh -L30100:localhost:cvspserver remotehost.net
>CVSPORT=30100 cvs -d:pserver:$USER@localhost:/cvsroot
[EMAIL PROTECTED] on 2000.07.25 00:29:08
>> And hence my point that developers must be trusted. In fact, this is a basic
>> philosophy of CVS.
>
>I trust myself and yet I don't sleep well if I'm not making nightly tape
backups.
Backups protect you from disasters other than hacking developers
[EMAIL PROTECTED] on 2000.07.25 00:14:41
>> If this wasn't a source of misunderstand, can you explain your point "I would
>> not like to see such an insecure mechanism become part of the main CVS
>> executable...".
>
>Did you or did you not specify that you wish authentication on the server si
Hi,
I have a problem regarding the setup of
ssh tunneling for cvs ("Again!", might some people shout...).
I have to use this solution since our developers are using
a commercial solution with a cvs interface. Unfortunately this
interface supports only :server: and :pserver: methods,
and the rs
Eric Sommerlade wrote:
> I was searching for this CVSPORT variable desperately, yet
> unsuccessful.
> Does it exist (in cvs >=1.10.8), or is there another way to
> specify the client side port number to connect to?
My apologies. Someone else posted something similar, I remembered
reading about
74 matches
Mail list logo
