From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21781 invoked by alias); 9 Dec 2002 23:20:10 -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 21759 invoked from network); 9 Dec 2002 23:20:09 -0000 Received: from unknown (HELO rose.csi.cam.ac.uk) (131.111.8.13) by sources.redhat.com with SMTP; 9 Dec 2002 23:20:09 -0000 Received: from student.cusu.cam.ac.uk ([131.111.179.82] helo=kern.srcf.societies.cam.ac.uk ident=mail) by rose.csi.cam.ac.uk with esmtp (Exim 4.10) id 18LXC4-0003Ii-00; Mon, 09 Dec 2002 23:20:08 +0000 Received: from jsm28 (helo=localhost) by kern.srcf.societies.cam.ac.uk with local-esmtp (Exim 3.35 #1 (Debian)) id 18LXC4-0007GG-00; Mon, 09 Dec 2002 23:20:08 +0000 Date: Mon, 09 Dec 2002 15:27:00 -0000 From: "Joseph S. Myers" X-X-Sender: To: Walter Landry cc: Subject: Re: source mgt. requirements solicitation In-Reply-To: <20021209.150428.08314333.wlandry@ucsd.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-12/txt/msg00483.txt.bz2 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. > > 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. > > 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. > > 3. Should allow a user without commit privileges to generate a change > > set, making arbitrary changes to the repository (none of this "you > > can edit files and generate diffs but you can't add or delete > > files" nonsense), which can be applied by a user who does have > > commit privileges, and when the original author does an update > > he/she doesn't get spurious conflicts. > > Are you thinking of sending patches by email? Arch doesn't have that. Patches by email (with distributed patch review by multiple people reading gcc-patches, including those who can't actually approve the patch) is the normal way GCC development works. Presume that most contributors will not want to deal with security issues of making any local repository accessible to other machines, even if it's on a permanently connected machine and local firewalls or policy don't prevent this. A patch for use with a better version control system would need to include some encoding for that system of renames / deletes / ... - but that needs to be just as human-readable as context diffs / unidiffs are. -- Joseph S. Myers jsm28@cam.ac.uk