on security and patch formats

[Tom Lord <lord at emf dot net>]

Two quick replies:

	* Zack Weinberg: You Missed My Security Point
	* Joseph S. Myers: An Implication of Testing for Patch Formats

================================================================

* Zack Weinberg: You Missed My Security Point


	The presumption I'm making is more fundamental: if there's
	only one user ID (ignoring root) with write privileges on the
	repository, and the sysadmins have tight control over what
	processes can legitimately run under that user ID, that
	reduces the number of potential vulnerabilities that can lead
	to the repository being compromised.  It's a
	privilege-separation argument, not a ease-of-auditing
	argument.

Would these restrictions be imposed by, for example?:

	1) Making it a no-shell account.

	2) Running only believed-to-be-quite-secure network 
	   services with that id.

	3) Perhaps chroot-jailing or via file protections severely
	   limiting both what parts of the file system that id
	   can see or change, and what executables that id can run.

Currently, `arch' is weak in this area -- but its prospects are
extremely strong.

`arch' is weak because the primary server, at this time, is an FTP
daemon, and (because of plain-text passwords) FTP is known to be weak.

`arch' is strong because the primary server, at this time, is an FTP
daemon.  Secure variations on FTP are available;  FTP servers
traditionally run within chroot jails;  there are a number of mature
FTP implementations available (hopefully some overlap with better
handling of authentication).

If you are really worried about it, we can make some modest changes to
an FTP server.  In particular, as I mentioned, `arch' never needs to
_modify_ files in the repository, only to add, rename and delete
them.  It never needs to delete precious files -- only lock files and
cache files.   One can imagine adding a feature to an FTP server that
implicitly manipulates the permissions on files and directories to
help ensure that precious files, once created, can not be modified or
deleted by the server under any circumstances.

Indeed, with a _little_ work, you can transfer the repository as it
evolves to write-once media, so that no process, under any
circumstances, can damage the goods.


================================================================


* Joseph S. Myers

	[Regarding smarter testing in the microbranches thread]

	For what you describe to work in general for patches needing
	review (and possible application by someone else), presumably
	the changeset format needs to be defined so as to formally
	include the base revision (of the whole tree, of course) the
	microbranch should start at?  (Not just as a comment, as in
	CVS diff.)

In `arch', basic project tree manipulation, changeset creation, and
changeset application are strictly a "layer below" repositories.

In other words, it will be quite reasonable for `arch-1.0' to 
consist of a separable (separately distributable) set of patch
manipulation tools -- contributors can adopt those without having to
buy in to all of arch.

In `arch', base revisions are named within a global namespace, and
information about a tree's revision name is typically stored in the
tree, in a plain-text format, included even with tar-ball
distributions.   

The area you mention, patch set format, is an important one with
implications in many areas.  `arch' has a fair-to-good prototype
solution, but the plan prior to 1.0 is to analyze the implications as
far as we can, design the final format accordingly, write up a formal
specification of the format and of the semantics of patching, and
provide tools that are separable from `arch' for patch manipulation.

I have been trying to encourage developers of other new revision
control systems to join in this design effort.  If we can find a
solution that satisfies all of them, that greatly increases both:

	a) the opportunities for various forms of inter-operation

	b) the chances that currently centralized systems can cheaply
	   and easily acquire features for distributed operation