[cvsnt] cvs login should only work with PSERVER (was: Trouble remotely checking out files from the CVS server)

Glen Starrett glen.starrett at march-hare.com
Tue Mar 25 16:45:25 GMT 2008

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Tony Hoyle wrote:
> :local: is not always admin, but they are always the same as the logged 
> in user (ie. you can't change username).  What it does do is bypass 
> repository registration by using absolute paths instead of aliases - 
> fixed in evs (so local behaves exactly like all other protocols now).

Don't forget that TCVS uses in the "ultra simple" single person 
just-getting-started case, the local protocol to a repository on the 
user's HDD.  It makes sense in that case to use the repository there.

Also, local is used to INIT the repository.

Some issue is that the user can use :local: without the :local: part, 
just implicitly, so they don't know what they are doing.  I can't see an 
easy fix for that though.

Not sure what my point is here...

> On Unix we could check/set the permissions of the cvspass file better 
> (should be rw to owner only and enforced as such) but it's no less 
> secure than ssh+certificates given that caveat.

Passwords embedded in the CVSROOT is far worse than the .cvspass file...

I agree that the .cvspass should be set up owner only.  On Win, the user 
reg is private anyway (and passwords scrambled a bit at that).  In 
either case it would require a compromised machine to obtain the passwords.

IMHO I don't think that the login should be restricted to any particular 

Now, if you're thinking about implementing something like a policy file 
for the workstations in a corporate environment to restrict behavior, I 
could certainly support that (provided we had a customer who needed it).

> The threat model is based on the idea that the client is secure but bad 
> guys can sniff the link.  If you define a threat model where the client 
> is compromised we have to design a whole new system of login.  cvsagent 
> goes some way to handle it but doesn't really address that scenario 
> directly (but even that needs timeouts to be truly useful - it should 
> ditch the stored password after 5 minutes or so to avoid the 'hacked 
> during lunch break' scenario).

Ticking the "lock workstation" on the screen saver options would be more 
secure.  "Hacking during the lunch break" opens up many more ways of 
obtaining the passwords than cvsagent could possibly protect against.

>> The question is - how much do we inconvenience the experienced people
>> for the sake of the new users/people who jump to (incorrect)
>> conclusions?
> We need to push people more towards sspi and ssh, and make pserver a 
> last resort option somehow - but I haven't thought of a way that'll do 
> that without creating huge amounts of support requests.

sserver too!

> It's also possible there's a case to disable support for non-system 
> users.  This would eliminate the CVSROOT/passwd file which is a source 
> of some confusion.  And make ACLMODE=Normal the default sometime (which 
> IMO is why people get the idea that ACLs don't work, because by default 
> they work in an opposite fashion to system ACLs).

Hmmmm.  A config option that more clearly sets the preference would be 
good, e.g. USER_DB = system_only | passwd_only | both, defaulting to 

> Whether this belongs in a stable tree though is debatable.

Maybe at the next major rev, but certainly not in the 2.5.03 or 2.5.04 


Glen Starrett
Technical Account Manager, North America
March Hare Software, LLC


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook