CVS woes: .cvspass

[Chiaki]

The file revision control system, CVS,
stores often used server's password in
users .cvspass file. (When we use pserver mode to set up a
central repository and access it from remote workstations,
that is.)

The password is "lightly scramblled" for accidental disclosure
to casual reader, but descrambling it is rather easy.

Several days ago, I needed to recall the CVS password, but
I found myself not recalling it since I relied on the automatic
login by using the password in .cvspass too much.
So I used the easy descrambling from my own .cvspass file
under my home directory to recover the password.
(The same password is used to crypt
a PDF file by my fellow worker. He remebers the password. A good thing.)

However, as I recover the password from .cvspass, I found
one troubling situation.
When I tried to find how to descramble the lightly
scrambled password in .cvspass using Google
(and this was before I check the CVS source file which
I eventually did and solved my ordeal.)
I found MANY HITs of people's .cvspass files on the web.
Theyt contain lightly scramblled passwords.

Granted that many of these files under user home directories
visible on the web
must be the password to be used by anonymous server or
publicly usable CVS server, but I doubt if ALL of them
are the result of such benign neglect.

Is it likely that some .cvspass visible on the web using
Google search may contain some valuable password to
a reasonably important server? I think the chances are high. UGH.

This probably has been a common knowledge among the blackhat community.

The weak password problem has been discussed often (see the
relevant two hits from the .cvspass search in google.), but
having the file published in web and being reported in Google
is something I didn't expect to see happening.
No difficult efforts need to be spent to collect .cvspass files.

URL: Discussions about cvspass. Found in the first page of
google search for ".cvspass".

http://www.derkeiler.com/Mailing-Lists/securityfocus/pen-test/2003-05/0073.html

http://www.contactor.se/~dast/svn/archive-2003-01/0851.shtml


--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

[Valdis.Kletnieks@vt.edu]

--==_Exmh_-1914559229P
Content-Type: text/plain; charset=us-ascii

On Tue, 27 Jul 2004 03:00:52 +0900, Chiaki <ishikawa@yk.rim.or.jp> said:

> Granted that many of these files under user home directories
> visible on the web
> must be the password to be used by anonymous server or
> publicly usable CVS server, but I doubt if ALL of them
> are the result of such benign neglect.

If a user's home directory is visible via a web browser, the .cvspass
is probably not the biggest problem....

--==_Exmh_-1914559229P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFBBpzFcC3lWbTT17ARAvHFAJ9dcDz3OG/g2Urk/+bIdT5AJAOtswCg0epY
laObpTWaF6jfGYt9IOJ+dS8=
=Cuex
-----END PGP SIGNATURE-----

--==_Exmh_-1914559229P--

[Greg A. Woods]

[ On Tuesday, July 27, 2004 at 03:00:52 (+0900), Chiaki wrote: ]
> Subject: CVS woes: .cvspass
>
> The file revision control system, CVS,
> stores often used server's password in
> users .cvspass file. (When we use pserver mode to set up a
> central repository and access it from remote workstations,
> that is.)

Anyone using the CVS pserver mechanism for anything other than totally
anonymous access gets only what they deserve.

If you want to keep your CVS repository secure then don't try to use CVS
as a security tool -- it wasn't designed for it, and it cannot be
"fixed" either (it's not a bug -- CVS is a version control tool, not a
security tool and CVS is designed _only_ to be executed by the unique
user performing operations on repository).

Use SSH or some other secure remote job execution tool to create a
secure connection for CVS to work with.

--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>

[Andreas Beck]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 27 Jul 2004 03:00:52 +0900, Chiaki <ishikawa@yk.rim.or.jp> said:
> > Granted that many of these files under user home directories
> > visible on the web
> > must be the password to be used by anonymous server or
> > publicly usable CVS server, but I doubt if ALL of them
> > are the result of such benign neglect.
> If a user's home directory is visible via a web browser, the .cvspass
> is probably not the biggest problem....

It looks like quite some people check the .cvspass into cvs itself. When
doing a quick check of yesterdays advisory, most hits were from
cvs-viewing utilities.

Maybe they just don't know what .cvspass is for and think "oh, there's a
..cvs in there, I'd better check it in". Of course this doesn't explain
why they move it into the respective directory in the first place, as
it usually resides in $HOME, while CVS sources usually create their own
directory on checkout.

Also note, that for exploitation you do not even need to reverse the
password. You just add the .cvspass entries to your own .cvspass and
get access.


Kind regards,

Andreas Beck

--
Andreas Beck
http://www.bedatec.de/

[Delian Krustev]

On Tuesday 27 July 2004 23:20, Greg A. Woods wrote:
> Anyone using the CVS pserver mechanism for anything other than totally
> anonymous access gets only what they deserve.

brr, do not forget that the security might be guaranteed on different
layers. E.g. ipsec secures the insecure protocols(the ones that transfer
data in plain text or with weak encryption), such as telnet or cvs
with pserver.

[Greg A. Woods]

[ On Thursday, August 5, 2004 at 12:52:10 (+0300), Delian Krustev wrote: ]
> Subject: Re: CVS woes: .cvspass
>
> On Wednesday 04 August 2004 23:35, Greg A. Woods wrote:
> > Nope, sorry, but that's just not possible, at least not with CVS pserver.
>
> What's not possible ? Using IPSEC ?!

It's not possible to "secure" CVSpserver using IPsec. Period.

I.e. it's just not logically possible, using CVSpserver, do do what you
said could be done. To do so violates the fundamental security model of
CVS and the Unix(like) systems it runs upon.

IPsec can only secure the inter-host network links and thus make it
possible to securely use CVS via remote job protocols such as RSH (which
use host-level security techniques and assume their virtual circuits are
already secure) instead of requriring SSH. IPsec does not operate at
the user level and even if it did you'd still require unique system
identities for every individual human user.

Note that even pushing the IPsec implementation away from the host
kernel and onto a gateway router implies blindly accepting many more
assumptions about the security of the local area network.


> I'm not sure what You mean by "human user".

The whole point of security, i.e. authentication, authorisation, and
accountability, is to relate all internal system activity back to real,
verified, authorised, individual human users.

I use the common phrase "human user" to differentiate the real people
who use a system from the identities they assume, or rather are given,
inside of a computing system environment.

It is fundamental that each system account be used by one and only one
unique human user. Without this condition accountability is impossible
(at least for the users of that shared user-ID) unless it's provided by
some external means (e.g. a security guard at the door of the
Tempest-level room where the computer is located who is instructed to
securely record every access to the computer, and who is capable of
securely performing this duty).

It is also fundamental that every system activity performed by a human
user be performed using a unique-per-human _system_ level identity. If
you do not meet this condition then you are violating the fundamental
security model of the system and all bets are off, all warrantees null
and void, etc.

(note that a single human individual can assume multiple system
identities without compromising accountability -- it's only not secure
to have multiple humans assume a single system identity)


> The users in cvs doesn't have
> to be mapped to system users(CVSROOT/passwd).

That's true at some level, but it's a (common) fallacy as well, and it
begins with a faulty foundation from the get go.

CVS only works securely with real, individual, unique-per-human, system
level user-IDs, and where the CVS processes on the server run using the
system identity of the human user they are acting on behalf of.

If your human users are not using unique internal _system_ level
representations of their unique identities then you have no secure
ground to stand on in the first place.

I.e. the mere concept of using cvspserver (and thus CVSROOT/passwd) is a
non-starter if you are worried in any way about the security of your CVS
repository. CVS users (the real humans using CVS) _MUST_ use unique
system user identities in order that you can even begin to consider the
state of the security of your CVS repository. CVSROOT/passwd entries do
not equate to real system identities even if they map identically to
real system identities because use of CVSROOT/passwd in that way implies
running CVS as root and that's not secure in any way whatsoever
(i.e. not by design and not by implementation).

There are no if's, and's, or but's about it -- this is really _really_
fundamental computer security basics. CVS security, by design and by
the way CVS is implemented, relies _entirely_ on system security and
unique system level identities. Running CVS as root, or having all CVS
users access one system account by way of CVSpserver with CVS running as
that one system account, leaves CVS without any secure accountability
whatsoever, while at the same time providing numerous holes big enough
for CVS users to drive big Mac trucks through at each other, if not
indeed also through to root level compromises in the former scenario.

Like I'm sure I've said many times before, CVSpserver should never ever
be used for anything but totally anonymous (and presumably read-only)
access to a CVS repository, and hopefully that pserver accessible
repostitory is also only an untrusted copy of the real CVS repository
that the developers have write access to, and hopefully the system it
runs on has the sole purpose of providing anonymous pserver access, or
at least the identity it runs under is totally untrusted within that
system.

Let me say it again the other way around for the benefit of clarity:

Only ever use CVSpserver for totally _anonymous_ access.


> There's a site outhere. It's sf.net . They demonstrate, with the number
> of projects being hosted there (with pserver access), You're not right
> again.

They demonstrate nothing of the sort (at least not with their CVSpserver
offering).

In the scenario you speak of sf.net has no real requirement for
accountability -- their offerning using CVSpserver is effectively the
same as providing anonymous access. Sf.net doesn't care who the real
humans are in this case -- they simply do their best (which isn't always
perfect) to keep whole projects from interfering with each other. (and
their none-too-rare failings have been directly attributable to this
particular mis-use of CVS -- i.e. their "lame" attempt to use CVS as
part of their security infrastructure)

Meanwhile, IIUC, sf.net does also offer secure SSH access to systems
hosting CVS repositories and they use true system identities for eash
SSH account, and presumably with this offering there's normally one (or
maybe more) unique system accounts for every real human using this
service, though of course the responsibility of verifying the uniqueness
of system identities will be on the shoulders of the CVS project admins,
and perhaps not on sf.net themselves. I.e. if two human users share an
account there's only their peers within their project to account to and
sf.net only attempts to provide the minimum level of _system_ security
necessary for their users to police each other.

Either way sf.net is a big enough target that if they have not
implemented their services securely and within the security model
provided by their underlying systems then we'll likely hear about the
result here in this forum.

> On the other side, people's stupidity is endless. I won't be surprised
> to see private keys posted in a public forum. This, ofcourse, could
> be nothing but a reason for admiration.

No disagreement there! :-)

--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>

[Delian Krustev]

On Wednesday 04 August 2004 23:35, Greg A. Woods wrote:
> Nope, sorry, but that's just not possible, at least not with CVS pserve=
r.

What's not possible ? Using IPSEC ?!

> The unix security model, within which CVS is designed and implemented t=
o
> work, _requires_ unique user-IDs for each and every unique human user.
>
> This is in fact a basic, fundamental, requirement of all systems of thi=
s
> type.
>

I'm not sure what You mean by "human user". The users in cvs doesn't have
to be mapped to system users(CVSROOT/passwd).

> CVS is not, and cannot be, a security tool so running it as root and
> pretending to have it do all your authentication and authorisation flie=
s
> directly in the face of the underlying system security model and leaves
> you with no real and verifiable accountability whatsoever, and it also
> leaves you open to the possibility of yet another vulnerability vector
> in the form of the unaudited CVS code base. Remember that the vast
> majority of all security incidents originate internally to the
> organisations they affect.

You're right CVS is not a security tool. It's a version control system.
In fact, what You are talking about ? Do You remember what the subject
of the post You're replying to was ?

[snip]

> If you think your network is secure enough courtesy other mechanisms
> then you can use RSH instead of SSH, but DO NOT try to use cvspserver
> for anything but totally anonymous access.

There's a site outhere. It's sf.net . They demonstrate, with the number
of projects being hosted there (with pserver access), You're not right
again.

The cvs server doesn't have to be run as root. IMHO it's pretty bad
idea to run it as root. Furthermore cvs provides several hooks, which
could be utilized if you need control at certain points and over
certain operations. E.g. commiters could be controlled by module and
branch.

About the password scrambling. It's well documented why it's like
that. The scrambling algorithm is also described. And it's all there.
In the manual.=20
S.O. said that fake security is worse than no security. Password=20
encryption in .cvspass should be considered "no security".


On the other side, people's stupidity is endless. I won't be surprised
to see private keys posted in a public forum. This, ofcourse, could
be nothing but a reason for admiration.

[Andy Dustman]

On Thu, 5 Aug 2004 12:52:10 +0300, Delian Krustev <krustev@krustev.net> wrote:
> On Wednesday 04 August 2004 23:35, Greg A. Woods wrote:

> > If you think your network is secure enough courtesy other mechanisms
> > then you can use RSH instead of SSH, but DO NOT try to use cvspserver
> > for anything but totally anonymous access.
>
> There's a site outhere. It's sf.net . They demonstrate, with the number
> of projects being hosted there (with pserver access), You're not right
> again.

SourceForge only allows anonymous CVS access through pserver.
Read-write access is through SSH only.

[Delian Krustev]

Your mails are getting longer and longer. Please try saying more
in less words next time. Thank You.

On Thursday 05 August 2004 23:11, Greg A. Woods wrote:
> It's not possible to "secure" CVSpserver using IPsec. Period.
>
> I.e. it's just not logically possible, using CVSpserver, do do what you
> said could be done. To do so violates the fundamental security model o=
f
> CVS and the Unix(like) systems it runs upon.

There's nothing like "fundamental security model". Not in unix/linux, nor
in CVS. I suppose You're talking about UID/GID based security.

I'll repeat myself. Security could be guaranteed on different layers.
In the software case - operating system, application, components, etc ..

Please tell me what, from the things I've said, is not "logically possibl=
e"
to be done and I'll provide an example.

> IPsec can only secure the inter-host network links and thus make it
> possible to securely use CVS via remote job protocols such as RSH (whic=
h
> use host-level security techniques and assume their virtual circuits ar=
e
> already secure) instead of requriring SSH. IPsec does not operate at
> the user level and even if it did ..

<bold>
>.. you'd still require unique system
> identities for every individual human user.
</bold>

The local access to the repository requires each commiter to have direct
r/w access to each of the directories inside the repository. This gives
him the power to compromise it in anyway he likes. The commits performed
by locally executed cvs command are performed by creating/renaming/unlink=
ing
files.

> Note that even pushing the IPsec implementation away from the host
> kernel and onto a gateway router implies blindly accepting many more
> assumptions about the security of the local area network.

The keyword here is opportunistic encryption. The nodes of trust
will be the server, the client and the client's DNS provider. The third
one could be eliminated. No lan security is involved in that scenario.

> The whole point of security, i.e. authentication, authorisation, and
> accountability, is to relate all internal system activity back to real,
> verified, authorised, individual human users.
>
> I use the common phrase "human user" to differentiate the real people
> who use a system from the identities they assume, or rather are given,
> inside of a computing system environment.
>
> It is fundamental that each system account be used by one and only one
> unique human user. Without this condition accountability is impossible
> (at least for the users of that shared user-ID) unless it's provided by
> some external means (e.g. a security guard at the door of the
> Tempest-level room where the computer is located who is instructed to
> securely record every access to the computer, and who is capable of
> securely performing this duty).

Not right. The services are virtulized nowadays. Each one could provide
it's own privilege/accounting methods(guaranteed on application layer).

> It is also fundamental that every system activity performed by a human
> user be performed using a unique-per-human _system_ level identity. If
> you do not meet this condition then you are violating the fundamental
> security model of the system and all bets are off, all warrantees null
> and void, etc.

No "fundamental security model". Nothing to break.

[snip]

There's nothing concreete in your words. All you're talking about
is fundamental principles. That makes me think You've never managed
a single cvs repository.

[Greg A. Woods]

[ On Friday, August 6, 2004 at 19:27:57 (+0300), Delian Krustev wrote: ]
> Subject: Re: CVS woes: .cvspass
>
> Your mails are getting longer and longer. Please try saying more
> in less words next time. Thank You.

Unfortunately it seems I have to be very careful and very explicit with
my words or else you evidently misunderstand what I am trying to say. :-)

I.e. the more words I use the less likely you are to misinterpret them,
assuming you do read them all quite carefully. ;-)


> There's nothing like "fundamental security model". Not in unix/linux, nor
> in CVS. I suppose You're talking about UID/GID based security.

I'm talking about _the_ fundamental security model of unix(like)
systems. And there certainly is one -- it's quite well known and very
well documented, completely with a patent that's been signed over to the
public domain.

I don't know what _you_ might mean by the phrase "UID/GID based
security". I'm talking about the basic concepts of computing system
security and network security and how they relate to implementing a
secure CVS repository on a unix(like) system with network client/server
access.


> I'll repeat myself. Security could be guaranteed on different layers.

No, I'm sorry but you're still very wrong in this case. As I've already
tried to say two different ways already it is simply not possible to
guarantee any security whatsoever for a CVS repository using CVSpserver
by piling together different, dis-contiguous, dis-connected layers of
security on top of it. What you have proposed directly violates the,
basic, fundamental, underlying security model of all unix(like) systems.
You will be left with no accountability whatsoever.

IPsec can only be used to protect virtual circuts that might happen to
have to travel over insecure networks. However IPsec does not, and by
design cannot, have any part to play in the user-level security required
for implementing a secure CVS repository. Even using host-based IPsec
and making the assumption that each user can be uniquely identified by
the client host he or she is connecting from there's still no
accountability for those user's actions on the server side when some
poor afterthought of a hack like CVSpserver is used.

SSH can also be used to provide the same level of protection, with the
added fact that SSH integrates directly into the security model of the
underlying system and thus no other security mechanisms such as those
used by RSH are needed to use SSH with CVS (or rather SSH already
incorporates those security mechanisms within itself). However SSH
relies on the fact that in a secure environment every user will have a
unique system identity just as would be done if CVS were used on a
standalone non-networked secure multi-user system.


> The local access to the repository requires each commiter to have direct
> r/w access to each of the directories inside the repository. This gives
> him the power to compromise it in anyway he likes. The commits performed
> by locally executed cvs command are performed by creating/renaming/unlinking
> files.

Hmmm.... what you've said suggests that you need to go back and try to
understand the basic underlying security model of the system that CVS
was designed and implemented to run on top of before you consider the
implications of what I'm trying to say.

Note further that this model I'm talking about applies to many similar
applications, including but not limited in any way to other file-based
version control systems such as RCS, SCCS, TCCS, Aegis, and so on.

Indeed as you say local access to the repository is required for each
CVS user.

In some scenarios it would indeed be easy for an authorised user to go
in and mess about direclty with the repository files in order to
compromise them. However the potential for compromise that you speak of
is mitigated almost entirely by the nature of the application and how it
is used. It is after all in fact the goal of CVS to provide mediated,
shared, access to the common repository files. I won't go into how this
mitigation works as all that's important in this discussion is to point
out that it's not relevant to why IPsec does not, and cannot, do what
you suggest.

What this means though is that CVS, by design and by its implementation,
relies _entirely_ on the underlying operating system for all of its
security.

As you hint CVS is no different in how it must be viewed from a security
perspective than any text editor or compiler or spreadsheet calculator.
CVS cannot safely be made responsible for the security of the repository
any more than a text editor could be -- yet that is exactly what the
CVSpserver hack attempts to do. Any and all ways of using CVSpserver
try to turn CVS into the security application that it was not designed
to be.

Something like IPsec can only be used to provide security for the
inter-host connections that might be used to interact with a CVS
repository -- IPsec does not, and cannot, make something like CVSpserver
into a security application.


There's also a very blatant fact of history to consider:

The evidence of CVS' failings as a security application have been
splattered all over this very forum only quite recently, and it should
be clear to anyone experienced with security software who has taken even
a casual look inside of CVS that those previous compromises I refer to
are only the tip of the inevitable and proverbial iceberg that anyone
(mis)using CVSpserver is guaranteed to eventually run square into. CVS
simply cannot ever be a safe part of any security infrastructure or
application. It was not designed to do this and it was certainly not
implemented to do this. Any and all attempts to use CVSpserver and/or
other hastily cobbled together security hacks on top of the basic CVS
code are bound to fail, sometimes catastrophically, and no amount of
tweaking or auditing the CVS code will ever remove these risks
sufficiently for such use.

CVSpserver cannot, and must not under any circumstances, regardless of
whether IPsec or similar is used with it, be used for anything but
totally anonymous access to a copy of a CVS repository.

Would you make your text editor responsible for authenticating and
authorizing user accesses and accounting for their actions? Do you
think IPsec could somehow make it safe to do this with your text editor?

--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>

[Robin Rosenberg]

On Wednesday 04 August 2004 22.35, Greg A. Woods wrote:
> [ On Thursday, July 29, 2004 at 16:30:07 (+0300), Delian Krustev wrote: ]
>
> > Subject: Re: CVS woes: .cvspass
> >
> > On Tuesday 27 July 2004 23:20, Greg A. Woods wrote:
> > > Anyone using the CVS pserver mechanism for anything other than totally
> > > anonymous access gets only what they deserve.
> >
> > brr, do not forget that the security might be guaranteed on different
> > layers. E.g. ipsec secures the insecure protocols(the ones that transfer
> > data in plain text or with weak encryption), such as telnet or cvs
> > with pserver.
>
> Nope, sorry, but that's just not possible, at least not with CVS pserver.
>
> The unix security model, within which CVS is designed and implemented to
> work, _requires_ unique user-IDs for each and every unique human user.
[...]
> CVS is not, and cannot be, a security tool so running it as root and
> pretending to have it do all your authentication and authorisation flies

"pretending"?

With 1.12 CVS can (and that seems to be the default) use system
authentication methods like PAM and does setuid etc before doing any cvs
operations, which takes places as the respective user. It won't even let
me add users in CVSROOT/passwd. It does allow me to set a different password
for CVS acess though.

But also 1.11 did setuid etc before doing CVS operations and perhaps earlier
versions also, but I'm not sure about that.

-- robin

[Robin Rosenberg]

On Wednesday 04 August 2004 22.35, Greg A. Woods wrote:
> [ On Thursday, July 29, 2004 at 16:30:07 (+0300), Delian Krustev wrote: ]
>
> > Subject: Re: CVS woes: .cvspass
> >
> > On Tuesday 27 July 2004 23:20, Greg A. Woods wrote:
> > > Anyone using the CVS pserver mechanism for anything other than totally
> > > anonymous access gets only what they deserve.
> >
> > brr, do not forget that the security might be guaranteed on different
> > layers. E.g. ipsec secures the insecure protocols(the ones that transfer
> > data in plain text or with weak encryption), such as telnet or cvs
> > with pserver.
>
> Nope, sorry, but that's just not possible, at least not with CVS pserver.
>
> The unix security model, within which CVS is designed and implemented to
> work, _requires_ unique user-IDs for each and every unique human user.
>
> This is in fact a basic, fundamental, requirement of all systems of this
> type.
>
> CVS is not, and cannot be, a security tool so running it as root and
> pretending to have it do all your authentication and authorisation flies
> directly in the face of the underlying system security model and leaves
> you with no real and verifiable accountability whatsoever, and it also
> leaves you open to the possibility of yet another vulnerability vector
> in the form of the unaudited CVS code base. Remember that the vast
> majority of all security incidents originate internally to the
> organisations they affect.

With 1.12 CVS can (and that seems to be the default) use system
authentication methods like PAM and does setuid etc before doing any cvs
operations, which takes places as the respective user. It won't even let
me add users in CVSROOT/passwd. It does allow me to set a different password
for CVS acess though.

But also 1.11 did setuid etc before doing CVS operations.

-- robin

[Tilman Schmidt]

This is a multi-part message in MIME format...

------------=_1091780976-6780-309
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

Greg A. Woods schrieb in <bugtraq@SecurityFocus.com>:
> [ On Thursday, August 5, 2004 at 12:52:10 (+0300), Delian Krustev wrote: ]
>
>> There's a site outhere. It's sf.net . They demonstrate, with the number
>> of projects being hosted there (with pserver access), You're not right
>> again.

> In the scenario you speak of sf.net has no real requirement for
> accountability -- their offerning using CVSpserver is effectively the
> same as providing anonymous access. Sf.net doesn't care who the real
> humans are in this case -- they simply do their best (which isn't always
> perfect) to keep whole projects from interfering with each other.

In fact, you are even more right than you seem to think. Sf.net's
pserver access is actually anonymous and read-only. Project data in
the SF repository is considered public, and open to anonymous read
access anyway. Their pserver access doesn't add anything to that.

> Meanwhile, IIUC, sf.net does also offer secure SSH access to systems
> hosting CVS repositories and they use true system identities for eash
> SSH account, and presumably with this offering there's normally one (or
> maybe more) unique system accounts for every real human using this

That is so, and SSH access, with a system identity that is a member
of the project's development team, is required for committing changes
to a project repository.

> service, though of course the responsibility of verifying the uniqueness
> of system identities will be on the shoulders of the CVS project admins,
> and perhaps not on sf.net themselves.

Indeed. The registration form asks you to enter a real name, and
a valid E-mail address which is verified by a confirmation E-mail,
but there is no verification beyond that.

--
Tilman Schmidt E-Mail: Tilman.Schmidt@ePost.de
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

------------=_1091780976-6780-309--