Re: [Cvs-dev] Re: cvs-passwd patch

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Prasad,

P J P <address@hidden> writes:

> On Fri, 27 Oct 2006, Mark D. Baushke wrote:
> > If we assume that it is a bad idea to a :pserver: connection with
> > another connection method, then you would need a separate protocol
> > transaction to send across the old password to be validated.
> 
>    What? I beg your pardon!?!

Assertion:
  If a user has connected to :extssh:/cvs/repository/root it should not
  be assumed that :pserver: will also work from his host. For example,
  tunneling through a firewall might be possible for :extssh: and not
  possible for :pserver:

Corollary:
  It is a really bad idea to assume that a new :pserver: connection will
  work for a password validation unless the connection is currently a
  :pserver: connection to the same CVSROOT.

> >>     That's a *different* issue al together, Mark! All the methods of
> >> connection that cvs supports, are completely independent of
> >> each-other.
> >
> > But all commands that manipulate the repository should be able to
> > perform all of those manipulations regardless of connection method.
> 
>    Yes, quite fair! But then, isn't it equally important that, all the
> *required* manipulations to the repository, be supported by a
> connection method?

You asserting that it is required that a separate :pserver: connection
is required to authenticate the old password. This is an assertion I
reject.

There is nothing stopping you from using the current server connection
to send a message from the client to the server with the old password
and ask if it matches. A mismatch should probably generate a log event
of a bad password exploration. Yes, this would require a new protocol
token and round-trip. However, it will probably be less expensive than
setting up a new :pserver: connection just to see if you can.

> > I have not even mentioned wondering how your methods will work with a
> > proxy in place. Clearly attempting to do a direct connection to validate
> > the old password may not even provide a path for the packets to go.
> 
>    Ummn Mark, are you talking about a *new* validation method here?

No, currently supported methods in CVS already validate a user. My
assertion has been and remains that it is a very bad idea to open a
new :pserver: connection to validate the current password.

There are two current ways that proxy stuff works. One is limited to
:ext: connections to a secondary server which send the same commands
forward to the primary server or re-direct the client to use the primary
directly (if the client is able to handle redirection), the other is via
a web-like proxy mechanism.

> Because, what I'm using is, just the plain :pserver:. If it can get
> past the proxy, I'm sure 'passwd' can!

No, my assertion is that the user may have used a connection method that
can get to the server to change the :pserver: password, but that
:pserver: may not get through using that same connection from this host.

In the same way that a cvs administrator may make a change to any user
password without needing the extra :pserver: connection, the user should
not be forced to use a :pserver: connection to validate their old
password in order to change to a new password. I have no objection to
the idea of validation of the old password. I object to opening a new
client/server :pserver: connection for this purpose.

> >> And support for all of them, by a command, could be(or
> >> should be) the *desirable* characteristic, but certainly not the
> >> *required* one.  As, in case of :pserver:, there is no way, by which,
> >> a user can change her cvs password; Where as, for other methods, there
> >> are good enough means to do that, such as system 'passwd' command. Of
> >> course if SystemAuth=no, then again they are cursed.
> >
> > I think you have switched SystemAuth=yes for SystemAuth=no here.
> 
>    I have?! I'm sorry!! I thought, SystemAuth=no means, cvs(:pserver:,
> :kserver:, etc) would make use of `CVSROOT/passwd' authentication,
> instead of `/etc/passwd'. And user can not change those credentials
> using cvs client, can she?

At present, no CVS user is able to alter any credetials at all...

> > Possibly I have had too little sleep. Have you looked at the way the
> > passwd implementation is done on CVSNT? Is it different in control flow
> > than your implementation? Should it be different in control flow?
> 
>    Yes, I have! And as far the control flow goes, I didn't see any
> significant difference, both are quite similar.

What protocol does CVSNT use to verify the current password today before
allowing the change?

> OT: Ummn, Mark, my messages to address@hidden, they don't quite
> make it to the list.  Everytime I get a reply saying, "my post to the
> list is awaiting moderators consent, and I'll receive a message in
> case it is rejected"; neither I get such message, nor my post makes it
> to the list.
> 
> Could you do something/anything about it?

Derek is the administrator of the list. I am not sure how it is setup,
but it is moderated somehow.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFFSXXrCg7APGsDnFERAl/+AJwOnHdW5h8p+Ir5ztIddV/vlyQ6DQCbBKye
DCCSTPmWqssH+s9qy+o7mTY=
=u7ll
-----END PGP SIGNATURE-----