Re: source mgt. requirements solicitation

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

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