From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31609 invoked by alias); 10 Dec 2002 00:43:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31596 invoked from network); 10 Dec 2002 00:43:10 -0000 Received: from unknown (HELO grue.ucsd.edu) (132.239.66.103) by sources.redhat.com with SMTP; 10 Dec 2002 00:43:10 -0000 Received: from localhost ([127.0.0.1] ident=boo) by grue.ucsd.edu with esmtp (Exim 3.36 #1 (Debian)) id 18LYUf-0007Bx-00 for ; Mon, 09 Dec 2002 16:43:25 -0800 Date: Mon, 09 Dec 2002 17:05:00 -0000 Message-Id: <20021209.164325.21937095.wlandry@ucsd.edu> To: gcc@gcc.gnu.org Subject: Re: source mgt. requirements solicitation From: Walter Landry In-Reply-To: References: <20021209.150428.08314333.wlandry@ucsd.edu> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00489.txt.bz2 "Joseph S. Myers" wrote: > On Mon, 9 Dec 2002, Walter Landry wrote: > > > arch doesn't interact at all with root. The remote repositories are > > all done with sftp, ftp, and http, which is as secure as those servers > > are. > > Is this - for anonymous access - _plain_ HTTP, or HTTP + WebDAV + DeltaV > which svn uses? One problem there was with SVN - it may have been fixed > by now, and a fix would be necessary for it to be usable for GCC - was its > use of HTTP and HTTPS (for write access); these tend to be heavily > controlled by firewalls and the ability to tunnel over SSH (with just that > one port needing to be open) would be necessary. "Transparent" proxies > may pass plain HTTP OK, but not the WebDAV/DeltaV extensions SVN needs. Anonymous access requires for HTTP + WebDAV (no DeltaV). However, the set of WebDAV commands needed are much smaller than what subversion needs. It just needs whatever anonymous ftp has that http doesn't (I believe PROPFIND is one). In particular, you can run a server using apache 1.3. > > > 0d. The data stored in the repository cannot be modified by > > > unprivileged local users except by going through the version > > > control system. Presently I could take 'vi' to one of the ,v > > > files in /cvs/gcc and break it thoroughly, or sneak something into > > > the file content, and leave no trace. > > > > There is no interaction with root, so if you own the archive, you can > > always do what you want. To get anything approaching this, you have > > to deal with PGP signatures, SHA hashes, and the like. OpenCM is > > probably the only group (including BitKeeper) that even comes close to > > doing this right. > > This sort of thing has been done simply by a modified setuid (to a cvs > user, not root) cvs binary so users can't access the repository directly, > only through that binary. More generically, with a reasonable protocol > for local repository access it should be possible to use GNU userv to > separate the repository from the users. This is a different security model. Arch is secure because it doesn't depend on having priviledged access. For example, there is an "rm -rf" command built into arch. I have a feeling that you are thinking of how CVS handles things, with a centralized server. Part of the whole point of arch is that there is no centralized server. So, for example, I can develop arch independently of whether Tom thinks that I am worthy enough to do so. I can screw up my archive as much as I want (and I have), and Tom can be blissfully unaware. Easy merging is what makes this possible. So you don't, in general, have a repository that is writeable by more than one person. > > > 2b. Ability to back out an entire change set just as atomically as it > > > went in. > > > > In theory, easy to do (just a few rm's and an mv). There are larger > > policy questions, though (Do we want to allow that?). Some day, I may > > just hack something together that does that. > > A change set is applied. It turns out to have problems, so needs to be > reverted - common enough. Of course the version history and ChangeLog > shows both the original application and reversion. The reversion might in > fact be of the original change set and a series of subsequent failed > attempts at patching it up. But intermediate unrelated changes to the > tree should not be backed out in the process. To get what you really want means that we can reverse our patches. Then you could simply unapply a patch. But that isn't possible right now, and is not going to be done real soon. That would require someone who is actually working on the code to understand the current patch format. Regards, Walter Landry wlandry@ucsd.edu