cvs-nserver-devel — Developers

cvs-nserver acl support

[Wang J. <la...@li...>]

Hello,

I test ACL on cvs-nserver but

[lark@sw2 foobar]$ /usr/local/bin/cvs acl access,modify .
cvs [server aborted]: admin is not allowed to manage ACLs

And I notice that cvs-nserver/acl/  is now empty in CVS repository in
cvs.sourceforge.net.

cvs-nserver will not support builtin ACLs any more?

-- 
  lark

Re: bug in checkpassword-pam (0.90.2)

[John V. <jva...@ag...>]

On Thu, 20 Dec 2001, Alexey Mahotkin wrote:

> >>>>> "JV" == John Vaughan <jva...@ag...> writes:
> 
> JV>     pam_error = pam_setcred(pamh, PAM_ESTABLISH_CRED);
> 
> JV> It worked fine...
> 
> Wow!   Thanks.  What operating system do you have? 

I'm inflicting Solaris upon it, lucky me. 
 
> /usr/include/security/_pam_compat.h:# define PAM_ESTABLISH_CRED      0x1
> /usr/include/security/_pam_types.h:#define PAM_ESTABLISH_CRED              0x0002U
> 
> 
> Feel the difference between two last #defines 8-[ ] People, do you see
> something like that on your system?

Solaris only has:
/usr/include/security/pam_appl.h:#define    PAM_ESTABLISH_CRED      0x1     

I think the second linux define is something specific to linux-pam, which 
was developed in parallel to Solaris pam (afair).

> Comments in log_pam.c say:
> 
> 	/* for compability with older pam stuff, before the stupid transposition */
> 	#ifndef PAM_CRED_ESTABLISH
> 	#define PAM_CRED_ESTABLISH  0x0002U
> 	#endif	
> 
> I think it could be changed to
> 
> #define PAM_CRED_ESTABLISH PAM_ESTABLISH_CRED
> 
> 
> though I'm already way fscking afraid of it all :)

My FreeBSD boxen have the 0x0002U define as well, but comment:
/* ---------------------- The Linux-PAM flags -------------------- */

So, unless you want to do some trickery with detecting which pam flavour 
it is, it may just be easier to do that simple change. 
I still think you should change the main thing to be the ESTABLISH_CRED 
though. Personally. But I'm just a sysadmin :)

 
> Oh, do you run cvs-nserver in production?

Well, we're looking to put it into a lab environment. My goal is to get 
every single thing we have passwords for to authenticate against ldap, and 
the only good way to do that in unixland is with PAM. I guess if it works 
in the lab, it could be used in production instead of the large commercial 
product which everyone hates :)


-- 
John Vaughan                            | 20 Exchange Place
Director of Network Systems		| New York, NY 10005
AGENCY.COM                              | 212-358-5407

bug in checkpassword-pam (0.90.2)

[Alexey M. <al...@hs...>]

>>>>> "JV" == John Vaughan <jva...@ag...> writes:

JV> Hi,

JV> I've just spent many days (I'm a sysadmin, not a programmer)
JV> tracking down a bug in the pam authentication part of
JV> checkpassword-pam.

JV> In log_pam.c, line 122, you have:

JV>     pam_error = pam_setcred(pamh, PAM_CRED_ESTABLISH);

JV> There's no such define as 'PAM_CRED_ESTABLISH' - it should be
JV> 'PAM_ESTABLISH_CRED' (see 'man pam_setcred');

JV> Once I changed it to:

JV>     pam_error = pam_setcred(pamh, PAM_ESTABLISH_CRED);

JV> It worked fine...

Wow!   Thanks.  What operating system do you have? 


Oh, I've just looked in headers in my Debian and I'm now extremely
frightened:

alexm@tyranny:~/checkpassword-pam$ grep PAM_ESTABLISH_CRED /usr/include/security/*.h
/usr/include/security/_pam_compat.h:# undef PAM_ESTABLISH_CRED
/usr/include/security/_pam_compat.h:# define PAM_ESTABLISH_CRED      0x1
/usr/include/security/_pam_types.h:#define PAM_ESTABLISH_CRED              0x0002U


Feel the difference between two last #defines 8-[ ] People, do you see
something like that on your system?

Comments in log_pam.c say:

	/* for compability with older pam stuff, before the stupid transposition */
	#ifndef PAM_CRED_ESTABLISH
	#define PAM_CRED_ESTABLISH  0x0002U
	#endif	

I think it could be changed to

#define PAM_CRED_ESTABLISH PAM_ESTABLISH_CRED


though I'm already way fscking afraid of it all :)


JV> Here's a diff, just for the heck of it ;)

;) 


JV> Thanks for doing this by the way - you seem to be the only person
JV> interested in get CVS to work with PAM at all...

Oh, do you run cvs-nserver in production?

AFAIK, there are couple more PAM-related patches, but mine is the
cleanest of all ;)



Many thanks again, it's not obvious how frightening this bug is.

--alexm

report for November

[Alexey M. <al...@hs...>]

I've did the following in November:

- implemented 'cvs ls' subcommand;

- implemented module-level ACL support; together with the 'cvs racl'
  subcommand; test-cases for all those;

- ACL on branches are now mostly supported;

- "CVS Administrator's Guide" started as a separate documentation
  volume;


What I'm expecting in the future: 

- shake out organizational issues regarding the test installation of
  cvs-ncli; have somebody to play with ACLs, and report feedback on
  that;

- continue writing Administrator's Guide;

- fix and finalize all the features we've been working on.

--alexm

couple of points to note about the ACLs

[Alexey M. <al...@hs...>]

[ This is documented in the acl-rfc.txt ]

a) possible caveat (with a solution):

The concept of "no ACLs" is used a lot, and this could sometimes lead
to (unexpected) opening of repository to extemely wide access.  In
short, when the ACL file is non-existent or becomes empty after
revoking all privileges granted, the "default ACL" come into play.
Default ACL simply allows everything.  Maybe we need some flag file in
the repository that means "default ACL is deny everyone".

(not done yet)


b) intercommunication between ACLs on branches:

- if there are no ACLs on a certain branch, then ACLs on a trunk are
  used instead.  If there are no ACLs on a trunk, then default
  directory ACLs for certain branch are used.  As a last resort, the
  default ACLs are used.

Of course, the "branch/trunk" should be generalised to "branch/its
parent branch", because there could be branch on a branch (done only
partially).


In fact, this behaviour is intuitive and expected.  It adds complexity
only for implementor.


--alexm

handling cvspasswd in presence of several virtual repositories

[Alexey M. <al...@hs...>]

Current installation instruction suggest to make the 'cvspasswd'
binary setgid reposNadmin, thus enabling the ordinary users to change
their passwords.  This scheme is obviously broken, because there are
many reposNadmin's.  Here is the solution:


+ Regarding several repositories.  You should create a pair of
user-group accounts on server machine.  Let them be called simply:
repos1.repos1, repos2.repos2 and so on. 


How to handle several repositories wrt 'cvspasswd' program: We could
create the appropriate users and groups: repos1admin.repos1admin,
repos2admin.repos2admin, etc.  The 'cvspasswd' program gets installed
setuid root.  There is a hardcoded configuration file
/etc/cvspasswd.conf, containing lines like:

    /repos1 repos1admin:repos1admin
    /repos2 repos2admin:repos2admin
    /repos3 repos3admin:repos3admin

When the cvspasswd program is run by the ordinary user (running under
repoN.reposN, where every reposN user is in the 'cvs' group), it reads
the configuration file and setuids to the appropriate user/group.
Afterwards it modifies the CVSROOT/cvspasswd file.

This probably should be made the default behaviour.


--alexm

Bug of command line -- misbehavior of 1.11.1.51

[Wang J. <la...@li...>]

Hello,

The racl subcommand can't be used. But it is listed in subcommands.

gw:~/test$ set|grep CVSROOT
CVSROOT=:pserver:cvsadmin@192.168.0.102:/cvsroot
gw:~/test$ ~/cvs-nserver-1.11.1.51/src/cvs acl
Usage: cvs acl [-r BRANCH] USER permissions files...
gw:~/test$ ~/cvs-nserver-1.11.1.51/src/cvs racl
Unknown command: `racl'

CVS commands are:
        acl          Manage Access Control Lists using the working copy
        add          Add a new file/directory to the repository
        admin        Administration front end for rcs
        annotate     Show last revision where each line was modified
        checkout     Checkout sources for editing
        commit       Check files into the repository
        diff         Show differences between revisions
        edit         Get ready to edit a watched file
        editors      See who is editing a watched file
        export       Export sources from CVS, similar to checkout
        history      Show repository access history
        import       Import sources into CVS, using vendor branches
        init         Create a CVS repository if it doesn't exist
        log          Print out history information for files
        login        Prompt for password for authenticating server
        logout       Removes entry in .cvspass for remote repository
        pserver      Password server mode
        racl         Manage Access Control Lists
        rannotate    Show last revision where each line of module was modified
        rdiff        Create 'patch' format diffs between releases
        release      Indicate that a Module is no longer in use
        remove       Remove an entry from the repository
        rlog         Print out history information for a module
        rtag         Add a symbolic tag to a module
        server       Server mode
        status       Display status information on checked out files
        tag          Add a symbolic tag to checked out version of files
        unedit       Undo an edit command
        update       Bring work tree in sync with repository
        version      Show current CVS version(s)
        watch        Set watches
        watchers     See who is watching a file


-- 
  lark

Re[2]: Bug report -- cvs-nserver-1.11.1.51 client

[Wang J. <la...@li...>]

Hello Alexey,

Saturday, November 17, 2001, 9:36:31 PM, you wrote:

>>>>>> "WJ" == Wang Jian <la...@li...> writes:

WJ>> Hello Alexey, Thanks.  But please fix it now :-) It is too
WJ>> mysterious and too easy to happen. Fixing it ASAP can avoid more
WJ>> fuss.

AM> 1.11.1.52 has zlib support simply disabled :) 

Hoho, so easy 'fix' ;-)

WJ>> BTW: 'group' subcommand doesn't work. Is it in lastest CVS
WJ>> version?

AM> There was never the 'cvs group' subcommand.  The CVS groups are
AM> handled like this (quoting from older message): 

AM> When the CVSROOT/cvsgroup file exists, it specifies the CVS groups in
AM> the following format:

AM>    %devel: alice, bob, carol
AM>    %mgmt: mike, nick
AM>    %devel: dave, elisabeth

AM> As you see, the group names could be specified several times: lists of
AM> users will just be added up together: this is to get rid of too-long
AM> lines in cvsgroup.

So it is a bug of documentation.

see www/acl-cli.txt in 1.11.1.51

==quote==
Command lines for groups management:

a. Creating a group:

    $ cvs group create <group>


b. Deleting a group:

    $ cvs group delete <group>
==quote==

I think this subcommand is necessary for convenient remote management.


AM> To edit that file, you simply 

AM>         $ cvs co CVSROOT/
AM>         $ echo cvsgroup >> checkoutlist
AM>         $ cvs add checkoutlist cvsgroup
AM>         $ vi cvsgroup
AM>         $ cvs ci

AM> When there is an error in the cvsgroup file, the users will get a
AM> warning about that, but not a fatal error (sure, the ACLs after that
AM> line will not be honoured).


AM> Special '%ALL' group is not supported yet.



-- 
  lark

Re: Bug report -- cvs-nserver-1.11.1.51 client

[Wang J. <la...@li...>]

Hello Alexey,

Thanks.  But please fix it now :-) It is too mysterious and too easy
to happen. Fixing it ASAP can avoid more fuss.

BTW:  'group' subcommand doesn't work. Is it in lastest CVS version?

What I can do to help this project?

Saturday, November 17, 2001, 5:36:23 AM, you wrote:

>>>>>> "WJ" == Wang Jian <la...@li...> writes:

WJ>> Hello cvs-nserver-devel, I find this bug. I wish it helps.

AM> Thanks, this is a known issue.  It will be fixed somewhere after the
AM> ACL part is done.

WJ>> Program received signal SIGSEGV, Segmentation fault.  0x0808d118
WJ>> in compress_buffer_initialize (buf=0x0, input=1, level=4,
WJ>> memory=0) at zlib.c:116 116 assert (! input || buf->data == NULL


-- 
  lark

Re: Bug report -- cvs-nserver-1.11.1.51 client

[Alexey M. <al...@hs...>]

>>>>> "WJ" == Wang Jian <la...@li...> writes:

WJ> Hello Alexey, Thanks.  But please fix it now :-) It is too
WJ> mysterious and too easy to happen. Fixing it ASAP can avoid more
WJ> fuss.

1.11.1.52 has zlib support simply disabled :) 

WJ> BTW: 'group' subcommand doesn't work. Is it in lastest CVS
WJ> version?

There was never the 'cvs group' subcommand.  The CVS groups are
handled like this (quoting from older message): 

When the CVSROOT/cvsgroup file exists, it specifies the CVS groups in
the following format:

   %devel: alice, bob, carol
   %mgmt: mike, nick
   %devel: dave, elisabeth

As you see, the group names could be specified several times: lists of
users will just be added up together: this is to get rid of too-long
lines in cvsgroup.

To edit that file, you simply 

	$ cvs co CVSROOT/
	$ echo cvsgroup >> checkoutlist
	$ cvs add checkoutlist cvsgroup
	$ vi cvsgroup
	$ cvs ci

When there is an error in the cvsgroup file, the users will get a
warning about that, but not a fatal error (sure, the ACLs after that
line will not be honoured).


Special '%ALL' group is not supported yet.


WJ> What I can do to help this project?

Trying to install and use that.  Reporting every glitch or
inconsistency you meet. 


Thanks,

--alexm

Re[2]: Bug report -- cvs-nserver-1.11.1.51 client

[Wang J. <la...@li...>]

Hello Alexey,

Actually, Only an empty repository there. So

$ cvs co lark

will fail in any conditions.

When calling compress_buffer_initialize, from_server is NULL,

#1  0x80b34de in internal_start_server (verify_only=0) at client.c:4040
4040                from_server = compress_buffer_initialize (from_server, 1,

so buf->data or buf->data->next causes SEGV.

#0  0x8093f7b in compress_buffer_initialize (buf=0x0, input=1, level=3,
    memory=0) at zlib.c:116
116         assert (! input || buf->data == NULL || buf->data->next == NULL);


To make sure the inexistence of module is not the cause, I create a
test module.

gw:~$ set |grep CVSROOT
CVSROOT=:pserver:cvsadmin@192.168.0.102:/cvsroot
gw:~$ cvs-nserver-1.11.1.51/src/cvs co test
Segmentation fault (core dumped)
gw:~$ cvs-nserver-1.11.1.51/src/cvs -z0 co test
U test/bo.c
U test/ex.c
U test/sc.c
U test/scode.c
U test/shellcode.c

Friday, November 16, 2001, 11:32:23 PM, you wrote:

AM> On Fri, Nov 16, 2001 at 11:04:46PM +0800, Wang Jian wrote:
>> Hello cvs-nserver-devel,
>> 
>> I find this bug. I wish it helps.
AM> I'll take a look on it tomorrow if you don't mind, Alex, Ok?

AM> 2Wang Jian: does this happen on any missing module in a repository?
AM> If no, we probably will need to know more about repository and module
AM> configuration etc etc etc, Ok?




-- 
  lark

Bug report -- cvs-nserver-1.11.1.51 client

[Alexey M. <al...@hs...>]

>>>>> "WJ" == Wang Jian <la...@li...> writes:

WJ> Hello cvs-nserver-devel, I find this bug. I wish it helps.

Thanks, this is a known issue.  It will be fixed somewhere after the
ACL part is done.

WJ> Program received signal SIGSEGV, Segmentation fault.  0x0808d118
WJ> in compress_buffer_initialize (buf=0x0, input=1, level=4,
WJ> memory=0) at zlib.c:116 116 assert (! input || buf->data == NULL

--alexm

Bug report -- cvs-nserver-1.11.1.51 client

[Wang J. <la...@li...>]

Hello cvs-nserver-devel,

I find this bug. I wish it helps.

I use ./configure --enable-setuid --with-openssl

[lark@swtest src]$ export CVSROOT=:pserver:cvsadmin@larkvm:/cvsroot
[lark@swtest src]$ ./cvs co lark
Segmentation fault
[lark@swtest src]$ pwd
/home/lark/cvs-nserver-1.11.1.51/src

[lark@swtest src]$ ./cvs -z0 co lark
cvs server: cannot find module `lark' - ignored
cvs [checkout aborted]: cannot expand modules

[lark@swtest src]$ ./cvs -z1 co lark
Segmentation fault

[lark@swtest src]$ gdb ./cvs
GNU gdb 5.0mdk-11mdk Linux-Mandrake 8.0
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-mandrake-linux"...
(gdb) run co lark
Starting program: /home/lark/cvs-nserver-1.11.1.51/src/./cvs co lark

Program received signal SIGSEGV, Segmentation fault.
0x0808d118 in compress_buffer_initialize (buf=0x0, input=1, level=4, memory=0)
    at zlib.c:116
116         assert (! input || buf->data == NULL || buf->data->next == NULL);
(gdb) bt
#0  0x0808d118 in compress_buffer_initialize (buf=0x0, input=1, level=4, 
    memory=0) at zlib.c:116
#1  0x080ac73b in internal_start_server (verify_only=0) at client.c:4040
#2  0x080ac0ed in start_server () at client.c:3679
#3  0x080503d4 in checkout (argc=1, argv=0x80d8504) at checkout.c:264
#4  0x08069348 in main (argc=2, argv=0x80d8500) at main.c:1060
#5  0x401301f0 in __libc_start_main () from /lib/libc.so.6


-- 
  lark

current ACL support status

[Alexey M. <al...@hs...>]

JFYI, I'm currently working on 

AM> TODO:

AM>  + module-level ACL support: both in libcvsacl and in client; 'cvs
AM> racl' subcommand; (est. 3 days)

I think that I'll complete it tomorrow or to-tomorrow.  After that
I'll be fixing branches support.

--alexm

preliminary support for 'cvs ls' subcommand

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Mahotkin <al...@hs...> writes:

AM> ACLs are also supported, too (though not tested).

AM> The only thing left is support for tags (see original cvsweb);
AM> Alex, do you need anything else from 'cvs ls'?

I think I've mostly implemented tag support.  That is, you may say

	$ cvs ls -R -r BRANCH module/sdir/

and get what is expected.  Dates are not currently supported, because
of a small yet unresolved issue.  I guess it's needed only for
completeness.

Committed,

--alexm

preliminary support for 'cvs ls' subcommand

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Mahotkin <al...@hs...> writes:

AM> Hello,

AM> I've partially implemented the 'cvs ls' subcommand.  Alex, I hope
AM> it would help you to at least put the basic framework into your
AM> code.  You should make the parsing be extensible, because
AM> currently only few fields are shown up.

Ok, I've partially understood how the rcs.c works, and now 'cvs ls'
can emit timestamps (simply as time_t) and user name.  The format is:

Dtesting
/README/1.3/alexm/991519963/
/hello.c/1.3/alexm/991586038/
Dtesting/sdir
/sfile/1.1/alexm/1004743368/
Dtesting/sdir/ssdir

The only thing left wrt original cvsweb is the "Last log revision".  I
do not know how to escape it here, so suggestions on output format are
appreciated (maybe simple XML?  or RFC822-style?  or binary-64
encoding?  =)


ACLs are also supported, too (though not tested).

The only thing left is support for tags (see original cvsweb); Alex,
do you need anything else from 'cvs ls'?


AM> Currently there are only filename and revision number supported.
AM> I could not get the timestamp (as in CVS/Entries) file however I
AM> tried.  It must be hidden somewhere in very obvious place.

Hm, yes, the place was rather simple :)  I think I need to make up
some summary of things uncovered while digging inside of the CVS...

Everything is committed.  Enjoy,

--alexm

preliminary support for 'cvs ls' subcommand

[Alexey M. <al...@hs...>]

Hello,

I've partially implemented the 'cvs ls' subcommand.  Alex, I hope it
would help you to at least put the basic framework into your code.
You should make the parsing be extensible, because currently only few
fields are shown up.

The usage and output look like this:

alexm@tyranny:~/cvs-ncli/src$ ./cvs -d :pserver:alexm@localhost:/repos ls -R testing
Dtesting/
/README/1.1//
/hello.c/1.1//
Dtesting/sdir/
/sfile/1.1//
Dtesting/sdir/ssdir/


Everything is hopefully obvious, as you see. 

Currently there are only filename and revision number supported.  I
could not get the timestamp (as in CVS/Entries) file however I tried.
It must be hidden somewhere in very obvious place. 


Everything is committed.  I'll keep you informed.

--alexm

checkpassword-pam (Was: cvs-nserver)

[Alexey M. <al...@hs...>]

>>>>> "JW" == Jochen Witte <jw...@al...> writes:

JW> Yes, correct: say you have a group called "cvs". When I have
JW> /my/repository as perhaps "root.cvs" with permissions 770, then a
JW> user can access the repository only if "cvs" is his PRIMARY group,
JW> which - of cource - is not always correct, isn`t it?

Ok, I knew about that bug.  Too bad I haven't fixed that right away.

The thing is that when upgrading to new checkpassword-0.90, we forgot
to use the initgroups() call there.

Jacob, may I ask you two things: a) if possible, could you add the
initgroups() call to your sources, and b) please send me the sources
in a simple .tar.gz format, not in .src.rpm which my rpm don't
understand.   Thanks a lot.

I'll finally put that as a cvs-nserver module to SourceForge.

Jochen, you may currently use older (0.81, I believe) version of
checkpassword-pam, taken from cvs-nserver 1.10.8.4 (sources attached).
Just untar that and do the

	$ make checkpassword-pam 

there.  This version requires the name of /etc/pam.d/ file to be the
first argument, that is:

cvs-pserver /repos1 ... /reposN -- /usr/bin/checkpassword-pam cvspserver cvs pserver

Where the "cvspserver" is how the file in /etc/pam.d/ called.  I
believe Jacob's version uses an environment variable for that purpose
(BTW, I don't think that's that good an idea, but nevertheless).


I'll reimplement the PAM'ified checkpassword from scratch with a
proper Autoconf build environment soon.


Thanks for patience, feel free to contact me,

--alexm

Re: New version of CVS permissions patch - security fix

[Corey M. <mi...@ac...>]

Alexey Mahotkin wrote:

>>>>>>"CM" == Corey Minyard <mi...@ac...> writes:
>>>>>>
>
>CM> 2001-09-21 Corey Minyard <mi...@ac...>
>
>CM>          * src/admin.c: Changed the admin command to only require
>CM> write access, not owner access.
>
>By the way, I've simply disabled the 'admin' subcommand in remote mode
>:)
>
>--alexm
>
Most of admin is useless, but if you forget to set a file binary (-kb) 
when you
add it, you need the admin command to set that option.  So you might 
consider
adding that one function back.  Also, if you use locking, you need the admin
command.  Really, admin is a big glob of unrelated functions and needs to be
split up, but that's another story.

-Corey

New version of CVS permissions patch - security fix

[Alexey M. <al...@hs...>]

>>>>> "CM" == Corey Minyard <mi...@ac...> writes:

CM> 2001-09-21 Corey Minyard <mi...@ac...>

CM>          * src/admin.c: Changed the admin command to only require
CM> write access, not owner access.

By the way, I've simply disabled the 'admin' subcommand in remote mode
:)

--alexm

Re: http_proxy client

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

AM> On Tue, Oct 23, 2001 at 03:27:45AM +0400, Alexey Mahotkin wrote:
>> Ah, I forgot: always use CFLAGS="-Wall -W" (-ansi -pedantic is
>> useful too) when compiling.  It shows the
>> 
>> *user == NULL;
>> 
>> bug, and the "control reaches end of non-void function".
AM> It's not a bug.  

It's a bug.  It is "statement has no effect" ;) 

AM> user is defined as char **user, not char *user.
AM> We can't pass parameters by ref, do we??

I don't think there is a need for http_proxy_get_info

--alexm

Re: http_proxy client

[John C. N. y L. <nj...@nt...>]

Alexey Mahotkin wrote:
> 
> >>>>> "AM" == Alexey Morozov <mo...@no...> writes:
> 
> AM> I have committed the files into NCLI-1-11-1 branch. The http_proxy
> AM> method looks Ok (I have tested it a bit), although authorized http
> AM> proxy access method was not in place yet (does anybody really need
> AM> it?).
> 
> As per authorized http proxy access -- I think we could post-pone that
> until someone actually requests that.  And I think there won't be a
> need to enhance the cvs_proxy syntax (though with regexes it's
> simple).  We could use simply cvs_proxy_username/cvs_proxy_password,
> or explicitly ask for the latter.
> 

Our set-up over is through an authorized web proxy...  Just a simple
username/password challenge =)

Perhaps I can coaxed our Net ad to add a non-authenticated proxy.... 
Well maybe =)


Cheers,


John Clark


-- 
     /) John Clark Naldoza y Lopez                           (\
    / )    Software Design Engineer III                      ( \
  _( (_    _  Web-Application Development                    _) )_
 (((\ \>  /_>    Cable Modem Network Management System <_\  </ /)))
 (\\\\ \_/ /         NEC Telecom Software Phils., Inc.  \ \_/ ////)
  \       /                                              \       /
   \    _/  phone: (+63 32) 233-9142 loc. 3113            \_    /
   /   /  cellphone: (+63 919) 399-4742                     \   \
  /   / email: nj...@nt...                        \   \


"Intelligence is the ability to avoid doing work, yet getting the work
done"
--Linus Torvalds

http_proxy client

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

AM> I had to change certain in the client.c and socket-client.h. Alex,
AM> please review it and tell if it's Ok.

Ah, I forgot: always use CFLAGS="-Wall -W" (-ansi -pedantic is useful
too) when compiling. 

It shows the 

  *user == NULL;

bug, and the "control reaches end of non-void function".

I would also recommend "-Wmissing-prototypes -Wstrict-prototypes", but
other CVS code gives a lot of unneeded positives for that (don't worry
about this).

--alexm

http_proxy client

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

AM> I had to change certain in the client.c and socket-client.h. Alex,
AM> please review it and tell if it's Ok.

Additional comment: you can see how the network-clients could be put
on top of each other, if you search for the "create_logging_client()"
in client.c.

(Though current usage is slightly wrong, because you shouldn't
explicitly call the

   particular_client->connect(particular_client);

the 

    /* connect() to remote host or something similar. */
    ncli->connect(ncli);

line is everything that is needed.  I'll fix that.


Otherwise, logging-client is a good example of actually stackable
client.

--alexm

http_proxy client

[Alexey M. <al...@hs...>]

>>>>> "AM" == Alexey Morozov <mo...@no...> writes:

AM> I have committed the files into NCLI-1-11-1 branch. The http_proxy
AM> method looks Ok (I have tested it a bit), although authorized http
AM> proxy access method was not in place yet (does anybody really need
AM> it?).

As per authorized http proxy access -- I think we could post-pone that
until someone actually requests that.  And I think there won't be a
need to enhance the cvs_proxy syntax (though with regexes it's
simple).  We could use simply cvs_proxy_username/cvs_proxy_password,
or explicitly ask for the latter.

--alexm