engineering arch (was re OSU and Re: [Gnu-arch-users] Re: Linus and blah blah blah)

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > And *this* is our disagreement.  I don't see copying permissions
    > to be "compromising the engineering of arch".  Sorry.  In fact,
    > quite the opposite - I think requiring people to use ssh for
    > multiple committers is compromising the filesystem-independence
    > of arch, which is certainly a large component of its
    > engineering.

And *that* deserves a reply.  I'm not optimistic that the reply will
satisfy you, but I am confident that it's the right reply.


* Fails on some transports

  Arch's "dumb server" support assumes a least common denominator 
  file system interface.   The "copying permissions" hack can not be
  robustly implemented on that interface.    In particular, FTP and 
  WebDAV would not be well supported by this hack.  It is reasonable
  to assume that future transports will also not support this hack.

  You are asking me to introduce a strange "special case" area of
  functionality for archives accessed by sftp or locally.   That would
  be a wart.



* Motivated by lame-brain access control ideas

  Part of your motivation for the copying permissions hack is that 
  it seems to be a way to provide access control with the granularity
  of those things which are directories in the current archive format.
  Set the permissions and ownership of a category, branch, or version 
  a certain way -- and voila, you have access control with category,
  branch, or version resolution.

  But you don't, really.

  You have a choice of three options about how to implement the
  permissions-copying hack (for those transports that can support it),
  two of which are unacceptable.  These are:

        1) Implement it non-robustly.

           A well timed attack can thwart the attempted protection.


        2) Break the lock mechanisms.

           Currently: If you have a revision lock, I can break it and
           clean up after you.  To implement permissions-copying
           robustly, you would have to deprive me of that capability.
           You would likely recreate the situation that CVS suffers
           from: the archive can become wedged and you have to "log in
           and fix it by hand".


        3) Don't implement it at all.

           "Strange game.  The only way to win is not to play at all."

  And, anyway: the directory layout of an archive is not obviously the
  ideal granularity for fine-grained access control.   I'm fairly sure
  that it is not, in fact.


* far better ideas exist

  So far, every single instance of the umask problem that has been
  reported (both of them) has been (a) site specific and (b) had a
  site-specific work-around.

  Meanwhile, read my recent challenge if you are seriously interested
  in fine-grained access control, Miles' comments and your own
  comments on patch managers if you are not.

-t