See my comments below
>-----Original Message-----
>From: C. Michael Pilato [mailto:cmpilato@xxxxxxxxxx]
>Sent: dinsdag 11 september 2007 15:48
>To: ViewVC Developers
>Subject: [viewvc-dev] What's Blocking ViewVC 1.1?
>
>Two general questions have been cropping up more and more
>lately (on-list and off) regarding ViewVC:
>
> * What's up with the path-based authorization code these days -- is
> it finally finished?
>
> * When is ViewVC 1.1 coming out?
>
>The answer to the latter is largely tied to the resolution of
>the first.
>And the answer to the first is, "Quite honestly, I'm stuck."
>
>The trunk holds the work done so far for the path-based
>authorization support. It mostly works, too, I'm happy to
>say. But there are a couple of issues that concern me.
>
>First, I haven't been able to decide how to deal with
>Subversion revision properties (log message, author, date).
>Subversion's own policy around the display of these things to
>a given user is built around path-based authz, and calculated
>for a given revision by checking the readability of the paths
>changed in that revision. For example, if the authz rules for
>the repository say that I'm allowed to see changes everywhere
>except in a "/private" directory then:
>
> * I can see all the revision properties, and all paths in the
> changed-paths list, for revisions in which nothing in or under
> /private was changed. [full access]
>
> * For revisions in which only paths in and under /private were
> changed, I can't see any revision properties or items in the
> changed-paths list. [no access]
>
> * For revisions where some paths under /private were changed and
> some paths *not* under /private were changed, I can see the
> date and author properties, and only the non-/private paths
> in the changed-paths list. [partial access]
>
>Because I currently have the vcauth code (the authorization
>layer) laid atop the vclib stuff (the generic version control
>abstraction), I'm in a weird spot trying to either make these
>types of determinations only for one version control system,
>or apply them to other systems which perhaps don't natively
>have such rules. CVS doesn't even have global revisions with
>various changed paths associated with them, so what does it
>mean to ask about the viewability of a CVS log message?
>
>The second ... discomfort I have today is that I think I might
>have keyed things all wrong. I was aiming for a modular
>system which lets you drop a Python module into place that
>implements a given class and *poof* you've got an authz
>plugin. I still like that kind of modularity, but I'm
>concerned my layers might be misordered.
I haven't had the time yet to go through the code. If you happen to have
some kind of design document, which explains how you came to the current
layering or which describwes it, then that would be highly appreciated.
I would vote in favour of modularity if it was up to me. I think it will
keep it more flexible.
>
>Today, you can write one authz plugin (or use one of the
>provided ones) and it can apply to both CVS and Subversion
>backends. This is really neat in some ways -- it means you
>can use Subversion's trivial authz file format to add access
>control to CVS repositories, too. That's cool because CVS
>doesn't really have its own access control mechanism aside
>from file permissions, which don't work so well in a CGI
>environment where the ViewVC script always runs as the same
>user regardless of who is sitting at the browser on the other
>end of the wire. But what about CVSNT, which has its own ACL
>subsystem? Wouldn't someone using that for their CVSNT
>installation presumably want to also use it for their ViewVC
>views? And how then would that make sense as a VC-agnostic
>authz plugin?
>
I understand that it is cool to be able to add something to CVS that is
not there yet, but that is not what ViewVC is intended to do. I would
rather see that that is fixed in CVS, but I wonder if that'll happen.
I would rather see them separated, it seems like abuse of subversion
related functionality for CVS or whatever other version control software
might be supported in future.
When you have the layers rights (which I've not determined yet), then it
should be possible to derive an authorization module for CVS based on
the Subversion one. I think it is best to keep it separated, also
because it keeps the code much clearer, and you will not break stuff for
one versioning system when working on another.
Maybe it is better to take on one problem at a time, so I suggest the
following order:
1) initially only authz support for Subversion, and not just because I
use that versioning system, but the whole idea of authorization in
ViewVC originates from the Subversion authorization, right?
2) derive an initial version for CVS from the Subversion authz module,
and see how it is received in the community
3) anything other authz issues (CVSNT ACL, etc)
>Finally, of interest (and issue) here is ViewVC
>configurability. Right now, you can define per-authz
>configurations, per-root configurations, and per-vhost
>configurations, and to be honest, I can't recall at the moment
>in which order they get handled. Part of me thinks that
>what's provided is too complex already. Part of me thinks
>that what's provided isn't enough because there's not also
>per-VCS configuration ("use 'svnauthz' for all Subversion
>roots, use 'forbidden' for all CVS roots", e.g.).
>
Hmm, I this is something out of my scope. I use only one authz file in
my configuration which is used for all subversion repositories. The
reason for this is that we use a single Bugzilla installation for
authentication and generate the authz file from the Bugzilla database.
We also have Subversion integrated with Bugzilla using ScmBug.
It would be nice to be able to specify it per configured root, with a
default for a specific kind of VC.
This would mean that when you have say 4 Subversion repositories for
which you want to configure a different authz configuration for only
one, then it would be nice to have to configure only one svnauthz for
the one repository and one for the rest. Same applies to any other VC.
>Any and all thoughts and suggestions on how to untangle this
>mess are very much appreciated -- I'm not opposed to ripping
>out the authz stuff and starting afresh if that's what's required.
Only if you have to.
>
>And I'm *terribly* sorry for not having reached out for help
>much earlier than this. ViewVC users deserve better than that.
>
You have now, that is what counts.
>-- C-Mike
>
>PS: There are other things that I think would be nice to get
>into ViewVC
> 1.1, such as unification of the markup and annotate views. But
> maybe we should just get the thing out the door ASAP with working
> authz stuff. At some point I'd like to do a deep performance-
> improvement dive, too. I've got some ideas on that already that
> I'm pretty excited about.
Cool!
>
>--
>C. Michael Pilato <cmpilato@xxxxxxxxxx>
>CollabNet <> www.collab.net <> Distributed Development
>On Demand
>
>
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender. Thank you.
|
