cvs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Cvs-dev] Re: cvs-chpass.patch (former: cvs-passwd.patch)


From: Mark D. Baushke
Subject: [Cvs-dev] Re: cvs-chpass.patch (former: cvs-passwd.patch)
Date: Wed, 21 Jun 2006 08:32:41 -0700

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

Prasad J Pandit <address@hidden> writes:

> On Wed, 21 Jun 2006, Tony Hoyle wrote:
> > It seems to me it's better to keep them the same - Windows users
> > will normally be using wincvs/tortoisecvs which both use cvsnt.
> > Those users will send the cvs passwd command... it seems to me that
> > creating an entirely different one will just confuse users.
> 
>    Exactly! I too thought the same way. But then changed it from
> 'passwd' to 'chpass', thinking that, as long as facility is provided
> to change the password, it doesn't matter much, what the name of the
> command is.

I think you have misunderstood my previous e-mail messages.

One reason I suggested opening dialogue with address@hidden
and CVS Development <address@hidden> was to try to get us to agree
on the SAME client/server protocol.

If you wish to provide a subset of the CVSNT defined REQ_LINE("passwd")
client/server option, then fine. Provide a subset for the client and
implement it on the server. However, you may wish to accept all of the
options that CVSNT provides and print out a message that that particular
feature is not available.

static const char *const passwd_usage[] =
{
    "Usage: %s %s [-a] [-x] [-X] [-r real_user] [-R] [-D domain] [username]\n",
    "\t-a\tAdd user\n",
        "\t-x\tDisable user\n",
        "\t-X\tDelete user\n",
        "\t-r\tAlias username to real system user\n",
        "\t-R\tRemove alias to real system user\n",
        "\t-D\tUse domain password\n",
    NULL
};

The client/server transport ends up sending the typed_password after it
sends the options. The username is either the username on the
command-line or a "*" to indicate the currently logged-in user.

If you wish to add an option for your encrypted password, then that would
probably best be implemented as adding a new noop REQ_LINE in the server
that would indicate that the "passwd" command supports the '-e' option and
test for it in the supported_request () function.

> > OTOH I don't see the problem with supporting different feature sets 
> > (providing the basic 'change my password' functionality works, and that 
> > should be easy enough to arrange).
> 
>    Yeh, that's true.

Sigh.

Let me try again.

Goal:

       Any client (CVS or CVSNT) should be able to connect to any server
       (CVS or CVSNT) and do as much as possible to use the union of the
       feature sets of both.

This means that it would be better if your 'cvs chpass' command
implemented things using the existing CVSNT protocol. If you have an
enhacement to this protocol you would like to propose, then the joint
team should come up with a new REQ_LINE() keyword for server.c such that
the client is able to do a 'supported_request ("new-keyword")' test
before sending the server a request it is not able to fulfill.

Where possible, borrow shamelessly from the CVSNT password
implementation if you find that useful. When you are finished, you could
also send the code to the cvsnt-dev folks for them to adopt enhancements
into CVSNT to support the additional option to their "passwd" command.

    { "chpass",   "pw",       NULL,        chpass,    0 },

Please do NOT add a command alias "pw" unless everyone agrees that the
name chosen actually needs one. In this case, it does not, so remove it
and use

    { "chpass",   NULL,       NULL,        chpass,    0 },

instead.

Note that the "chpass" command is actually an alias for a subset of
functionality that the client/server "passwd" command provides. If/when
CVS ever wants to add more functionality, it could then adopt the full
"passwd" command used by CVSNT.

OR, you could use the "passwd" command right now and just adapt how
things are sent to the server by normally using the CVSNT defined
client/server API and only altering it if the server has support for the
"passwd-encrypted" or whatever folks agree should be the indication that
the "passwd" command has been extended.

I hope the above is clear...

        Thanks,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEmWaZCg7APGsDnFERAh/AAKC/MfnwerKOGDk06Kb/qyyTtAELSACgtwJS
6vig70+jMuAugBTPkseUeoA=
=BOD1
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]