cvs-nserver-devel — Developers

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?).

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.


http_proxy-client.c is ~400 lines.  That's twice as large as other
clients.  Whoa! 


First, proper handling of errors should be like this:

             return ncli->error(ncli, "proxy has closed connection");

And _not_ like

	     ncli->error(ncli, "proxy has closed connection");
	     return NCLI_FAILURE;

Actually, ncli->error() is not supposed to return.  I've played a bit
with __attribute__((noreturn)), but GCC doesn't allow to specify this
attribute for typedef or at least I could not do that.

That change alone would actually save couple dozens of lines. 

(This was documented in ncli-architecture.txt, though not so clearly,
maybe).


Second, the network-clients should never create each other.  That is,
the http_proxy client should never create a socket-client for itself.
Instead, it should rely on client.c to create socket-client, and then
to put the http_proxy client on top of it.

The http_proxy read/write/disconnect methods thus should simply call
the

   ncli->next->disconnect()

etc. 


The http_proxy connect method should parse the cvs_proxy env-var, call
the ncli_socket_connect() (don't confuse it with socket_connect()),
and try to negotiate the proxy-connection.


Third, it is actually ok to use regexes :) I once rewrote the
parse_cvsroot() with regexes to handle port numbers.  So, you can
safely rewrite, if that would make the code more clear (and I am sure
it would, especially considering that:


Fourth, when you'll rewrite to regexes, you may use extremely strict
and simple method of specifying the "cvs_proxy" environment variable
(and that's how it should be called, BTW: to be consistent with
http_proxy and ftp_proxy).  You could simply use the

    cvs_proxy=http://proxy.example.org:3128/

and that's all.  Note that there is _no_ default port as far as I
know.  So don't hassle with all that cases -- it's not worth it.  


Fifth, the abomination of connect_line is completely unneeded, sorry.
You could simply use the POSIX fdopen(), and 

    printf("CONNECT %s:%hu HTTP/1.1");

That'll save a lot of free(connect_line).   Don't forget to fflush().


Sixth, wrt handling HTTP-response from proxy.  I really think that you
could use the ncli_read_line(), read a line, and then simply sscanf()
it, instead of strcmp()'ing its various parts.  sscanf() turned out
extremely powerful for simple cases, and it seems like the
HTTP-response _is_ a simple case.


Whoa!  I hope that we'll greatly improve the http_proxy-client.c using
the above suggestions :)


AM> Please note in order to build things properly you have to re-run
AM> 'aclocal; autoconf; automake', 'cause I didn't commit local
AM> ./configure, it differs from server's one too much (377 lines and
AM> I'm not sure that's not my local misconfigurations/features).

--alexm

cvs-nserver-1.11.1.51 beta release

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

I'm currently uploading the cvs-nserver-1.11.1.51 beta release to
sf.net.  I hope it'll be available in several hours.

libcvsacl + CVS client:

 + does the basic ACL manipulation/checking (ignoring branch, working
   only on trunk) for:

   + branch-level ACLs;

   + directory-level ACLs;

   + default file ACLs;

 + 'cvs acl' subcommand works;

 + the code is fully auto-verified;


CVS client:

 + ~75 percent of most important subcommands is protected with ACLs;

 + preliminary SSL support;


CVS server:

 + supports user groups with help of CVSROOT/cvsgroup file; 

 + supports ACL administrators with help of CVSROOT/acl-admins;

 + SSL support with help of stunnel;


TODO: 

- ACL-protect all the subcommands and variants of it;

- there is no "ACL administrator can't access files as regular user"
  security check yet;

- implement module-level permissions (various ways of tagging);
   'cvs racl' subcommand;

--alexm

ACL administrators support

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

I've implemented support for ACL administrators, a very simple one:

when there is a file /repos/CVSROOT/acl-admins, it should contain a
list of username who are allowed to manage ACLs in this repository.

There is no "ACL administrator can't access files as regular user"
security check yet. 

Enjoy,

--alexm

user groups support

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

ok, I've preliminarily implemented support for user groups both in
libcvsacl and in cvs binary itself.

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.


Everything is committed.   Enjoy,

--alexm

ACL status update

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

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

AM> Current status of ACL implementation is as follows:

AM>  + 'cvs acl' subcommand for managing the ACLs is mostly
AM> implemented (setting branch-level and directory ACLs works);

Fully implemented: default file ACLS done. 

AM>  + actual ACL checking is done only partially: for the most
AM> important and simple commands; adding new checks is rather easy;

Several new commands are ACL-protected.  'cvs admin' is disabled in
server mode.  Thorough audit is needed. 

AM> TODO:

AM>  + complete ACL checking (there is no formal way to make sure that
AM> "everything" is ACL-controlled, BTW) (est. 1 day);

Thorough audit is needed. 

--alexm

extra-fresh Autoconf and Automake are needed

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

Because of a need to introduce the Autotest support, the cvs-nserver
development now requires the current Autoconf from CVS and the
Automake 1.5.

This could be a little pain, but it's the way to go if we want it all
to be tested.

--alexm

ACL status (with completion estimates)

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

Current status of ACL implementation is as follows:

libcvsacl:

 + does the basic ACL manipulation/checking (ignoring branch, working
   only on trunk) for:

   + branch-level ACLs;

   + directory-level ACLs;

   + default file ACLs;

 + the code is fully auto-verified;


command-line client:

 + 'cvs acl' subcommand for managing the ACLs is mostly implemented
   (setting branch-level and directory ACLs works);

 + actual ACL checking is done only partially: for the most
   important and simple commands; adding new checks is rather easy;

 + the client code is fully auto-verified; 



TODO:

 + complete ACL checking (there is no formal way to make sure that
   "everything" is ACL-controlled, BTW) (est. 1 day);

 + complete the CVS client (actual usability testing should be done)
   (est. 1 day);

 + user groups support; (est. 2 days)

 + fully support branches (est. 2 days);

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

 + ACL administrators support; (est. 2 days)

where "day" is about 10 hours;

--alexm

Re: [RFC] proposed client command-line interface for dealing withACL

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

This looks very good, but as usual, I have a few comments:

* You don't list the ability to add directories to the repository as
  a separate access method.

* I don't think comma separated lists should allow spaces in them, it
  seems unnatural to me and simple errors can cause problems.  I assume
  you are using the comma at the end of the name to know the next thing
  is a member of the list.  Plus, it will be uncommon to specify more
  than on user/group on a command line.

* The <dirs> should be optional, and you should operate by default on
  the current directory.

* I don't understand the use of "racl", could you explain that a
  little more?

* You don't mention per-tag permissions.  Are you planning that for
  later?


It's good to hear from you again.  Things have been pretty chaotic
here for the last week.

-Corey

Alexey Mahotkin <al...@hs...> writes:

> CVS CLIENT COMMAND-LINE INTERFACE TO ACL
> =========================================
> 
> 
> Notation used in this document:
> 
>   <user>
> 
>         CVS user name, a-la UNIX username.  E.g.:
> 
>                 alice
>                 bob-johnson
> 
> 
>   <group>
> 
>         CVS group name, a-la UNIX group, with leading "percent" (this
>         is subject to discussion).  E.g.:
> 
>                 %devel
>                 %support-staff
> 
>         There are special groups called %all and %nobody with obvious
>         meaning.
> 
> 
>   <users>
> 
>         Comma-separated list of <user>s and <group>s.  Note that there
>         could be a whitespace after the comma.  E.g.:
> 
>                 alice, bob-johnson, %devel.
> 
> 
>   <files>
> 
>         Space-separated list of files in current directory (for the
>         "acl" subcommand) or from the top of repository (for the
>         "racl" subcommand).
> 
> 
>   <dirs>
> 
> 	Space-separated list of directories in current directory (for
> 	the "acl" subcommand) or from the top of repository (for the
> 	"racl" subcommand).  Each directory should have trailing
> 	"slash" character for clarity.
> 
> 
>   <file-perms>
> 
>         Comma-separated list of branch-level file permissions.  E.g.:
> 
>                 checkin
>                 checkout
> 
>         There are common aliases for that: "ci", "co".
> 
> 
>   <dir-perms>
> 
>         Comma-separated list of directory permissions.  E.g.:
> 
>                 access
>                 modify
> 
> 
>   <module-perms>
> 
>         Comma-separated list of module-level permissions.  E.g.:
> 
>                 tag
>                 tag:PREFIX
>                 branch
>                 branch:PREFIX   (questionable, but simple to
>                                  implement)
> 
>         The "tag:PREFIX" construct permits some user creating tags
>         with names starting from PREFIX.  Rationale: you could give
>         release engineer rights to create tags with names starting
>         from "RELEASE".  
> 
> 
> 
> Command lines for groups management:
> 
> a. Creating a group:
> 
> 	$ cvs group create <group>
> 
> 
> b. Deleting a group:
> 
> 	$ cvs group delete <group>
> 
>    Note that when you delete a group which is listed somewhere in ACLs
>    of some directory or a file it is not deleted from there: those
>    entries are just ignored.  This could turn out to be a caveat.
>    There should probably be an "ACL checker" that should be run from
>    time to time that cleans up obsolete entries.
> 
> 
> c. Adding users (or entire groups) to a group:
> 
> 	$ cvs group add <users>
> 
>    Note that adding of entire groups is "symlink-style", not
>    "copying-style".
> 
> 
> d. Deleting users (or entire groups) to a group:
> 
> 	$ cvs group remove <users>
> 
> 
> 
> 
> 
> Command lines for ACL management:
> 
> 
> Note that there are two flavours of the "acl" subcommand: "acl" and
> "racl".  The latter is used outside any working copy and requires that
> files and directory names be specified starting from the top-level
> repository directory.
> 
> 
> a. Setting ACL on files:
> 
>         $ cvs acl <users> <file-perms> <files>
> 
> 
> b. Setting ACL on directories:
> 
>         $ cvs acl <users> <dir-perms> <dirs>
> 
> 
> c. Setting default file ACLs:
> 
>         $ cvs acl <users> default::<file-perms> <dirs>
> 
>    (The "default::" line is used there verbatim.)
> 
> 
> d. Setting ACL on modules:
> 
>         $ cvs acl <users> <module-perms> <modules>
> 
> 
> Notes:
> 
> Please not that "recursive" operations are not implemented, and that's
> intentionally.  Use default file operations instead.  Remember that
> directory permissions are checked from the top.
> 
> 
> --alexm
> 
> _______________________________________________
> Cvs-nserver-devel mailing list
> Cvs...@li...
> https://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel

[RFC] proposed client command-line interface for dealing withACL

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

CVS CLIENT COMMAND-LINE INTERFACE TO ACL
=========================================


Notation used in this document:

  <user>

        CVS user name, a-la UNIX username.  E.g.:

                alice
                bob-johnson


  <group>

        CVS group name, a-la UNIX group, with leading "percent" (this
        is subject to discussion).  E.g.:

                %devel
                %support-staff

        There are special groups called %all and %nobody with obvious
        meaning.


  <users>

        Comma-separated list of <user>s and <group>s.  Note that there
        could be a whitespace after the comma.  E.g.:

                alice, bob-johnson, %devel.


  <files>

        Space-separated list of files in current directory (for the
        "acl" subcommand) or from the top of repository (for the
        "racl" subcommand).


  <dirs>

	Space-separated list of directories in current directory (for
	the "acl" subcommand) or from the top of repository (for the
	"racl" subcommand).  Each directory should have trailing
	"slash" character for clarity.


  <file-perms>

        Comma-separated list of branch-level file permissions.  E.g.:

                checkin
                checkout

        There are common aliases for that: "ci", "co".


  <dir-perms>

        Comma-separated list of directory permissions.  E.g.:

                access
                modify


  <module-perms>

        Comma-separated list of module-level permissions.  E.g.:

                tag
                tag:PREFIX
                branch
                branch:PREFIX   (questionable, but simple to
                                 implement)

        The "tag:PREFIX" construct permits some user creating tags
        with names starting from PREFIX.  Rationale: you could give
        release engineer rights to create tags with names starting
        from "RELEASE".  



Command lines for groups management:

a. Creating a group:

	$ cvs group create <group>


b. Deleting a group:

	$ cvs group delete <group>

   Note that when you delete a group which is listed somewhere in ACLs
   of some directory or a file it is not deleted from there: those
   entries are just ignored.  This could turn out to be a caveat.
   There should probably be an "ACL checker" that should be run from
   time to time that cleans up obsolete entries.


c. Adding users (or entire groups) to a group:

	$ cvs group add <users>

   Note that adding of entire groups is "symlink-style", not
   "copying-style".


d. Deleting users (or entire groups) to a group:

	$ cvs group remove <users>





Command lines for ACL management:


Note that there are two flavours of the "acl" subcommand: "acl" and
"racl".  The latter is used outside any working copy and requires that
files and directory names be specified starting from the top-level
repository directory.


a. Setting ACL on files:

        $ cvs acl <users> <file-perms> <files>


b. Setting ACL on directories:

        $ cvs acl <users> <dir-perms> <dirs>


c. Setting default file ACLs:

        $ cvs acl <users> default::<file-perms> <dirs>

   (The "default::" line is used there verbatim.)


d. Setting ACL on modules:

        $ cvs acl <users> <module-perms> <modules>


Notes:

Please not that "recursive" operations are not implemented, and that's
intentionally.  Use default file operations instead.  Remember that
directory permissions are checked from the top.


--alexm

ACL implementation comments

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

Hello,

I've started implementing ACLs.

The goals of implementation are rather strict and probably unusual,
and I'd very much like to keep it that way.  In short, I'm hooked on
one particular aspect of eXtreme Programming: Test First.

Everyone interested are encouraged to read

William C. Wake, "XP Explored":
http://users.vnet.net/wwake/xp/explored/XP-Explored.pdf

Ronald E. Jeffries, Ann Anderson and Chet Hendrickson, "XP Installed":
http://classes.seattleu.edu/computer_science/csse514/klawitter/pdf/xpinstalled.pdf


and follow the guidelines.  The ACL stuff is in the acl/ subdirectory.
Look especially at the check_acl.c and other check_*.c to get a clue
on what is the current functionality, and how do the tests look like.


As for the functional specification, you can take a look at the
current revision of /www/acl-rfc.txt from the project (soon to be
updated to Draft III).

As for the on-disk structures, I don't think that's important
currently.  It probably will be subject to discussion a couple of
weeks from now, when there will be a need to keep backwards
compatibility.  Anyway, the format is designed to be simple, and
simply extensible:

  branch-level ACLs are kept in `ACL' file in each directory.  File is
  of the following format: 

<space>filename\t	branch\t	username\t	rights...

  the leading <space> is exactly a means of extensibility.  When new
  kinds of records will be needed, we'll just use another character
  instead.  See the data-file format of djbdns.

I don't think there will be a strong need to create any indices over
that file (given that 95% of permissions will be handled by
directory-level ACLs), but if it'll ever be needed, we'll always be
able to do just that, with a lot of tests supporting that change.


To properly test user-level operations, we'll need to finally create
Autotest-based testsuite for the client binary (and its server
counterpart).  It is a nice task in itself (and I think that stock CVS
will gladly accept if it's going to be backported there), so if
somebody needs something to work on -- here it is.

A yet another "dynamic strings" structure is created in a form of
"stringbuf.h".  I don't think it will ever need a lot of
functionality, so don't bother extending it without a clear need (and
tests first, sure).


Comments?

--alexm

Re: preliminary SSL client

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

>>>>> "m" == minyard  <mi...@ac...> writes:

m> Ok, I've looked through the code, and I see you are not doing any
m> certificate verification.  I believe you have to add a call to:
m> SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); on the context
m> before doing anything.

Whoa!  'Twas all my fault.  Basically the patch is: 

     while (len > 0) {
        int n = SSL_read(ssl, buf + nread, len);
 
-       long ssl_err = SSL_get_error(ssl, nread);
+       long ssl_err = SSL_get_error(ssl, n);
        if (ssl_err == SSL_ERROR_ZERO_RETURN)
            break;

It passes simple tests with stunnelled cvs pserver.  More details to
follow.

--alexm

Re: preliminary SSL client

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

Alexey Mahotkin <al...@hs...> writes:
> m> However, I didn't see any server code in your stuff, so I assume
> m> you are using my server for this?  
> 
> No, I decided very long ago to do the first minimal implementation of
> SSLified server with a help from stunnel, so only the client needs
> actual SSL code inside.

Ah, stunnel is an external application.  I didn't know about that.

> 
> I think that's going to be rather useful setup anyways.  However, this
> scheme allows only server certificates verification.  There is a
> demand for client certificate verification (w/o the login/password at
> all), and that will be implemented too some day (and would require
> minimal changes in client code, I believe).

I've spent some time thinking about this.  The big pain will be key
management for all the users, you will have to store the key in
something like a password file or some database and look up the key by
username.  The users will have to generate keys, and changing their
key will be a pain (although you could probably devise some way to
transfer it).  But it would be more secure than the password version.

-Corey

Re: preliminary SSL client

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

>>>>> "m" == minyard  <mi...@ac...> writes:

m> Ok, I've looked through the code, and I see you are not doing any
m> certificate verification.  I believe you have to add a call to:
m> SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL); on the context
m> before doing anything.

Ah, thanks, I'll try that. 

m> However, I didn't see any server code in your stuff, so I assume
m> you are using my server for this?  

No, I decided very long ago to do the first minimal implementation of
SSLified server with a help from stunnel, so only the client needs
actual SSL code inside.

I think that's going to be rather useful setup anyways.  However, this
scheme allows only server certificates verification.  There is a
demand for client certificate verification (w/o the login/password at
all), and that will be implemented too some day (and would require
minimal changes in client code, I believe).

--alexm

Re: preliminary SSL client

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

Ok, I've looked through the code, and I see you are not doing any
certificate verification.  I believe you have to add a call to:
   SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, NULL);
on the context before doing anything.

However, I didn't see any server code in your stuff, so I assume you
are using my server for this?  The above won't work in that case,
becase the server will expect certificate authentication, you would
have to do the previous call on the server, also.  It would probably
be easier to just add the certificate stuff.  It's not hard to create
a certificate, the directions are in my changes to the documentation.

-Corey

Alexey Mahotkin <al...@hs...> writes:

> Hello,
> 
> I've committed preliminary SSL client implementation.  On server side
> you have to use stunnel.  I think that this is rather useful setup
> even without client certificates (which will be implemented later).
> 
> Corey, I was looking at your sources when creating it.  It currently
> writes ok (I've checked with recordio), and the stunnelled cvs-pserver
> writes back "I LOVE YOU" ok, but the client dies with:
> 
> Logging in to :pserver:alexm@localhost:22401/repos
> CVS password: 
> Entered internal_start_server
> Created socket_client: 0x80d4100
> Created ssl_client: 0x80d4138
> Entered ssl_connect()
> ssl_write(27)
> ssl_write(6)
> ssl_write(1)
> ssl_write(5)
> ssl_write(1)
> ssl_write(4)
> ssl_write(1)
> ssl_write(25)
> ssl_read(1)
> Could not read SSL data: bad asn1 object header
> 
> The ssl_write()s are the "BEGIN AUTH REQUEST user password repository
> END AUTH REQUEST".
> 
> Corey, if you could look at it and say if I've missed something
> crucial, it would be great.  I'll also look at fetchmail
> implementation, but maybe I'm just overlooking something tiny. 
> 
> --alexm
> 
> _______________________________________________
> Cvs-nserver-devel mailing list
> Cvs...@li...
> http://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel

Re: preliminary SSL client

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

>>>>> "m" == minyard  <mi...@ac...> writes:

>> Did you checked out with -r CVS-1-11-1?
>> 
>> Yes, I did, and I double checked.  I searched everything for SSL
>> and stunnel, and I couldn't find anything.

m> Ok, I figured it out.  It's NSERVER-1-11-1-1 that I need to check
m> out.  There seems to be stuff there.

Corey!!!   It has to be something with Freud, but I told you wrong tag
name (twice, it seems).

The correct branch tag is `NCLI-1-11-1'.   Here is double check:

(insert-file (expand-file-name "~/cvs-ncli/CVS/Tag"))TNCLI-1-11-1

Sorry!

--alexm

Re: preliminary SSL client

[<mo...@no...>]

08/25/2001 08:48:40 cvs-nserver-devel-admin wrote:
>> > Yes, I did, and I double checked.  I searched everything for SSL and
>> > stunnel, and I couldn't find anything.
>>
>> Ok, I figured it out.  It's NSERVER-1-11-1-1 that I need to check out.
>> There seems to be stuff there.
>
>Ok, that's not it.  What tag should I use to get the SSL stuff?
I guess NCLI-1-11-1 branch. At least I see all the new stuff included there
:-)

Yours, Alexey

Re: preliminary SSL client

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

mi...@ac... writes:

> mi...@ac... writes:
> > Alexey Mahotkin <al...@hs...> writes:
> > 
> > > >>>>> "m" == minyard  <mi...@ac...> writes:
> > > 
> > > m> I did a "cvs update" from SourceForge and I didn't get any changes,
> > > m> and I looked through the logs and I didn't see anything.
> > > 
> > > Hm.  Did you checked out with -r CVS-1-11-1? 
> > 
> > Yes, I did, and I double checked.  I searched everything for SSL and
> > stunnel, and I couldn't find anything.
> 
> Ok, I figured it out.  It's NSERVER-1-11-1-1 that I need to check out.
> There seems to be stuff there.

Ok, that's not it.  What tag should I use to get the SSL stuff?

-Corey

Re: preliminary SSL client

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

mi...@ac... writes:

> Sorry I've been so long, but I have just taken a voluntary layoff an
> where I work, and things have been pretty chaotic.  I should have some
> free time soon :-).
> 
> Alexey Mahotkin <al...@hs...> writes:
> 
> > >>>>> "m" == minyard  <mi...@ac...> writes:
> > 
> > m> I did a "cvs update" from SourceForge and I didn't get any changes,
> > m> and I looked through the logs and I didn't see anything.
> > 
> > Hm.  Did you checked out with -r CVS-1-11-1? 
> 
> Yes, I did, and I double checked.  I searched everything for SSL and
> stunnel, and I couldn't find anything.

Ok, I figured it out.  It's NSERVER-1-11-1-1 that I need to check out.
There seems to be stuff there.

-Corey

Re: preliminary SSL client

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

Sorry I've been so long, but I have just taken a voluntary layoff an
where I work, and things have been pretty chaotic.  I should have some
free time soon :-).

Alexey Mahotkin <al...@hs...> writes:

> >>>>> "m" == minyard  <mi...@ac...> writes:
> 
> m> I did a "cvs update" from SourceForge and I didn't get any changes,
> m> and I looked through the logs and I didn't see anything.
> 
> Hm.  Did you checked out with -r CVS-1-11-1? 

Yes, I did, and I double checked.  I searched everything for SSL and
stunnel, and I couldn't find anything.

> 
> m> Anyway, a few things I learned while playing with OpenSSL:
> 
> Hm.   Scary :)

Yes, it is.  The documentation on OpenSSL really sucks, and it seems
to be kind of frail.

-Corey

Re: preliminary SSL client

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

>>>>> "m" == minyard  <mi...@ac...> writes:

m> I did a "cvs update" from SourceForge and I didn't get any changes,
m> and I looked through the logs and I didn't see anything.

Hm.  Did you checked out with -r CVS-1-11-1? 

m> Anyway, a few things I learned while playing with OpenSSL:

Hm.   Scary :)

--alexm

Re: preliminary SSL client

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

I did a "cvs update" from SourceForge and I didn't get any changes,
and I looked through the logs and I didn't see anything.

Anyway, a few things I learned while playing with OpenSSL:

You have to be VERY careful using openssl to get everything right.
Even the slightest deviation can cause wierd problems that are
difficult to explain and debug.  So when copying my stuff, any
deviation is suspect, OpenSSL expects you to do everything in just the
order it wants.

I assume to created valid certificates and installed them in the right
place.  Figuring out how to do this took as much time as it took me to
write the code.  The instructions for creating the certificates are in
the documentation changes I made.  I assume you did this and copied my
code about loading the certificates, since I doubt you would have
gotten this far, but just in case.

Also, make sure you don't use the socket for anything else after you
connect it to the SSL stuff.

When the changes get into the repository, I'll look at them.

-Corey

Alexey Mahotkin <al...@hs...> writes:

> Hello,
> 
> I've committed preliminary SSL client implementation.  On server side
> you have to use stunnel.  I think that this is rather useful setup
> even without client certificates (which will be implemented later).
> 
> Corey, I was looking at your sources when creating it.  It currently
> writes ok (I've checked with recordio), and the stunnelled cvs-pserver
> writes back "I LOVE YOU" ok, but the client dies with:
> 
> Logging in to :pserver:alexm@localhost:22401/repos
> CVS password: 
> Entered internal_start_server
> Created socket_client: 0x80d4100
> Created ssl_client: 0x80d4138
> Entered ssl_connect()
> ssl_write(27)
> ssl_write(6)
> ssl_write(1)
> ssl_write(5)
> ssl_write(1)
> ssl_write(4)
> ssl_write(1)
> ssl_write(25)
> ssl_read(1)
> Could not read SSL data: bad asn1 object header
> 
> The ssl_write()s are the "BEGIN AUTH REQUEST user password repository
> END AUTH REQUEST".
> 
> Corey, if you could look at it and say if I've missed something
> crucial, it would be great.  I'll also look at fetchmail
> implementation, but maybe I'm just overlooking something tiny. 
> 
> --alexm
> 
> _______________________________________________
> Cvs-nserver-devel mailing list
> Cvs...@li...
> http://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel

cvs-nserver-commits@lists.sourceforge.net mailing list

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

Hello,

it seems like I've created a mailing list for automatic CVS commit
reports.  If you'd like to subcribe, visit the

  http://lists.sourceforge.net/lists/listinfo/cvs-nserver-commits

--alexm

preliminary SSL client

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

Hello,

I've committed preliminary SSL client implementation.  On server side
you have to use stunnel.  I think that this is rather useful setup
even without client certificates (which will be implemented later).

Corey, I was looking at your sources when creating it.  It currently
writes ok (I've checked with recordio), and the stunnelled cvs-pserver
writes back "I LOVE YOU" ok, but the client dies with:

Logging in to :pserver:alexm@localhost:22401/repos
CVS password: 
Entered internal_start_server
Created socket_client: 0x80d4100
Created ssl_client: 0x80d4138
Entered ssl_connect()
ssl_write(27)
ssl_write(6)
ssl_write(1)
ssl_write(5)
ssl_write(1)
ssl_write(4)
ssl_write(1)
ssl_write(25)
ssl_read(1)
Could not read SSL data: bad asn1 object header

The ssl_write()s are the "BEGIN AUTH REQUEST user password repository
END AUTH REQUEST".

Corey, if you could look at it and say if I've missed something
crucial, it would be great.  I'll also look at fetchmail
implementation, but maybe I'm just overlooking something tiny. 

--alexm

Re: [RFC Draft] ACL in CVS proposal

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

mo...@no... writes:

> >> Should it be 'module administrators'? Or maybe it would be useful to add
> >> another type of action on ACL: 'allow to modify ACL [for a particular
> >> file/module/branch/etc]?'
> >If you are saying that we should allow something more fine-grained
> >(permission to make branches, permission to change ACLs), that's fine,
> >I agree that it could be useful; better than a simple owner.
> Yes, that's exactly what I mean. Yesterday we had an IRC session w/ Alex
> Mahotkin (sorry, mostly in Russian :-/), generally he agreed to extend list
> of actions that need to be ACLed and now he works on the new draft.

I wish I spoke Russian, and I also wish I spoke many other languages :-(.

> 
> >> Should it be the only person or each module/branch etc can have its own
> >> administrator?
> 
> >Someone needs access to the repository with the ability to do
> >anything, and the verification needs to be done outside the normal ACL
> >verification (so if the ACLs accidentally get deleted or set wrong,
> >they can still work on the repository).
> Well, do you think that should be a superuser inside CVS [repository] (on
> per-repostitory basis)? Maybe we can just create several small maintainance
> programs for system administrator (in fact it should be enough to run these
> programs from within 'repository owner' system account) to perform rescue
> actions (like ACL recreation etc). I think this would ease and decrease
> amount of work needed.

It's actually quite easy to make an superuser type login in CVS, much
easier than writing independent programs.  When checking permissions,
just scan the admin file first and return "true" for any check if the
user is an admin.  I'm not sure about which would be more secure.  We
have administrators that I don't want to give access to the machine's
filesystem, but my situation is probably the exception, not the rule.

-Corey

Updates

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

>>>>> "m" == morozov  <mo...@no...> writes:

m> src/rsh-client now fits Alex's specifications (but Alex please
m> check it, you're the only person who reached Zen at the moment
m> :-)). I'm not sure it works perfectly but it definitely compiles
m> :-).

Comments: 

- always try to check the diffs before commiting.  That way we'll get
  rid of committed conflicts, false diffs, etc., etc.;

- we don't need no K&R C given the "ansi2knr" option of Automake;  I
  hope the whole CVS will switch to ANSI C over time;

- always add comment headers to the files;

- always try to update first before starting to do any changes. 


I've updated rsh-client and basic-fd-client as per that suggestions
and commited.  The socket-client still does not use the
basic-fd-client, that is going to be fixed.


m> Alex please tell me what versions of automake, libtool, autoconf
m> etc are "kosher" to be used in developemnt. I got numerous warnings
m> that I don't have automake of a correct version (I have 1.4, while
m> 1.4a is needed); 'make' causes ./configure to re-run even if I
m> successfully run it just before make etc.

You absolutely need Automake 1.4h (or later, _not_ 1.4pX); Autoconf
2.13 (we'll need 2.50 when stock CVS switches to it, and not earlier).

	http://sources.redhat.com/automake/

Use Redhat mirrors, not GNU mirrors to download.

--alexm