cvs-nserver-devel — Developers

Re: Possible bug in cvs log/rlog command

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

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

 AM> Either I can't understand cvs log syntax completely or it has a bug in
 AM> -w switch processing. As I read in dox I should write smth like this
 AM> if I want to get both tyranny's and morozov's commits for src/ls.c:

Genuine off-by-one error:

Index: log.c
===================================================================
RCS file: /cvsroot/cvs-nserver/cvs-nserver/src/log.c,v
retrieving revision 1.1.1.6.4.5
diff -u -r1.1.1.6.4.5 log.c
--- log.c       25 Nov 2001 20:45:30 -0000      1.1.1.6.4.5
+++ log.c       14 May 2002 21:32:16 -0000
@@ -747,7 +747,7 @@
            len = cp - argstring;
            p->key = xmalloc (len + 1);
            strncpy (p->key, argstring, len);
-           p->key[len + 1] = '\0';
+           p->key[len] = '\0';
        }
 
        if (*plist == NULL)


I'm very impressed :)

--alexm

Re: Possible bug in cvs log/rlog command

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

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

 AM> Either I can't understand cvs log syntax completely or it has a bug in
 AM> -w switch processing. As I read in dox I should write smth like this
 AM> if I want to get both tyranny's and morozov's commits for src/ls.c:

 AM> alex@sig ncvs/cvs-nserver.clean/src $ cvs rlog -wtyranny,morozov
 AM> cvs-nserver/src/ls.c


 AM> But I get only morozov's commits this way...

Wow!  That's very interesting.

First, this bug appears in stock CVS 1.10.7 too.

Here is the excerpt from the log (what is sent to server:

Argument -wmorozov@
Argument -wtyranny
Directory .
/cvsroot/cvs-nserver/cvs-nserver/src
Sticky TNCLI-1-11-1
Entry /ls.c/1.1.2.12///TNCLI-1-11-1
Unchanged ls.c
Argument ls.c
log


I do not know what does "@" means and if it's correct.  I think someone
needs to do some debugging output and see.  Alex?  Or I could do that some
time.

I believe this is a bug.

--alexm

Re: build environment

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

>>>>> "NP" == Nick Papadonis <ni...@co...> writes:

 NP> What is the build environment people use for branch NCLI-1-11-1?  I'm
 NP> trying to build with RH 7.2 and RH's Kerberos package installed in
 NP> /usr/kerberos.  It appears client.c and server.c are having build
 NP> problems:

Kerberos and GSSAPI are effectively "broken" in the cvs-nserver currently:
I do not know both these packages, and there were no requests for
implementation, and no need for us to support it.


Ideally, someone would write proper cvs-kserver.c and cvs-gserver.c, which
fit into the idea of cvs-nserver's protocol front-ends and checkpassword
authenticators (see the Administrator's Guide).  After that the old
Kerberos/GSSAPI code would be thrown out of the server.c. 


As a workaround, I think it could be easy to bring back the compilation of
Kerberos, if you really have something to compile against (I do not, though
I plan to install fresh RedHat and try Kerberos out some day).  I think the
problem is with a couple of headers (and need to bring back the
switch_to_user() from the stock CVS, which was thrown out and now regularly
screws up compilation on RedHat machines ;).


So if you are able to help with Kerberos/GSSAPI -- that would be greatly
appreciated, and I could certainly provide you with advice on that.  That's
a task that waits for volunteers for a long time.


So it is,

--alexm

build environment

[Nick P. <ni...@co...>]

What is the build environment people use for branch NCLI-1-11-1?

I'm trying to build with RH 7.2 and RH's Kerberos package installed in
/usr/kerberos.  It appears client.c and server.c are having build
problems:

I assume them having to do with the directives:
HAVE_KERBEROS
HAVE_GSSAPI
KERBEROS_SUPPORT

make[4]: Entering directory `/home/nick/build/cvs/nserver/cvs-nserver/src'
source='client.c' object='client.o' libtool=no \
depfile='.deps/client.Po' tmpdepfile='.deps/client.TPo' \
depmode=gcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../lib -I../diff -I../acl -I/usr/kerberos/include -I/usr/kerberos/include    -g -O2 -c `test -f client.c || echo './'`client.c
client.c:98: parse error before `kblock'
client.c:98: warning: data definition has no type or storage class


What verison of Kerberos are you compiling against?

I would dig in but people here seem to be in touch 
with this branch.

Any insight appreciated.

Thanks

- Nick

Possible bug in cvs log/rlog command

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

Either I can't understand cvs log syntax completely or it has a bug in
-w switch processing. As I read in dox I should write smth like this if
I want to get both tyranny's and morozov's commits for src/ls.c:

alex@sig ncvs/cvs-nserver.clean/src $ cvs rlog -wtyranny,morozov cvs-nserver/src/ls.c


But I get only morozov's commits this way...

Re: ls*, markup and other things

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

=F7 =FE=D4=D7, 09.05.2002, =D7 20:01, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
> Now, I think that XML is viable option (of course, not via full libxml,
> simply printf-style ;).
Sure. we don't need XML parsing at all. Just printf("<some=20
attribute=3D"value">\n") instead of printf("some attribute was assigned to
value eventually\n") :-))

> So, the server-side XML handling is very simple, while the client-side XM=
L
The only thing we need is some kind of URL escaping (probably
simplified, just % -> %25, " -> %22, > -> %3E, hmm, looks that's enough
for everything (C):-))

> handling is completely standalone and we should not bother about _its_
> bloat.
Somebody shouldn't, somebody should :-)

> Currently Alex is the primary customer of the 'cvs lsacl' command and it
> seems to me he hates its output :)
A-a-a-ah, "dislike" :-)

Re: lsmodules.c warnings

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

=F7 =F0=D4=CE, 10.05.2002, =D7 01:18, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
> One of them "i could be used w/o initialization", seems to me rather
> nasty.  I've did local fixes to it, but you'd better look into it
> yourself.
Fixed. Stupid cut-n-paste technique :-)

Re: ls*, markup and other things

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

=F7 =F0=D4=CE, 10.05.2002, =D7 07:01, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
> Huh?  You mean purging intermediate revisions that are, say, older than
> certain date?  This could be done simply with 'cvs admin -o' (an option
> inherited from the RCS).
Well, almost but not completely. One needs to be able to save parts of
rcs files that are going to be removed and be able to restore them upon
a request... Well, I understand that this functionality shouldn't be put
into server but rather into admin scripts instead.

> Of course, that's maybe kind of extreme to do this, though maybe
> practical.
>=20
>=20
> In the long term rewriting of librcs could be considered, surely :) It
> could create all sorts of temporary files and indices near the master
> ,v-file.  I do not think that such decision should be taken lightly, thou=
gh
> it could have a lot of advantages.
:-). The Proper Way is not a light thing anyway :-)

Re: ls*, markup and other things

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

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

 AM> A while ago my Novosoft bosses (actually it's Marod :-)) told that
 AM> would be fine to have a workaround against one well-known cvs (librcs)
 AM> bottleneck: when file processing time dramatically increases when
 AM> there're long/complicated commit history. One possible solution for
 AM> the problem is to implement (in a separated utility) a kind of
 AM> purge/merge operation. This will allow us to remain compatible w/
 AM> stock cvs and solve some of the problems. The question: is there
 AM> another, more convenient way? Or we should change the repository
 AM> format instead and solve the problem completely?..

Huh?  You mean purging intermediate revisions that are, say, older than
certain date?  This could be done simply with 'cvs admin -o' (an option
inherited from the RCS).


man rcs:

       -orange
              deletes ("outdates") the revisions given by  range.
              A  range  consisting  of  a  single revision number
              means that  revision.   A  range  consisting  of  a
              branch  number  means  the  latest revision on that
              branch.  A range of the form rev1:rev2 means  revi╜
              sions  rev1  to rev2 on the same branch, :rev means
              from the beginning of the branch containing rev  up
              to  and including rev, and rev: means from revision
              rev to the end of the branch containing rev.   None
              of  the  outdated  revisions  can  have branches or
              locks.


Of course, that's maybe kind of extreme to do this, though maybe
practical.


In the long term rewriting of librcs could be considered, surely :) It
could create all sorts of temporary files and indices near the master
,v-file.  I do not think that such decision should be taken lightly, though
it could have a lot of advantages.

--alexm

CVSROOT/nval-tags and cvs lstags

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

Hello,

here is what I've done:

new administrative file is introduced in repository:
CVSROOT/nval-tags.  It is analogous to CVSROOT/val-tags, only it
contains much more information about tags.

This text file contains lines of the following simple format:

BBRANCH_NAME PARENT_BRANCH username timestamp
TTAG_NAME PARENT_BRANCH username timestamp

(adding the "V"-lines, for vendor branches, is being considered).


The 'cvs rtag' subcommand is enhanced so that the server updates this
file with each new tag or branch created in the repository.


cvs lstags
-----------

The new 'cvs lstags' subcommand simply transfers this file to the
client verbatim.  The primary users of this subcommand are various
web-based repository interface a-la viewcvs.cgi.  They get the ability
to display more accurate tree of tags and branches, and are able to do
that extremely quickly.


init-nval-tags.pl
------------------

The 'init-nval-tags.pl' script is provided which scans the existing
repository and gathers tag information, using the RCS 'rlog' program.
It then dumps this information using the nval-tags format.  This
script could be used to initialize the repository for using the new
nval-tags.

This script tries to deduce the correct parent of each tag, however
this could only be a guess because of the RCS legacy in CVS.  Also, it
does not (and could not) handle cases where there is a tag and a
branch with the same name in various parts of repository (it simply
takes the first which it stumbles upon, ignoring others).


legacy
-------

The CVSROOT/val-tags is still handled.  However, it is expected that
the support for this file will be dumped.

--alexm

lsmodules.c warnings

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

Alex, please take a look at warnings in lsmodules.c, which are
produced by the (recommended) command-line: 

CFLAGS="-Wall -W -Wmissing-prototypes -Wstrict-prototypes -O2 -g" ./configure --enable-maintainer-mode


One of them "i could be used w/o initialization", seems to me rather
nasty.  I've did local fixes to it, but you'd better look into it
yourself.

Thanks, 

--alexm

cvs lstags support

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

hello,

I've almost completed the implementation of 'cvs lstags'.

Two things that are missing now are:

  - locking (but the CVSROOT/val-tags is not lock-protected anyway ;)
    Though this will be done actually.

  - how to properly authorize the 'cvs lstags'?  I think that if the
    user is allowed to access the 'CVSROOT' module, then she must be
    allowed to do 'cvs lstags';

    What do you think?

    The one drawback for this plan is that we do not have the "access"
    module-level permission :) Maybe it's time to think if we need one
    or if could get away with directory-level permissions on
    'CVSROOT/' subdirectory?


I'll do a couple more fixes bit later, and I MUST DOCUMENT THIS I MUST
DOCUMENT THIS I MUST DOCUMENT THIS.

--alexm

SSL certificates (was: ACL status?)

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

=F7 =FE=D4=D7, 09.05.2002, =D7 16:32, Alberto Dainotti =CE=C1=D0=C9=D3=C1=
=CC:
> On 8 May 2002, Alexey Morozov wrote:
>=20
> > BTW, it's another task: implement SSL certificates management, if
> > there're volunteers for it, I think Alex wouldn't mind :-)
>=20
> If you are talking about cvs-nserver
Sure, nserver. WinCVS has a little to do w/ it: just a configuration or
prompt dialog where a user can specify which file to use as certificate.
It's not a big problem generally.

> and not about wincvs may be I could
> carry it..
It would be really nice.
> What do we need exactly , other than solve the discussed
> selfsigned/expired/etc. certificates problem ?
Well, these are more interesting tasks and they should be carefully
thought... Unfortunately it looks like we have no 'instant' experience
for the subject...

Re: ACL status?

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

=F7 =FE=D4=D7, 09.05.2002, =D7 20:06, Alexey Mahotkin =CE=C1=D0=C9=D3=C1=CC=
:
> Is it that cvs-specific?   I thought your Lotus Notes or whatever does LD=
AP
> for you or something similar will take care of this?=20
Well, Lotus Notes assigns an id file for each user, this file has /some
kind/ of certificate (as our local LN gurus told) but it's in
proprietary format and can't be used as SSL certificate [directly]. Our
LDAP has usual "password" authentication (possibly over SSL-encrypted
channel) but w/o any user certificates....

Re: ACL status?

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

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

 AM> Heh, WinCVS is just a wrapper for command-line cvs which supports SSL
 AM> already (at least for Cygwin build). So we get the support
 AM> automatically (maybe except user-friendly interface for certificate
 AM> management) but for the moment I have no idea yet how this will be
 AM> implemented by Alex.  BTW, it's another task: implement SSL
 AM> certificates management, if there're volunteers for it, 

Is it that cvs-specific?   I thought your Lotus Notes or whatever does LDAP
for you or something similar will take care of this? 

 AM> I think Alex wouldn't mind :-)

--alexm

Re: ls*, markup and other things

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

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

 AM> Technically speaking a carefully designed and well-defined XML DTD
 AM> doesn't give the server too much additional work. / and // used now as
 AM> separators will be changed to number of <> " etc...

 AM> Probably there's a better solution though... Any suugestions?

We could start with formal definition of how are the ACLs stored in
repository, on abstract level.  I must admit that 'cvs lsacl' is totally ad
hoc, because it does not take into account the module-level ACLs and the
repository policy.

 AM> tools/. Tomorrow morning I'll start to commit things so everyone is
 AM> welcome to test and improve.  Particularly improvements will be needed
 AM> for System::Account module which helps to create system accounts (via
 AM> call to appropriate system tools like useradd). Different systems are
 AM> supported via in-module database which describes tools names and
 AM> switches. I added support for linux/redhat account tools (useradd and
 AM> groupadd), support for other system is still missing but hopefully
 AM> easy to add.

Please write some wrap-up of the web-interface: how to set it up,
basically.  After that somebody will take a look at it wrt making it more
"redistributable".


We need the release!  :)  1.11.1.53 will be broken, that's for sure. 

--alexm

Re: ls*, markup and other things

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

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

 AM> There's an issue I want to discuss though. Current format of ls*
 AM> commands are humanly readable and understandable but they can be more,
 AM> hmm, formalized or smth (especially lsacl, but ls also has portability
 AM> bottlenecks and so on). So my question is: do we need these commands
 AM> to have an, hmm, XML-like output? If yes, what's the DTD? There're
 AM> pros (we won't need an unique parser for each command) and cons (the
 AM> server code needs to be more complex, there will be greater output
 AM> size and so on) so final decision should be carefully discussed.

 WJ> I don't think output of XML-like format is good. The pros doesn't buy
 WJ> cons.

Well, first I too was against the XML.

Now, I think that XML is viable option (of course, not via full libxml,
simply printf-style ;).

The thing is that the recipients of the 'cvs lsacl' command are usually
some web front-ends, which are written in Perl as the very least (but could
be simply done with Java/XSLT, if needed (so we could do the direct
transformation of the ACLs to webpage!)).  I hope that Perl finally caught
up with XML parsing with Java at last (AFAIH, two years ago it was almost
inadequate).

So, the server-side XML handling is very simple, while the client-side XML
handling is completely standalone and we should not bother about _its_
bloat.

Currently Alex is the primary customer of the 'cvs lsacl' command and it
seems to me he hates its output :)

--alexm

Re: ACL status?

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

>>>>> "NP" == Nick Papadonis <ni...@co...> writes:

 NP> Does anyone know the status of the ACL implementation?  

I do! =)

 NP> What is left?

Actual real-life usage. :) It all went theoretically ok, until Alex
installed and actually tried it.  Then we found the need for the
"repository policy".  That's just an example.  I am pretty sure we'll found
more of those things as the usage will expand (although no release yet,
alas!)


So, you should use the NCLI-1-11-1 branch.  Read the acl-rfc.txt on the
project homepage and see the help on 'cvs acl' and 'cvs racl' subcommands
(the acl-cli.txt is somewhat out of date, and I'll simply merge it with the
Admin Guide).

 NP> IMHO the community is in dire need of this feature.

 NP> I would be willing to help wrap this up.

Just try it out and report feedback.  


Thanks,

--alexm

Re: ACL status?

[Alberto D. <al...@ur...>]

On 8 May 2002, Alexey Morozov wrote:

> BTW, it's another task: implement SSL certificates management, if
> there're volunteers for it, I think Alex wouldn't mind :-)

If you are talking about cvs-nserver and not about wincvs may be I could
carry it..
What do we need exactly , other than solve the discussed
selfsigned/expired/etc. certificates problem ?



Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

Re: ACL status?

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

=F7 =F3=D2=C4, 08.05.2002, =D7 20:41, Alberto Dainotti =CE=C1=D0=C9=D3=C1=
=CC:
> On 8 May 2002, Alexey Morozov wrote:
>=20
> > > What is left?  IMHO the community is in dire need of this feature.
> > The nice web configuration tools and support for ACL management from
> > within WinCVS:-)
> And adding ssl capabilities to WinCVS ! :-)
Heh, WinCVS is just a wrapper for command-line cvs which supports SSL
already (at least for Cygwin build). So we get the support automatically
(maybe except user-friendly interface for certificate management) but
for the moment I have no idea yet how this will be implemented by Alex.
BTW, it's another task: implement SSL certificates management, if
there're volunteers for it, I think Alex wouldn't mind :-)

Re: ACL status?

[Alberto D. <al...@ur...>]

On 8 May 2002, Alexey Morozov wrote:

> > What is left?  IMHO the community is in dire need of this feature.
> The nice web configuration tools and support for ACL management from
> within WinCVS:-)

And adding ssl capabilities to WinCVS ! :-)



Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

INSTALL-nserver

[Alberto D. <al...@ur...>]

few fixes attached. Those errors could be confusing for a
first-time user.



Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

Re: self signed certificates patch

[Alberto D. <al...@ur...>]

On Sun, 5 May 2002, Alexey Mahotkin wrote:

> I do not remember, has the CVS client reached the point where we should
> think about extending the ~/.cvsrc to a more generic configuration
> facility, not only for the default command-line options?
>
> If we'd push the issue towards the OpenSSL configuration -- that's fine.
> Otherwise, we'd have to think about the more generic configuration.

Let's bring up the question to the open-ssl guys and let's wait
to see what happens.. As we said before the problem should be solved
there and not in cvs. Otherwise I agree that .cvsrc would be better
than using enivonment variables.


Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

Re: self signed certificates patch

[Alberto D. <al...@ur...>]

On Sun, 5 May 2002, Alexey Mahotkin wrote:

> As far as I can tell, there are several common situation which should be
> handled by any SSL client, and some of them should have some kind of user
> option for what to do with them:
>
> - self-signed certificates;
>
> - expired certificates;
>
> - unknown CA;
>
> - maybe there's more which I don't remember now.
>
>
> Browsers commonly allow to override decisions for each particular
> situation, asking user about what to do with this: cancel or continue
> connecting.
>
> I believe that we would have to deal with this somehow earlier or later, so
> let's try to preliminarily discuss it.
>
>
> *** below goes some rough draft on that issue ***
>
> There must be some common extendable facility provinding the
> site-level/user-level SSL policy.  Each and every SSL client should consult
> this facility and act accordingly.
>
> This could be done with a couple of configuration files, something like
> /etc/ssl-policy.conf and ~/.ssl-policy.conf, containing lines like that:
>
>    self-signed-certificates: allow
>    expired-certificates: ask
>    unknown-ca: deny
>
> etc.  User-level configuration file could override the site-level
> configuration file towards more strictness.
>
>
> I think there should be some provisions for that in OpenSSL, but quick
> glance over /etc/ssl/openssl.cnf didn't uncover any.  Maybe it should be
> discussed with OpenSSL folks, cleaned up, and used consistently.
>
>
> Oh lord I remember how I was subscribed to openssl-dev.  That was pain.
> But something should be done about this.
>
>
> Your thoughts?   I do not think that any short-cuts will suffice.
>
> --alexm


I totally agree with you ! This is the right way to do it.



Alberto Dainotti
URIZEN - Internetworking & Digital Security    http://www.urizen.it
PGP Key available at: http://www.urizen.it/pgp
Key Fingerprint: 87CF D95A CE0F 3188 3950  4B1F 3B56 DE69 D05F B8F5

Re: ACL status?

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

=F7 =F3=D2=C4, 08.05.2002, =D7 01:34, Nick Papadonis =CE=C1=D0=C9=D3=C1=CC:
> Does anyone know the status of the ACL implementation?
Well, it works :-). At least in the development (NCLI-1-11-1 branch
version which is quite stable for the moment IMHO)

> What is left?  IMHO the community is in dire need of this feature.
The nice web configuration tools and support for ACL management from
within WinCVS:-)

> I would be willing to help wrap this up.
Well, actually you can help in patching WinCVS and other cvs front-ends
(see http://cvsgui.sf.net and so on). The server part is on place
already... Now I'm preparting a bunch of tools (cvs-group,
cvs-repository) (in fact just a frontend for 'cvs init' command and
CVSROOT/cvsgroup file) and there's a task to build cvs binary on Windows
platform using MSVC (it's built almost automatically using cygwin
libraries but should be also built (w/o server support at least) in
MSVC6+...