RE: Log data for branches
I have been meaning to get this back to Karl Fogel. This is what
we did:
===
RCS file: /system/cvsroot/buildsvc/src/cvs2cl.pl,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** buildsvc/src/cvs2cl.pl2002/05/21 19:20:541.1
--- buildsvc/src/cvs2cl.pl2002/11/22 21:29:491.2
***
*** 8,15
######
##
! ## $Revision: 1.1 $
! ## $Date: 2002/05/21 19:20:54 $
## $Author: rhb $
##
## (C) 1999 Karl Fogel <[EMAIL PROTECTED]>, under the GNU GPL.
--- 8,15
######
##
! ## $Revision: 1.2 $
! ## $Date: 2002/11/22 21:29:49 $
## $Author: rhb $
##
## (C) 1999 Karl Fogel <[EMAIL PROTECTED]>, under the GNU GPL.
***
*** 78,84
my $Log_Source_Command = "cvs log";
# In case we have to print it out:
! my $VERSION = '$Revision: 1.1 $';
$VERSION =~ s/\S+\s+(\S+)\s+\S+/$1/;
## Vars set by options:
--- 78,84
my $Log_Source_Command = "cvs log";
# In case we have to print it out:
! my $VERSION = '$Revision: 1.2 $';
$VERSION =~ s/\S+\s+(\S+)\s+\S+/$1/;
## Vars set by options:
***
*** 187,192
--- 187,193
# within a file:
my $logmsg_separator = "";
+ my $No_Ancestors = 0;
### End globals
***
*** 398,404
goto dengo;
}
# Non-trivial case: check if rev is ancestral to branch
! elsif ((length ($branch_number)) > (length ($revision)))
{
$revision =~ /^((?:\d+\.)+)(\d+)$/;
my $r_left = $1; # still has the trailing "."
--- 399,405
goto dengo;
}
# Non-trivial case: check if rev is ancestral to branch
! elsif (((length ($branch_number)) > (length ($revision))) &&
!$No_Ancestors)
{
$revision =~ /^((?:\d+\.)+)(\d+)$/;
my $r_left = $1; # still has the trailing "."
***
*** 1604,1609
--- 1605,1613
$Hide_Filenames = 1;
$After_Header = "";
}
+ elsif ($arg =~ /^--no-ancestors/) {
+ $No_Ancestors = 1;
+ }
else {
# Just add a filename as argument to the log command
$Log_Source_Command .= " $arg";
***
*** 1741,1746
--- 1745,1751
-I REGEXP, --ignore REGEXP Ignore files whose names match REGEXP
-C, --case-insensitive Any regexp matching is done
case-insensitively
-F BRANCH, --follow BRANCH Show only revisions on or ancestral to
BRANCH
+ --no-ancestors When using -F, only track changes since the
BRANCH started
-S, --separate-headerBlank line between each header and log
message
--no-wrapDon't auto-wrap log message (recommend -S
also)
--gmt, --utc Show times in GMT/UTC instead of local time
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Info-cvs Digest, Vol 3, Issue 42
Matt, thanks for your response. > are you saying that they must be checked out to unix format, > even on windows machines? then how does Visual Basic compile > the source code, since it expects it in CRLF format? Yes, that is what I am saying. We have a multi-platform build environment here. There are basic three phases: 1. code check out on a master platform (is UNIX) 2. do platform independent stuff 3. build platform-specific code (Solaris, HPUX, Windows, etc.) >From a process perspective it makes sense to have the code checkout occur on one machine, from a single repository. But in order for VB, etc. stuff to build the sources need to be -kb'ed which is much less than optimal for ASCII (mergable) files. > -kb is used to tell cvs not to presume to know what an > end-of-line character should look like. you cannot have this > and also do (line-based) merges, since it doesn't know what the > end of a line is! Then what is the point of the cvswrappers MERGE directive? Clearly, if diff can be told to try to diff two binary files, then CVS should be able to diff two files marked -kb if the MERGE directive so stipulates. I can, if necessary, create make rules that use the Cygwin toolset to apply unix2dos, and then again do something similar in a commitinfo hook. Possible, but messy. And sure, I could also checkout on Windows-- but that too is like the tail wagging the dog from a multi-platform build env. The fix should, IMHO, be applied to the server. Maybe this feature (cvswrappers MERGE directive) is what CVS developers had intended to do, but have not yet fully implemented. I wish some of them would kindly speak up. :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Problems with cvswrappers MERGE directive
> > I need to be able to provide the CVS server with a directive > > that forces a merge using the cvswrappers functionality, > > overriding CVS's default COPY behavior for files marked as '-kb'. > > That is not currently possible. Can you please be more verbose? Also, I guess I don't understand the point of the MERGE vs COPY directives. If the default behavior of CVS is to merge, unless I say COPY then what is MERGE for? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problems with cvswrappers MERGE directive
I need to be able to provide the CVS server with a directive that forces a merge using the cvswrappers functionality, overriding CVS's default COPY behavior for files marked as '-kb'. Without adding complications of explaining our build process suffice it to say there is a requirement that all sources, regardless of the platform on which they build/run, are checked out on UNIX. This of course causes all files to have UNIX line endings-- unless the files are -kbe'ed, in which case line endings are untouched. The lack of a CR/LF line ending format cause file read errors by IDE's such as MS VB-- unless line endings are preserved by way of marking the files as binary, i.e. '-kb'. But then there is no merge-- only copy. What I really need, since many of the IDE files are truly ascii text, is to using the MERGE directive to *force* the merge of the selected files. Here is an example of what I have in cvswrappers: # Visual Basic Formats *.[Cc][Ll][Ss] -k 'b' -m 'MERGE' But, the MERGE directive is being ignored, and a COPY is instead occurring. I really need this flexibility... hopefully I am just doing something wrong, or maybe a later version of the server will do. Presently using CVS 1.11.1p1 on Solaris 2.8. Thanks!!! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
test
___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Docs for cvs 1.11.4
Is there a new set of [html] docs for the latest cvs release? The latest I can find are vintage 1.11.3. Thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: GUI client that checks out 1 file?
> mehul choube wrote: > >> Does anyone know how to check out just 1 file (as opposed > to a whole > >> directory) in WinCVS, Eclipse, or some other client? > > > > cvs checkout cvsClient/client.c > > Sorry, I've been directed to find a gui client that allows > this. Do you know of any? WinCVS has a command line mode-- either through the 'Admin' menu, or in the status area provided you have TCL installed, and in your path. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Weird problem, not urgent, just curious
> I think you mean CVS 1.11.1p1 and 1.11.2 -- there is no 1.12 yet. Larry, any idea when you'll roll a new release? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security options :-(
> > > That is, cvsphil can't login from the console, from telnet, > > > rlogin, etc. I think this is mainly done by setting his > login shell to > > > "/sbin/nologin" or the equivalent. > > > > You'll also need to configure cvsphil such that he can only > log on with > > a particular keypair. Otherwise, what stops phil from using the su > > command to sidestep this elaborate configuration? > > [/home/mzieg] mzieg $ grep cvsmark /etc/passwd > cvsmark:x:510:510:CVS-only account for Mark > Zieg:/home/cvsmark:/sbin/nologin > > [/home/mzieg] mzieg $ su cvsmark > Password: > This account is currently not available. > > [/home/mzieg] mzieg $ su cvsmark -c "ls /usr/local/cvsroot" > Password: > This account is currently not available. AFAIK, ssh requires a real shell-- but you can disable passwd auth at the os and application layer. This is my recollection of how it worked on solaris. I am presently doing this along w/ restricting the ssh key usage to a single command-- only difference is I allow *no* logins on the cvs server at all, except at the admin level. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
> > A chroot environment is only good at containing > > what's inside it. It > > does not prevent access to the chroot environment > > from outside. > > I see. I guess it's obvious that the repository would > have to be within the chroot'ed environment meaning > that such an environment wouldn't help in preventing > users from directly accessing the archive files. Is > this right? Yes, this you are correct... chrooting a file system would have no impact on the user's ability to access the repository. The best method for keeping folks out is to use public key ssh auth, constrain user's key to exactly one command required for cvs, and to disable passwd authentication-- both on the ssh and os level. >From this point you can use unix file and group security to further control what can be written/read. I've not set up cvs readers/writers, but that may add an additional layer. Finally, you can implement a commit hook to further filter by module and or branch. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Running a program after 'cvs commit' has completed
You want to create an entry for your script in loginfo-- it runs right after commitinfo. > -Original Message- > From: David Anderson [mailto:[EMAIL PROTECTED]] > Sent: Saturday, December 07, 2002 3:40 PM > To: [EMAIL PROTECTED] > Subject: Running a program after 'cvs commit' has completed > > > Hello, > > I am administering a cvs repository for a project that uses > Doxygen to > generate online documentation of the source code. The best > way to link > Doxygen to CVS would be to have the pserver run a script following a > code commit to immediately update the doc. > > However, I found nothing in the Cederqvist on this subject > (please note > that commitinfo is not what I want: I want the script to run > after the > commit has been fully entered in the repository), and I now have to > resort to a cron job that periodically regenerates the doc. > This is far from ideal for various reasons, and so I would > like to know > if any of you who have already set up what I am trying to accomplish > could point me in the right direction. > > Thanks in advance and many apologies if I overlooked something in the > documentation. > David Anderson > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Sharing files across directories
> >> Is there a way to share a single source file across multiple > >> directories in CVS, so that if it gets committed/merged in > >> one directory the update registers in both locations? I know > >> that VSS has this concept, and was wondering if CVS offers > >> any sort of similar functionality. I was thinking that > >> perhaps this could be achieved with some symlink trickery on > >> the server-side? > > >Yeah, this is possible using "Ampersand modules". See > >http://www.cvshome.org/docs/manual/cvs_18.html#SEC160 > > The ampersand module technique will only work if the shared > file is the only one in its parent directory. True enough. > Unfortunately, CVS has no way > to map multiple repository directories to a single workspace > directory, and it has no wayto explicitly map version containers > to files in the user's sandbox. Because the mapping is done > explicitly by matching directories in the repository and > sandbox, you're limited in the kinds of sharing that you can perform. Another method of hackery would be to put in a comminfo hook that matched on the desired file(s), and then called rysnc to distribute. Of course, to be safe, you'd need to do write locking on the receiving side during the operation. There's a program called cvslock that can be used w/ rsync to do just that. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Sharing files across directories
> Is there a way to share a single source file across multiple > directories in CVS, so that if it gets committed/merged in > one directory the update registers in both locations? I know > that VSS has this concept, and was wondering if CVS offers > any sort of similar functionality. I was thinking that > perhaps this could be achieved with some symlink trickery on > the server-side? > > Matt Yeah, this is possible using "Ampersand modules". See http://www.cvshome.org/docs/manual/cvs_18.html#SEC160 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Strategy to merge an Rev A.a modification into Rev A, B, C ... sources
> Of course, diffing "diff" output makes for an unreadable mess, so > instead I run both diffs in two xterm windows with the same > geometry, then flip back and forth between the windows a few > times quickly, looking for the characters that flicker. Our > visual systems are very good at spotting movement :-) Try using the ediff command within Emacs-- it's excellent for this, as well as for doing manual file merges. Each difference is broken down such that it's color-coded, and can be copied from one buffer to the other. There's even a 3-way diff when things get really nasty-- meta-x ediff-files3 (or buffers3). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
> At 01:06 PM 9/3/2002, Douglas Finkle wrote: > >Yes, you're right... you can use either of the two methods > >mentioned, 'cvs status', or the Entries file. Still, both > >of these methods are client side and their success depends > >upon software (e.g. Perl) that may or may not be present on > >client machines. > > The script named in commitinfo executes on the server side. Sure, but what about the data that the script looks at? On the server side of things there is no CVS/Entries file, and 'cvs status' will fail if there's no checked out sources. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: branch access control
Yes, you're right... you can use either of the two methods
mentioned, 'cvs status', or the Entries file. Still, both
of these methods are client side and their success depends
upon software (e.g. Perl) that may or may not be present on
client machines.
I've yet to see a good reason why a patch that passes the
branch tag can't be incorporated into, for example, commit.c
so the rules can be implemented completely on the server side.
Maybe there's more to it than I'm seeing?
-D
> > hi,cvs doesnt pass branch information to commitinfo file,so you cant
> > use commitinfo for that.I had the same problem, and then solved with
> > writing a patch for access control. Available at
> > http://www.geocities.com/barissahin/
>
> While it is true that the commitinfo script is not given any explicit
> arguments about the branch, this does not mean that you can
> not find out
> this information.
>
> The commitinfo script is running in a directory where the
> files given on
> the command line reside as local files. There is also a copy
> of the CVS
> directory present and the CVS/Entries file contains the
> branch information
> if you want to parse it. There are two ways you could get
> that information.
>
> You may either write a script to 'manually' parse the CVS/Entries file
> something like the following perl script fragment:
>
> open(ENTRIES, $ENTRIES) || die("Cannot open $ENTRIES.\n");
> while () {
> chomp;
> # /file/ver/timestamp/options/tag_or_date
> my($filename, $version,$ts,$opt,$tag) = split('/', substr($_, 1));
> $cvsversion{$filename} = $version;
> # the /^D/ date specification for a tag should not be
> possible in a commit
> # so ignore it
> if ($tag eq '' || $tag =~ /^T/) {
> $cvsbranch{$filename} = $tag;
> }
> $cvsoption{$filename} = $opt;
> }
> close(ENTRIES);
>
> It should also be possible to do something like:
>
> cvs -Qn status filename
>
> and parse the 'Sticky Tag:' line in your script.
>
> This does not require any patches to cvs at all.
>
> -- Mark
>
> > baris
> >
> > --- [EMAIL PROTECTED] wrote:
> > -
> > A simple question. Can I discover on which branch a file is being
> >committed from withina script run from the commitinfo file?
> Basically,
> >I know how to apply per user/module access controls, but I would like
> >to extend this to include branch information so that certain
> teams are
> >confinedto branches. We have in the past experienced code fixes being
> >applied to thewrong branch and it would be preferable for the
> >technology to help people avoidthat mistake in the future.
>
>
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
>
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Locking a branch
> > Some time ago John Cavanaugh wrote a patch for commit.c, > > but I don't think it was ever incorporated-- don't know why. > > As John himself noted, the patch is not ready for prime time > -- it does > not include documentation updates and it is not upward compatible. In > addition, I haven't noticed any groundswell of opinion that > it should be > included. > > -Larry Jones Perhaps since this patch is more than 3 years old it could be time to revisit this? (ground swell beginning now ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Locking a branch
> >> >> What is the best way to lock a branch? Should I use > >> > >> >How about: > >> > >> >``Please don't commit to this branch until told otherwise, or you > >> >will be fired on grounds of inability to follow instructions.'' > >> > >> >Why work with people that require a piece of software to > stop them from > >> >doing what they aren't supposed to? > >> > >> Everybody makes mistakes. Good tools warn people when > they're about to > >> do something bad. > > >How can the computer tell that what you are committing is okay or not > >for the given branch? > > >One way is to require the commit message to have a certain format, > >like to include 'Bug number: '. > > Another is to match your user ID with a list of users > permitted to commit > on a particular branch. Such a list would also have the notion of > "everyone" and "no one" and perhaps some notion of group membership > to give better control and easier maintenance. Paul, thanks for your insight here, and for adding the voice of reason to this thread. I've also been thinking of implementing locks on a user id basis. Some time ago John Cavanaugh wrote a patch for commit.c, bit I don't think it was ever incorporated-- don't know why. Here it is: http://www.cvshome.org/dev/patches/commitinfo Any thoughts? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvsweb
Have a look at ViewCVS... it's much the same idea, but w/ some very cool features added on (e.g. graphical history, sorting, and more); written in Python, and actively being developed. http://viewcvs.sourceforge.net/index.html -D ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: (no subject)
Check out http://coombs.anu.edu.au/ipfilter/. You can make your server listen on _only_ the desired interface. > I presume thats a no on a interface binding option. > Atm I already have a chain in place. But, I would > prefer the cvs-server process -not- to even listen on > the second interface. > I might do a inetd jail;) > > Thanks Anyway > -Josh > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Gianni Mariani > Sent: Wednesday, July 31, 2002 5:18 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: (no subject) > > > > You can do this using ip filtering. Check out ipchains or iptables > which is OT. > > Regards > G > > Josh wrote: > > > As I am running the CVS server (v1.11.2 pserver) on a > > (linux) machine with two network adapters I would very > > much like to know if it is possible to bind the server > > to a specific network interface? > > > > e.g. > > eth0: > > eth1: > > > > With the server only listening on the 'eth1' interface? > > > > > > Thanks, J. > > > > > >___ > >Info-cvs mailing list > >[EMAIL PROTECTED] > >http://mail.gnu.org/mailman/listinfo/info-cvs > > > > > > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Selective merging of changes on the vendor branch
> I previously did a cvs import of 'third party code'. I have > been making changes to the code, and checking these into cvs. > I have done another import of the 'third party code'. I was > hoping that I could pick only the parts of this latest code > that I wanted to merge in with my changes. However cvs asks > me to merge in all the changes. When a do a 'cvs -n update' > it lists all the files that have changed on the vendor branch > as having to be updated on the main trunk. Aren't these two separate > branches of code ? How can I prevent having to merge all the > changes on the vendor branch ? Use the 'M-x ediff-files' feature of Emacs. This will get the job done very simply. You can then pick and choose which diffs to apply. It's one of my favorite Emacs features. -Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How 2 Secure the repository?
>> Environment: cvs 1.11.1p running on unix. Clients are mostly >> wincvs1.13.7+ >>(in-house modifications to prevent password display on the >> screen) >> Huh? > Huh what? There's no need to use passwd... you should be using keys. The passphrase does _not_ go in as p/o the CVSROOT definition. That's why you are seeing it in WinCVS. > plink for ssh connection. >> Also, use Pageant on Windows. UNIX will require ssh-agent for >> the same functionality. >> > Pageant did us no good. plink does the ssh connection without a > hitch and does not hold the >connection open after the transaction > completes. Wincvs was another issue ... We/I modified >the code so when > you display the preferences window, the "Using:" message is not > displayed (it contains the password in clear text). WinCVS handles plink just fine, but you need to use keys. Pageant doesn't help b/c you're using passwd auth, and not public key auth. Public key auth is a better solution if you really want security. Pageant helps you do this while maintaining good passphrases. >> Developers have valid login on unix server and are >> members of the cvs and users groups. >> >> How do I protect the repository from developers modifying or >> deleting code directly without using cvs? Any protection scheme >> we've been able to think of either locks them out completely or >> has loop holes. > > You take away login access. Do this by setting their hashed passwd > in /etc/shadow to "NP", and add a line to their SSH authorization file > on the server side to _only_ allow the command 'cvs server'. The > O' Reilly SSH book explains this pretty clearly. > >Taking away login access on THIS machine is not feasible ... however, > we are exploring the possibility of moving the repository to another > machine where this is not an issue. Unless you can restrict access to this machine then you can't get any better security or data integrity than to mandate it through your security policy. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How 2 Secure the repository?
> Environment: cvs 1.11.1p running on unix. Clients are mostly > wincvs1.13.7+ > (in-house modifications to prevent password display on the > screen) Huh? > plink for ssh connection. Also, use Pageant on Windows. UNIX will require ssh-agent for the same functionality. > Developers have valid login on unix server and are > members of the cvs and users groups. > > How do I protect the repository from developers modifying or > deleting code directly without using cvs? Any protection scheme > we've been able to think of either locks them out completely or > has loop holes. You take away login access. Do this by setting their hashed passwd in /etc/shadow to "NP", and add a line to their SSH authorization file on the server side to _only_ allow the command 'cvs server'. The O' Reilly SSH book explains this pretty clearly. Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: spam on this list
> > To the owner of this list: > > > > I suggest that the list is closed to the subscribers only. > Quite a lot > > of spam is being sent there. > > What do you think ? > > I suggest they use ordb.org to lock out the spam from > open relays. Most > of the messages I've seen here as spam in the past few months > have been > specifically from open relays. Close them off (I've done it > in sendmail, > it's a cinch), and 95% of the spam will go away. Yes, plase do something about this spam... it's really affecting the quality of the list. Thanks, Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Loginfo misbehavior w/ CVS 1.11p1
> > Here is the line in loginfo that worked in v1.10:
> >
> > DEFAULT /usr/ucb/Mail -s "CVS Update: %{sv}" ${USER}@nvs.com
>
> This change was inadvertently omitted from NEWS -- the substitution is
> now inside double quotes rather than single quotes (this allows us to
> support files with single quotes in their names). You need to change
> your loginfo to something like:
>
> DEFAULT /usr/ucb/Mail -s "CVS Update: "%{sv} ${USER}@nvs.com
>
> or, if you like the single quotes around the substitution:
>
> DEFAULT /usr/ucb/Mail -s "CVS Update: '"%{sv}"'"
> ${USER}@nvs.com
>
> -Larry Jones
Thanks, Larry!!! I now have sendmail happiness! :-)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Loginfo misbehavior w/ CVS 1.11p1
I'm trying to find out if there's been a change to the way CVS
handles mail triggers in the info files. Specifically, I am
having mail woes using 1.11p1.
What used to work just dandy in v1.10 is now broken in v1.11p1.
It seems as though the single quotes have been removed from
the subject line.
In other words:
Subject: CVS Update: 'CVSROOT loginfo,1.14'
is now:
Subject: CVS Update: CVSROOT loginfo,1.14
The affect of this is sendmail tries to parse the file and
revision number as user args. Has anyone else seen this,
or perhaps am I doing something wrong?
Here is the line in loginfo that worked in v1.10:
DEFAULT /usr/ucb/Mail -s "CVS Update: %{sv}" ${USER}@nvs.com
Here is the brokeness:
- Transcript of session follows -
... while talking to mail.nvs.com:
>>> RCPT To:<[EMAIL PROTECTED]>
<<< 550 5.1.1 <[EMAIL PROTECTED]>... User unknown
550 loginfo... User unknown
>>> RCPT To:<[EMAIL PROTECTED]>
<<< 550 5.1.1 <[EMAIL PROTECTED]>... User unknown
550 1.14... User unknown
TIA,
Doug
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: ANN: cvssh - secure ext-to-pserver bridge
Sorry, I've gotta jump in for a minute... Greg is right about SSH v pserver, however. > > There's only _EXACTLY_ one case where cvspserver is in any way more > > secure than giving out real accounts, and that's when > > pserver is used to > > give read-only anonymous access to a _copy_ of a repository. > > And if the copy needs to get sync'd back to the "real" > repository (a > definate requirement), there goes your security. Next idea? Read up on rsync via an ssh tunnel to do this. Sudo, and noshell for a non-priviliged role account are also advisable. > > In other words if you've given an account to an user to access a CVS > > repostitory hosted on your network then you _MUST_ do whatever is > > necessary to isolate that user's access from the data and > services on > > your network and in your systems that you do not trust them > to access. > > I.e. you give them limited trust. > > i.e. you give them no access. Hence, pserver. I don't > want to give > out shells to hundreds and thousands of developers using ssh. > Using pserver, > this works today, and is much more secure. I don't need > accountability, I > need security. pserver vs. ssh are not even _CLOSE_ to a > comparible item. Well, you're right here... security between ssh and pserver is not even close-- ssh is secure, and pserver is not. Also, you do not _need_ to provide the user w/ the ability to login. In fact, the account that gets created should be LOCKED to ensure it is not used. Next, lock down the ssh key on the server end; read up on how to tell SSH it can exec exactly ONE command-- cvs only needs one. > > In other words you must comparmentalize access to your shared CVS > > repository so that remote users can gain secure access to > it while not > > gaining access to anything you don't want them to access. > > Gee, sounds like pserver again. Once you hand out an > ssh account, > you give them a huge truck to drive through your wall of security, > authenticated and validated.. with absolutely _NO_ > verifyability that the > user on the other end is who you think it is. Not so. You're creating a tiny pin hole, and it's very easily closed by revoking the user's key pair on the server. > It's an interesting idea, however.. not usable as users > scale into > the thousands. Well, key management is a bit of work, and so is setting up a well hardened cvs server. The key mgmt part it's easily scripted. If I had more than a dozen users that's what I'd advise scripting the administration. I'm actually completing a setup aas described, and will be happy to share it w/ the list when I have a bit more time. I just wanted to add my 0.02 in defense of the SSH solution. For an externally facing server it's the only sane thing to do. -Dou ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS via SSH2 on Win32 hangs
I am trying to connect to my CVS server via SSH2 and public key, and it is hanging my connection. I checked the archives, and some have had similar problems, and have stated that it's an SSH bug. Listed below is my scenario, s/w versions, etc. Can someone please offer a suggestion as to what the problem is, and possibly confirm if they have had the SAME problem? * CVS server v1.11p1 on Solaris 8 * SSH server on Solaris 8: F-Secure SSH Version 2.0.13.2 DSS * SSH Client on Solaris 8: F-Secure SSH Version 2.0.13.2 DSS * SSH Client on Win32: F-Secure 3.0 build 28 DSS * WinCVS 1.2 * CVS command line client v1.10 on Win32 On UNIX I can connect via SSH/public key from UNIX login; also can do a 'cvs co ' from UNIX command line. CVSROOT is set to use the :ext: syntax, and CVS_RSH is set to ssh2. So all is happy in UNIX land... In Windoze, I can also ssh from the command line using public key. But, when I try the same 'cvs co ' either from command line or WinCVS the connection hangs. On the server end I'm doing a truss, and see cvs issuing it's 'cvs server' command, and I see a directory /tmp/ being created. Then the world stops, and the server process goes to sleep. No files checked out, no error messages. WTF? TIA, Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Looking for SSH authorized_keys cookie for CVS
> On Thu, Feb 14, 2002 at 06:33:18PM -0500, Douglas Finkle wrote: > > Thoughts, references, examples? > > Don't know if this will help, but here's a key I use for > port-forwarding a pop3 connection to give you an idea of the general > format: > > command="sleep > 10",no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss B3Nz > [more pubkey lines] > DSHxqmbVujg= Pop Forwarding > > Basically, you just specify options before the key. You might not be > able to do what you want, as the I think the command must be matched > exactly, and I expect that cvs issues lots of different commands. > > Steve Thanks, Steve. I'm using F-Secure SSH2-- does your example work for protocol v2, or are you using SSH1? In SSH2 the keys look quite different: Here's a public key I can use to authenticate my login. Where would your command string be inserted? BEGIN SSH2 PUBLIC KEY Subject: dfinkle Comment: "1024-bit dsa, dfinkle@myhost, Thu Feb 14 2002 23:19:40" B3NzaC1kc3MAAACBAKHEapFhmpEYhnhudsanshusisadiudsans2MiObsyCOs8wtT8 ... more key hash ... 3nMyjZfcYF1caq5M0JDY69+PMZJtjsadhudsdsdsadsaSRjuO9tKz7ESGAeZL84vuGK3Qc yFsB8AMEN6xaG4JSuxw= END SSH2 PUBLIC KEY In SSH1 I think this is the syntax, but as you see the key is quite different in this example. Also, I did manage to fins that the CVS's magic command is "cvs server". Now for how to shove it into SSH2... command="cvs server" 1024 35 117026948781 ...more hash ...486938847 dfinkle@myhost ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Looking for SSH authorized_keys cookie for CVS
> > I'm looking for an example of a SSH public key that > > has the special "command=" format for CVS. I'm setting > > up CVS server access, and want to be very explicit what can > > be done w/ the key. > > > > Can anyone, Greg?, provide an example of what the key > should look like? > > "man ssh-keygen"? :-) > > -- > > Greg A. Woods Honestly, I would not have sent this request if I had not RTFM. :-) The sshd1 man page seemed to explain the syntax somewhat, but in ssh2, which I'm using, the way keys look and taste has completely changed! Thoughts, references, examples? Thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Looking for SSH authorized_keys cookie for CVS
> I'm looking for an example of a SSH public key that > has the special "command=" format for CVS. I'm setting > up CVS server access, and want to be very explicit what can > be done w/ the key. > > Can anyone, Greg?, provide an example of what the key should > look like? I should also state that I am using SSH2. -D ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Looking for SSH authorized_keys cookie for CVS
I'm looking for an example of a SSH public key that has the special "command=" format for CVS. I'm setting up CVS server access, and want to be very explicit what can be done w/ the key. Can anyone, Greg?, provide an example of what the key should look like? TIA, Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: SECURITY BUG in CVS 1.11.1
> > Douglas Finkle writes: > > > > Sorry, but can you provide a reference url, or ftp > > path for this update? > > I checked out on > http://ccvs.cvshome.org/servlets/ProjectDownloadList > > and the last version posted was v1.11p1 on 2001-10-16. > > Sorry for the confusion -- at the moment, the fix is only in > the current > development version of the code, it is not yet in a released version. > Anyone can get the current development version source code by checking > it out of CVS: see the checkout instructions at: > > <http://ccvs.cvshome.org/servlets/ProjectSource> Is there any chance of you offering this as a smaller step by publishing the fix as a patch? I'd feel much more comfortable applying a small patch vs replacing the entire tool w/ a development version. I imagine many others would feel similarly. A cvs diff of the files requiring the fix would be most appreciatiated. Regards, Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: SECURITY BUG in CVS 1.11.1
> It has been brought to my attention that CVS 1.11.1 and > 1.11.1p1 have a > bug in pserver mode that allows read-only users to run the "tag" > command. This allows read-only users to add and, more > importantly, move > or delete tags. The bug does not affect releases prior to 1.11.1 and > has been fixed in the current development version. Anyone with a > publicly-accessible pserver (or clumsy users) is urged to upgrade > immediately. Sorry, but can you provide a reference url, or ftp path for this update? I checked out on http://ccvs.cvshome.org/servlets/ProjectDownloadList and the last version posted was v1.11p1 on 2001-10-16. Thanks, Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Checkout inconsistencies -- known bug?
> >Directory hierarchy (InstallShield project) checked into CVS > >filled with a few files, but mostly empty directories. The > >directory hierarchy is required by InstallShield, not me. > > Empty directories are not supported well in CVS. If your project > requires some empty directory structure to always check out, > you have to put some dummy files into the leaf directories > of that structure. Yeah, it's inconsistent to be sure-- but that's why I was questioning the behavior. :) Dummy files also work, but it's an ugly solution, IMHO. > >Problem: > >On the trunk everything checks out complete w/ various empty dirs, > >and all is fine. On a branch however, the module checks out up to > >the point where the last file (i.e. non-directory) entry exists > >leaving multiple empty, but required, directories unchecked out. > > People I work with have reported similar behavior when > checking out to a tagged release; directories did not get created > even though -P pruning was not turned on. I think it happens because > the tag, be it a version or branch tag, does not exist in the empty > directories. Hmmm, it seems to me if this were true then 'cvs up -d' would yield nothing, but in fact it does. > The solution is to use those dummy files, because you want > those certain empty directories to show up no matter what, even > if pruning is specified. Yes, this is a workaround. Same goes for running a 'mkdir' script in a makefile, same for 'cvs up -d', but none fix the problem. The desired behavior seems to come w/ CVS for free, i.e. main trunk behavior-- it's only on the branch that the workaround seems necessary. Thoughts? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Checkout inconsistencies -- known bug?
Scenario: Directory hierarchy (InstallShield project) checked into CVS filled with a few files, but mostly empty directories. The directory hierarchy is required by InstallShield, not me. Problem: On the trunk everything checks out complete w/ various empty dirs, and all is fine. On a branch however, the module checks out up to the point where the last file (i.e. non-directory) entry exists leaving multiple empty, but required, directories unchecked out. Solution: Performing a CVS update -d will fill in the rest of the directories, as will a mkdir (duh), but neither should be necessary IMO. Question: The repository was created w/ CVS 1.10, but regardless of client, client version, or platform the behavior is the same. Is this a [known] bug, or an unusual feature? :-) TIA, Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: multiple respositories using pserver
> Scott O. writes: > > > > Can you use pserver to authenticate for multiple > repositories? If so what > > would the xinetd.conf look like. Thanks. > > Yes, just have multiple --allow-root= options: > > server_args = -f --allow-root=/u/cvs1 > --allow-root=/u/cvs2 pserver FWIW, in Solaris 2.6 you are limited to five "server-argument" entries. This was increased to twenty for Solaris 8. The former meant you had to write (and reference) your own script to pass into inetd. -Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Repository access question...
>> > Disclaimer: I think this is all... Oh yeah, admin user cvs should be in all groups... cvs, public, company[abc] > = > Thanks for the detailed answer! ur welcome. > Now for the trick question: If I am not going to use pserver, what is > the easiest to set up, and most secure? Remember, users thats > going to work with the source have never seen CVS or any tool like it > before. Sounds like a training issue. Also, easiest and most secure are generally mutually exclisive. :-) > So I think about using Tortoise CVS for the day to day use from windoze > because its easy to use. What about the alternative to pserver? SSH? > Kerberos? Tunneling? (I recently learned alot of fancy words...(hehe) SSH is pretty easy, it's free, and commonly understood. > :-) I have SSH, CygWin, and Putty on my windoze box. Tortoise > CVS comes with SSH via a DOS window...and you have to punch in the password for > every CVS command. Thats not very user friendly for people > totally blank on CVS and SSH and linux. Must be a better way (easier for the users). Why not use WinCVS? I'm pretty sure the user can even set his/her passwd in the line that specifies the repository. That would solve the retyping problem, but at the expense of some security/authentication. Can anyone confimr this? Larry, Greg, anybody? Again, this is a training/procedural problem. -Doug ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Repository access question...
> On Thu, Jan 24, 2002 at 05:44:51PM +0100, Olav Lindkjølen wrote: > > In short: > > ---(Admin) must have read/write access to all modules. > > ---Users from Company B must have read/write access only to > modules with > > code owned by them. > > ---Users from Company B must allso have Read Only Access to > public code. > > ---Users from Company C must have read/write access only to > modules with > > code owned by them. > > ---Users from Company C must allso have Read Only Access to > public code. > > > > Is there a way to solve this? (cvs user/passwords, file > permissions...?) > > - Create a UNIX group for each of the companies. > - Put each company's modules in the correct per-company group. > - Put the company's user account(s) into that group, but NOT into > the "cvs" group. > - Put yourself in all of the per-company groups, AND in "cvs". > - Set everybody's umask to 2, i.e. files and directories will be > world-readable, and group-writable. Close, but I do not completely agree: - Admin group cvs-- nobody else, create an unpriviledged admin role user cvs - Set (almost, see next line) all files under $CVSROOT/CVSROOT to cvs:cvs - set $CVSROOT to cvs:public 0750, $CVSROOT/history, val-tags to 0660 cvs:public - Each company has a separate, unique group - Each company requiring access to "public" modules also be in the same public group - Set the group sticky bit on for each module, according to public/private rules, that is 2770 for the (private) group. - Users can change their own umask, but if you force it, do so to 027 - Set up the readers and writers acl's-- assuming you're using v1.10.8 or higher. This will enable you to allow read-only checkouts of the public module(s). See cvs_acls.pl in the contrib section of the sources for this. - DO NOT use pserver-- under any circumstances as it's not safe. Disclaimer: I think this is all... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How to extract the branch tag with loginfo/commitinfo
Hi, I am trying to find out how to extract the branch tag info from CVS check-in messages. I'd like to be able to parse this data, and take certain actions if the commit was on a branch. I'm know I can take loginfo's output, redirect to a file, and then parse it, but is there a better way? --- Sample loginfo message --- Update of /net/snow/disk6/vpn_cvsroot/configurator/download_mgmt/lib In directory snow:/home/jfeng/R1_1_patches/configurator/download_mgmt/lib Modified Files: Tag: R_1_1_patches dl_tftp.pm Log Message: Add dl_router() to download the routing table for supporting multiple NOCs. -- Thanks for the insight. -Doug -- Douglas Finkle Genuity, Inc.
