Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
>If only Sun's Java team understood the importance of >version tracking in JAR files and in RMI definitions. Sun has a version standard that defines at the package level the format of an interface specification version (major.minor.edit), the format of an implementation version (a string, comparable for equality but not for less than/ greater than), and the names of the appropriate labels to use for them in the MANIFEST.MF. I think it even showed a set of methods on one of the system classes to look all this data up and compare interface versions. It has been out there for some time; I have a dog-eared hard copy at the office that I printed over a year ago and I don't think it was recent then. A search on the http://java.sun.com site should scare it up. Of course, Jar versioning doesn't help you particularly for RMI, does it? Or does it? It would be very nice if the version tab in Windows and the version checking logic in InstallShield were smart enough to pick up jar versions, but I don't see that happening any time soon. Ralph ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs commit as root
> Let me clear something up here. First off, I'm not debating the value > of your technique. Like I said, it is well beyond my level of operation. > > Only descibed my home grown technique as strictly amatuer hour. Just > filled in a little to show how it actualy works. > > > For example how would you manage per-user crontab files? I did it quite > > simply in my makefile with this kind of rule: > > In my setup, its not the kind of thing I would be concerned with. > I don't expect to cause mass harm with crontab settings. Although > possible I'm sure. My crontab usage is rather low level. > I'm more concerned with keeping tabs on things that effect the system > in a basic way. Things like /etc/fstab /etc/profile /etc/syslog. Or > on freeBSD things like /etc/rc.conf The heart of the config setup. > rc.firewall and others of similar importance. One of the implications of CVS managing your files as source files rather than as deployed files is that CVS assumes a certain latitude in how it uses file system "attribute" information like permissions and ownership and such. CVS tends to do this sort of thing a directory at a time, which is a very broad brush, particularly when you are talking about something like the /etc directory. CVS updates also, I believe, recreate files in working directories without respect to their prior attributes. Keeping a layer of makefile/script between your source control system and your deployment areas gives you a greater control of file system attributes of deployed files. If you are concerned about security you may want this layer in place, as there are some files (e.g. /etc/profile) that, in order to be used on a day-to-day basis, need different permissions than you would willingly place on other files like, say, /etc/shadow. There is always a continuum between convenience and security that any system admin needs to weigh. I won't intrude on your prerogative with arguments or suggestions in this regard beyond thinking about the hassles involved if a third party used your system as a staging platform for an attack on somebody with something valuable to lose and the habit of pushing their weight around. On one front I agree with you: most shell script looks a bit like line noise. :-) However, it can be learned with surprisingly little effort. The base rules are very simple and shell script is very idiomatic. Some combinations of syntax and commands are so useful that they tend to get used quite a lot. Once you've learned a few of the common idioms, it becomes very easy to read scripts like /etc/rc.local or /etc/profile and nothing that you are likely to use for this purpose will be more complicated than those. Besides you will need a good command of shell script in order to manage a Unix-influenced operating system effectively anyway. Without it you are severely hampered. If makefiles make you uncomfortable, start out with a few simple shell scripts and learn make later. All make really gives you over a well-written shell script is convenience and run-time efficiency (since it inherently checks file dates before doing anything). Ralph ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .doc file concerns
I also need to store and version my design documentation with the code that implements the design. I have some rather strong requirements for meaningful use - 1) The most important content will be pictures - class and ladder diagrams - with explanatory text. I also use sidebars, i.e. multiple content streams. 2) I don't want to have to remember and enter tags - I'd prefer a pull-down of predefined styles, with some automation of which paragraph style follows which header style, etc. 3) I need to be able to see what the *printed* result will look like while I'm authoring it (WYSIWYG or near-WYSIWYG). CVS has some rather strong requirements for efficient storage and meaningful versioning - 1) The content, including any figures, must be stored in a 100% text representation. 2) The process of editing must produce differencable changes in the stored document, i.e. opening, editing, and saving a document should produce differences only in the area edited. 3) The raw text view has to be meaningfully editable to resolve merge conflicts. I will gladly use a document editor that satisfies both sets of requirements. The requirements seem to recommend a dual-view editor (where you can edit in either the raw or cooked view). The dual-view editors I've seen for HTML are kind of primitive w.r.t their handling of styles. Are there such editors for any of the traditional Unix document formats, like *roff or LATEX? I think the latest version of Word might do what I want (moment of weakness: will it?), but I'd rather not get into Word and line Bill's pockets much more than I already have. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
repository surfing
> I've got two engineers here who want to be able to just view the files > in the repository without checking them out. These are ex-ClearCase > users and, let me quote "I could do that in ClearCase." Yes, they are > aware they can checkout read-only. They don't want to have to checkout > to view files. The nature of the quote suggests that they were users of ClearCase but not involved in its administration nor aware of how it works. What they are looking for is not direct access to the repository (vob in ClearCase terms) but an equivalent to ClearCase "dynamic views", where a view is implemented as a file system. By varying a short text configuration spec, the versions of files in the view auto-magically change. CVS's approach is similar to ClearCase "snapshot views", or the sandbox mechanism supported by virtually every other source control system on the planet. AFAIK, ClearCase is the only SCM that implements views of versions of data as a file system. Most other SCMs require you to specify how it should determine the version you want and then copies the files to a sandbox. MVFS is a neat feature, but ClearCase's implementation requires a company to pay a full-time staff to administer and maintain it. (I've never been in an organization running ClearCase with less than two such people.) This isn't generally necessary for PVCS or SourceSafe or CVS. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
"Greg A. Woods" wrote: > Ah, but in this case I can. Everything I've described about tracking > the renaming/moving of files using "cvs rm" and "cvs add" with magically > meaningful comment strings can be easily automated by a front-end. No > change is necessary in CVS itself to achieve this functionality, > therefore it is provably not a necessary feature of the basic CVS > functionality. I guess I'm ok with this as long as the format that is used permits both a machine-automatable comment and a human-to-human comment. Tactful political commentary is sometimes necessary to explain why an otherwise competent programmer did something patently stupid: "RENAME/MOVE -> fubar/coolfeature : Files moved to fubar project due to management insistance" My philosophy around merges is that the more frequently they are done the smaller and therefore safer they are. Any system in which merges are difficult to get right, where even simple merges require judgement not only about the source code and what you are merging but what version to use as a base, will encourage people to do as few of them as possible. In my view, a version control system should capture and use what information it can about the versions to make merges no larger or more dangerous than they need to be. I believe that the smallest, safest merges generally occur when the version control system uses for its base version the most recent common ancestor of both the versions being merged. CVS currently fails to track two types of historical events critical to making this determination (file migration and past merges). They could be collected by a scripting layer above CVS. This layer could contain the intelligence to query CVS about the merge-relevant information that it holds and combine it with this collected information to calculate for each file the optimal base version to use for a merge. It seems more natural to me that CVS, which already has most of the merge-relevant information, track the other two pieces of merge- relevant information and perform the calculation to identify the optimal base itself as a part of default behavior. Then all of the merge-relevant information is being tracked together in the repository. There has been good talk about technical feasibility of keeping the information in CVS. We've established that there is a place where the data could be kept in the rcs files without messing up rcs compatibility. Someone came up with a general work list - a prodigious general work list. I'm not particularly "religious" about binary files, locking, or empty directories, the other recently-hot topics on here. I think that hooks for external diff-merge tools for binary file formats would be a good move likely to spawn a cottage industry in such things that could only be good for everyone, since they could be used by all kinds of tools. Beyond that, I wouldn't want to see CVS go overboard over binaries. It is a *source* control system based on differencing. OK. I've expressed my views and have commenced to repeat myself, so it is time for me to stop talking and put up or shut up. I started contributing to the ArgoUML project a year and a half ago and then had to bail a couple of months later due to work; I hated to do it, but I learned a valuable lesson. I can't pull a passionate four-hour worknight after pulling a passionate nine-to-ten-hour workday. If I cared less about my work than I do or did less of it, I could eagerly pour my heart into authoring the appropriate patches. But I already have a wife, a son, and a mistress (my work), and I've learned I haven't the stamina for two mistresses. If I've lit a spark for anyone else, I will be delighted to encourage them and to test their patches. I will continue to comment from time to time in this group (albeit more briefly - I promise :-)) but I suspect I would be of greater service to the open source community if I spent an hour or two a night testing some worthy open-source project and filing bugs or picking up filed bugs and fixing them. If I lack the stamina to do what I would like, at least I should do what I can. Maybe ArgoUML will take me back on that basis... Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
>> cp olddir/oldfile.c newdir/newfile.c >> cp olddir/oldfile2.c newdir/newfile2.c >> cvs rm -f olddir/* >> cvs add newdir/newfile.c newdir/newfile2.c >> cvs commit -m 'reorganized source to be better' >> cvs update -P > However I can't let that sit. What a downright stupid and misleading > example. This doesn't seem like a manufactured scenario to me - more like something that comes up every so often, although I'll admit it has fewer files than the normal case. It looks like what I would do if you had to move the contents of a directory from one place in the directory tree to another? How would you do it, Greg? It isn't enough to say that you simply wouldn't let this happen to you. Migrations, even mass migrations, are a fact of life; demands of logistics often place their prevention beyond our control; since they cannot be prevented, they need to be supported without damaging continuity. > CVS isn't a market driven product -- it's a freeware niche product. I don't see CVS as a niche product at all. CVS is as mainstream as Linux or Java. Most of what most people need is easy to learn and use, with the exception of branches and merges. Set up is kind of fragmentary, as for many Linux services, but it seems to have all the right hooks in all the right places for integration into corporate build mechanisms. Its support for Windows clients is adequate. As companies become more accustomed to shareware, I could see it become the preferred version control system for corporate Unix/Linux. If the Windows version could register out of the box as a Win2000 service, I could see it becoming popular for Windows shops, too. Its biggest drawback as a mainstream product is that branching and merging require you to know a lot more than with other products and require certain voluntary behaviors that aren't immediately obvious, like tagging on both branches when doing merges. A few enhancements, like tracking moves, renames, and merges will permit reasonable default behavior in most situations for those developers who do not have a passionate interest in revision control. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
> Greg's comments generally fall under the "That's by design" category > but it's not obvious that that design is good. Every team needs someone who is passionate about protecting the elegance of the original design and not succumbing to creaping-feeturitis. For this reason, I'm very, very glad that Greg is here. However, I do tend toward the notion that a revision control system should automatically track important events in the lives (plural, given branching) of every file it contains, including merges, moves, and renames. Not supporting these affects the continuity of the history, which in turn affects automated operations like subsequent merges. > I've been working lately with a SCM tool that versions directories and > I've found that it makes life much easier (at least with regards to > renames and branching). If it is possible to truly track directory changes by inference from file changes, I'm all for it. Directory tracking is problematic in a variety of ways, as it is in some sense a second view of some of the same data. I suspect that the imperfections in directory tracking you've experienced may a side-effect of imperfections in tracking file movement and renaming. If these are done correctly, it should be possible to infer directory behavior from them. The two directory changes that I can think of that can't be inferred from properly tracked file activity are creation and deletion; the only effect of this is that an empty directory is indistinguishable from an absent one. I think accurately tracking the existence of empty directories is the least of CVS's limitations, so I'm willing to let that one go. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: BRANCH LABEL FOR DIRECTORIES
>> you can't reorganize your sources (e.g. rename a file). > Yes, you CAN. All rename operations, in all facets of computing, is > simply a deletion and an addition in whatever order is appropriate (and > sometimes it's an atomic operation from the point of view of the user, > and sometimes, as currently in CVS, it's not). Well, that depends upon what you mean by "an addition", doesn't it, Greg? If you mean the deletion of the old object with all of its baggage and the creation of a new object _with all of the old object's baggage_, I would tend to agree that the sequence implements the concepts of renaming or moving an object. In a Unix file system, that baggage consists of a set of permissions, owner and group assignments, and perhaps a couple of things that I forget, but is nonetheless a relatively light bundle. A file under revision control has a history of revisions (and - one hopes - ancestors and migrations) that describe all the important events of its colorful life. Does moving or renaming a file by deletion and addition retain the file's family history? It sounds to me as if it reduces it to a Unix file with none of these attributes and then recreates it as if it were newborn. All connection to the past is lost. Do you regard this loss as a frivolous concern? To me the power of source control lies not just in its ability to store all the versions of software but to accurately reflect the historic relationships of those versions. After corporate restructurings, when there is nobody to ask, sometimes only the source control system can give any clue as to what really happened - and sometimes we can even infer why. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
[Quoth I... :-)] > 0. select a reference version and a from and to version > 1. make a diff from the reference version to the "from" version > 2. make a diff from the reference version to the "to" version > 3. merge the diffs (preferably with optional user input), and > 4. apply the result to the "to" version. As I lay in bed thinking about all this, it suddenly occurred to me that, since CVS is always using the root as its reference version, CVS (and its ancestor RCS) can get away with not recalculating any diffs at all during an update but merely selecting from among the diffs calculated during prior commits. This is a significant time savings. A commit becomes the only operation that actually calculates a diff as a side-effect. Is this true? If so, it seriously restricts the kind of merge behavior that CVS can support, but I can see why it was done. Lots of other things about CVS that seemed a little odd also suddenly become comprehensible. How hard is it to extract three different revisions of the same file to a temp area outside of the normal checkout tree using CVS? (I'm contemplating what a seperate graphical merge utility layered on CVS might need to do.) This approach would be slow, of course, as it would have to extract and diff twice for every file in the covered area to determine if there is any work to do for each one. The result of the merge would be copied back to the checkout tree. By the way - step 4 should have read "apply the result to the reference version" (not the "to" version). I'm going back to bed. :-) Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
[Quoth Stephen Cameron...] > There is no merge history. OUCH! That should probably be mentioned when people are comparing CVS to things like ClearCase. Merge history is an important feature. In ClearCase, you can get a version tree for each file showing every branch and merge that ever occurred, which I have found essential when trying to figure out precisely what happened. Knowing the merge history also enables the findmerge tool to know the best reference version to use for merges, which generally keeps merges very small. I am a little puzzled that people aren't having more problems with merges in CVS. When there is pipelined development going on, it seems inevitable that you are going to be copying changes across at least three versions of a product on a relatively frequent basis. Do CVS developers really do all these parallel updates by hand-editing with cut/paste? Maybe the term "merge" is ambiguous. My concept of a merge is: 0. select a reference version and a from and to version 1. make a diff from the reference version to the "from" version 2. make a diff from the reference version to the "to" version 3. merge the diffs (preferably with optional user input), and 4. apply the result to the "to" version. Does CVS use a different merge concept entirely? Assuming that the answer is "no", how much of this is user-accessible? Does CVS support a command to do a merge of two revisions of a single file from a user-specified reference revision? This is the fundamental user-controlled merge operation. From your comments, it sounded like the answer is "no", that it always merges from the root of the oldest branch or some such thing. I would like to see CVS support, at least for individual files, a means to specify the "from", "to", and "reference" revisions on an update. CVS could generalize this to directories and trees by permitting the user to specify branches or labels for "from" and "to" and a label for the reference revision. With this support, everything else (e.g. labeling important merge points) could then be done through customary disciplines, like "always label after checking in a merge", possibly supported through scripts. This approach seems to be in harmony with the CVS philosophy of providing the raw mechanics without dictating how they are to be used. Did I miss something? Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Maintaining branches...
Hello, all, I have a couple of questions. First a question for my home environment - has anybody managed to integrate CVS into Visual Age for Java? I got the Zeus-SCC stuff and I tried to use it from VAJ but it killed the VAJ environment. I may have had it set up wrong, though. If I at least know that it is supposed to work, it will help me focus my efforts. Next about branches... At the office we use (or are used by) ClearCase (I'm never quite sure which). We have a mainline that is only used for releases. We have an integration branch that is used to collect various developers' stuff during development, and, for most parts of the project, each developer has their own working branch. There are a lot of merges back and forth between the integration branch and the developers' branches. That seems like a lot of branching activity - I think they do it partly because only datacenter systems are backed up and developers store all views on their own PCs so no file is "safe" until it is checked in. My part of the project does things a little differently. We make a branch for each task or bugfix and then merge back into the integration branch. That way we know exactly what files were changes for each fix. We only have to merge back from integration and then merge new changes to integration if a bug is reopened. What I'm reading about branching and merging makes me think that a branch-merge pair on CVS is a one-way trip, that once you have merged from a branch you can't merge to that branch from the updated mainline and then merge back again. Another interpretation is that you have to specify your merge "control points" (from, to, last common ancestor) manually. Does CVS branching and merging allow the developer to do the kind of rev-up/promote merge pattern that we do routinely with ClearCase? If you have to specify all three control points, shouldn't CVS be able to figure out the last common ancestor from the merge history? Is this another situation complicated by directories not being versioned? Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Use of CVS on large scales
[Quoth Donald Sharp...] > Go with Clearcase if you have 100+ developers. > CVS starts to break down( ie become unuseable ) with > over a 100 developers actively developing at a single time. > This is related to how cvs does file locking inside of > the repository when people commit/update/checkout in the > repository. If you deploy all of your source control for a large project through one repository, your concerns may be true, but there is an alternative when this becomes a problem: Put major divisions of the projects in different repositories to distribute the load. Even ClearCase uses multiple vobs on multiple servers, but ClearCase doesn't require the users to know what server their vob is on. They do have to know what vob they are using, though, when creating branches and labels. > Another good advantage of Clearcase is the multisite capabilities. > If you have developers working at a large number of remote > sites, you might want to think seriously about this. Here I might suggest that the first strategy should be to serve repositories closest to the majority of people that are using them. If a few people have to snarf sources over a distance, it generally isn't a major problem. FWIW, you run into these issues with ClearCase multisite as well. It isn't as seamless a distributed VOB as one would hope - the term "VOB mastership" may ring a bell with some. > Especially if they are connected at a relatively slow ethernet speeds > or their connection can be unreliable The source pool for even a large body of code is surprisingly small. Development-time binaries like icons and bitmaps likewise tend to be small. What gets big are the binaries built from these little bits and pieces. Solution - don't store derivative files under source control. In extremis, tarballs of nightly builds on appropriate platforms can save a lot of time once the interfaces between components are relatively stable. But don't store these under source control - put them in a directory somewhere. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Use of CVS on large scales
One thing which has been alluded to but not expanded on adequately - I have been in a couple of organizations that use ClearCase and in both cases it has been necessary to have a team *dedicated* to supporting it. It has a definite MIS/central management flavor to it. It is too complex to effectively distribute control to the teams. I generally see CVS as something which the development teams using it can support. Some things need to be centrally managed - things that nobody sees except when they aren't done, like backups or maintaining the corporate email system. Other things need to be centrally managed because they coordinate the activities of the corporation as a whole. Customer problem reporting and resolution are arguably in this category if the corporation is large and geographically diverse. But source control is something which can be effectively distributed among the organizations that need it. This is both cheaper and more effective than centralizing it. So, in management buzzwords, provided you do sensible things to keep control of repositories local to the development teams that use them, my sense is that CVS has better Total Cost of Ownership (TCO). Of course, CVS has a $30 head start in TCO over ClearCase right out of the gate :-). Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linux security issues as they pertain to CVS
[Greg Woods wrote...] > By allowing *anyone* to use CVS on your machine you are very nearly > granting them shell access anyway! If you do so in a totally > unaccountable way (i.e. with pserver) then you've just lost the > integrity (and thus the security) of your repository. > I.e. CVS cannot guarantee that it will not allow a remote user to > execute any arbitrary command (and indeed maybe even any arbitrary code > whatsoever). There is no inherent security in CVS -- anyone who can > execute it can probably do anything as the user it executes as. Perhaps this is what I am missing, then. How does CVS access "very nearly grant them shell access"? By what mechanism do you see this happening? Are you assuming that there is a risk worthy of consideration that, since no service can be proven to not possess program bugs, and since some bugs allow code to be injected into programs, any running service must be assumed to contain code that was not a part of its original design, code "contributed" by a hacker at runtime that may run in any account to which the service has access? The implication of this would be that no restriction in the design of a program is of any significance to security, since no assumptions can be made about the actual contents of the running code. The only factor about a running server that is of any significance is the set of accounts to which it is may acquire access during execution. Of course, this would apply to the code implementing tunneling services or ssh or any of a dozen other services as well, no? The fundamental paradox of security is that you have to trust someone in order to know whom to trust. :-) If we aren't worried about those services, then the argument is really "I trust these coders not to screw up (perhaps only because I have to) but not those coders." That's fine; but if that is the substance of your argument, it needs to be stated plainly. Or is there something more specific to CVS that I am missing? Let us presume from the outset that reasonable precautions have been made about the CVSROOT directory that prevent it from being modified except in a local account on the system. This is a known vulnerability, dealt with easily enough. Is there something else in CVS that permits its users to affect files outside of the repository? Once we're past this point in the discussion, I'll bring up the notion of what is or isn't considered "acceptable risk" and why. Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Linux security issues as they pertain to CVS
Greg, > Some of the systems that allow this are buggy. Others are broken by > design (the system will not let a process permanently discharge its > privileged state). I have made changes to my NetBSD kernel which I > believe prevent this from ever happening (at the expense of totally > eliminating the ill-designed system calls which allow it in the first > place), but even with those changes I would still not feel safe > enough to run CVS as root from inetd (i.e. as a non-anonymous > pserver). This is interesting and you obviously have a lot of experience in this area - can you elaborate either here or via private eMail? What system calls? What design flaws? Is Linux one of the systems to which you refer? I want to understand the mechanism well enough to avoid problems in coding wherever possible and to identify and correct problems in other folks' code that I encounter. Forewarned is forearmed. > Worst of all of course is the fact that CVS does not need pserver > junk. It works entirely perfectly with any external remote job > execution tool. And any external remote job execution tool will also presumably be using setuid() to ensure that it follows the rules because that is how any daemon does it, right? Its chief advantage is that rje tools tend to be more closely examined because the cost (and benefit, I suppose, to some) of a hole in such a tool is proportionally higher. However, I am beginning to understand Mr. Price's argument... It occurs to me that :pserver brings one valuable thing to the table that other mechanisms do not. It recognizes that there are two kinds of CVS user identity - the user identity through which source changes as tracked by CVS, and the operating system user account used to determine permissions. In other modes of access, the operating system user identity becomes the sole user identity tracked by CVS, since there is no other identity to be found. This "identity of identities" :-) is a problem for many environments. System administrators want exclusive control of system user account creation. They don't want to deal with user accounts for individual CVS users - CVS users come and go at an alarming rate especially on open source projects - the road to Linux was paved with good intentions - and system administrators aren't equipped to deal with user account management at faster than the typical corporate hire/fire rate. They would rather delegate CVS user identity management to someone closely associated with the repository they are serving, someone who can't create user accounts or groups, only assign CVS users to existing user accounts. CVS users under the same system account have the same access to the same files and belong to the same groups. However, CVS is open source and can change. An access mode that uses something external and well-examined to secure the connection and verify account access safely (or better yet provides hooks to do so) but separately manages and secures the user identity within CVS would be of great value. It could even continue to use the familiar CVSROOT/passwd file for the latter role. Now is that what Mr. Price did or did he do something else? Ralph ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Linux security issues as they pertain to CVS
Hello, I've been following the discussion between Messrs. Price and Woods with some interest but with little comprehension. I know what setuid() is and does fundamentally - it lets a privileged user act as another user. It is used to perform services in behalf of another user and actually exists for a security purpose - to ensure that the program can't perform actions that the user is not ordinarily permitted to perform. That's one edge of the sword. The other edge is that if the program can be induced to improperly identify the user for whom it is performing an action, it may inadvertently permit some other user to perform actions they are not ordinarily permitted to perform. I suppose one approach (perhaps I should call it the Woods approach :-)) would be to treat me as a child and say "setuid() baaad - you aren't wise enough to manage that kind of power - forget it". Of course, I never liked that kind of treatment even when I was a child. What I much preferred, both then and now, is to understand the circumstances under which a powerful tool can be harmful and how to mitigate the risks to an acceptable level. (Yes, there is ALWAYS such a thing as an acceptable level of risk.) Now it seems to me that when looking at a program I have to ask "What actions can this program perform in a setuid() environment?" CVS can edit files in CVSROOT, which include some scripts that will be executed in the server context. This is an interesting risk, but one that can be more easily tightened down, at least to some extent. For instance, these files can be restricted fairly easily to only be written to by a group whose members have individual login ids and no pserver access. CVS can also do what it is meant to do - edit source files under revision control. Assuming that somebody got somebody else's pserver password by sniffing, etc., I fail to see how this permits the user to do anything except checkout, edit, checkin, tag, and remove files from the source control system, i.e typical CVS user actions. There is a risk of rogue code getting slipped in, but this can be managed by other means. I am assuming that the source code isn't seen as a major "trade secret" by the owner of the CVS repository. This is pretty limited in scope. Of course, the last 50 or 100 Linux patches I've seen from RedHat have been from exposures where buffer overflows could be exploited to execute a statement from a setuid() environment. I'm sure there've probably been a few of those fixed in CVS and I'm sure there may eventually be a few more. This sort of thing is the security risk (deemed acceptable by most) of working in any software environment these days. That's my child's-eye view of setuid(). What gaping hole did I miss? Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem with LF <--> CRLF trasnlation
My current favorite for editing files of uncertain parentage on Windows is Textpad (http://www.textpad.com). It's shareware, so no source, but it's cheap and solid and starts up fast - and, of course, it supports Windows key bindings (unlike VI :-)). It has some programmer-friendly stuff like syntax-highlighting. I use it as a notepad replacement for those times when I want to glance through some code and don't want to wait for a bulky IDE to come up. What makes it relevant here is that it not only properly displays LF- delimited files and preserves the dominant existing line ending style of files, but it has explicit commands for tweaking the line termination on existing files one way or the other. This can help if a file has been damaged and has mixed line terminators, which is guaranteed to happen from time to time if you're developing in a mixed-OS environment. Ralph > From: "Echlin, Michael" <[EMAIL PROTECTED]> > > Mike, > > Suggesting to a windows user to use VI??? > > That's scary :-) > > Mike. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Setting up repository - very odd - help!
Hello all, I finally got on broadband, so I picked up a cheap PC to use as my Linux server, and started setting up services on it, including setting up CVS for :pserver: access from my Win2000 box. At first things were going great. I got it set up and was able to login from my Windows 2000 box and use the CVS command line and WinCVS on Win2000 to import all of my projects into the repository. I look and everything is there - only the files were set with my personal group instead of the "cvs" group and they had a username of "ralph" rather than "root". Strange... Then I say to myself "OK, now let's get these files back out so I can work on them." I do a cvs checkout and I get: cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied OK, now this really doesn't seem right. Any clues? My config is: SystemAuth=no PreservePermissions=no TopLevelAdmin=no My passwd has ralph and anonymous with working passwords. I don't want to loosen the permissions on root for obvious reasons. Where else can I look? It is almost as if cvs is not operating as root. Is there some other bit I need to set? (I know I need to tighten up my CVSROOT before I open up 2401 on my firewall so I can get at my sources from the office. Everything I've done so far is on my local LAN.) drwxrwxr-x3 root cvs 4096 May 10 01:59 CVSROOT drwxrwxr-x3 ralphcvs 4096 May 9 02:17 CharMaster drwxrwxr-x5 anonymou cvs 4096 May 9 03:34 Desktop drwxrwxr-x2 ralphcvs 4096 May 9 02:13 LANSwap drwxrwxr-x2 ralphcvs 4096 May 9 02:24 OrderOfBattle drwxrwxr-x2 ralphcvs 4096 May 10 01:48 OrderOfBattle-PPC Oh - yeah - versions - server is RedHat 6.2 (CVS 1.0.7) and client is 1.10. (I'll go to 1.11 when I upgrade my RedHat box to 7.1.) Thanks, Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
