[Gnu-arch-users] Re: expert needed: arch doesn't support multi-committer archives!

[James Blackwell]

In lists.arch.users, Ethan wrote:
>
> this is not different then a single shared unaccountable account.
>> * accounting will be logged
> not in any meaningful way.  unless you only allow connections to the
> shared account from localhost, forcing a real login first.

If you think it through, localhost ends up with exactly the same
problems as remote. Any file a user can write a user can edit, truncate
or just plain rm. This holds whether we're working on the local
filesystem or a remote filesystem. There's just no way around that. 

When you get right down to it, the question you're really asking is "How
do I let people change files without deleting them or truncating them?
You don't. 

A shared writable archive implies that you fully trust the people to not
abuse your trust and wipe out your tree. If you do not trust them fully,
do not give them write access to your tree! 

Thats why, if you look back about a month, you'll see that for exactly
these reasons I strongly recommended that a person be put in place that
is responsible for a master archive that is responsible for merging from
other people's archives. This way, if that patchmaster ever goes away,
each developer essentially has a full copy of the archive and a new
patchmaster can be selected.

Now, with all of that said, another option can potentially
exist. An arch server could be designed, built and deployed that would
allow proper modifications to an archive while denying improper
modifications. This hypothetical server would accept patches from
submitters and apply them under the context of the archive owner. 

But this archive server would open up a **_HUGE_*** can of worms that
are more painful than the problem its trying to address in the first
place. Some of the things that would have to be considered would be:

1. If we didn't trust this user not to screw over the tree in the first
place (thus requiring an arch server), how could he be trusted to not
insert a trojan into the source code? 

2. Writing an arch server is a lot of painful work. I don't care enough
about that particular problem to spend the next six months writing an
arch server. What's more, I don't think anyone currently working on arch
is willing to make that sort of obligation.

3. The developers of this arch server would be obligated to ensure that
this arch server is completely buffer-overflow free. One single
potential buffer overflow is enough to throw the intended safety of this
arch server into doubt. 

Compare that to how arch works now: 

1. I can make an archive that nobody but I can access.

3. I can make a copy of anyone else's archive that is public and edit my
   own copy.

2. I can make an archive that I can read and write but others can do 
   #2.

3. Others can use my archive if I trust them to not screw it up.


When you get right down to it, creating a specialized arch server would
only solve part of the trust issue, be painful to write and provide yet
another potential entry point to a server for a script kiddie. 

-- 
James Blackwell                               570-407-0488
Owner, Inframix                        http://inframix.com
   Using I.T. to bring more business to your business

----- End forwarded message -----

-- 
James Blackwell                               570-407-0488
Owner, Inframix                        http://inframix.com
   Using I.T. to bring more business to your business