"Justus Pendleton" <subversion@ryoohki.net> writes:
> Ben Collins-Sussman writes:
>
> > We have an architecture that looks like
> >
> > client app --> libsvn_client --> libsvn_ra
> >
> > The arrows indicate the direction of function calls. As a matter of
> > principle, we don't want an RA library to directly call some
> > libsvn_client routine (or client app routine) like
> > prompt_for_passphase(). It breaks the layered design if we start
> > allowing circular dependencies.
>
> I guess I'm not clear on why this is such an iron principle. Even if it
> adds a circular dependency -- I'm not really sure what you mean by that --
> that's orthogonal to the layered design concern, isn't it? Why can't
> something with circular dependencies have a layered design?
By "circular dependency", I mean "a pain to link." In fact, I'm not
even sure that the linker *can* deal with the situation.
Our layered design is client-centric in the sense our code-flow always
tries to keep the client in control. That's why we want function
calls to flow one direction.
Here are some examples:
* commits:
Client calls svn_client_commit(), which calls ra_commit(), which
returns an editor object. The client then describes the change
it's making by making calls into the editor; these calls move
all the way to the repository.
* updates:
Client calls svn_client_update(), which calls ra_update(), which
returns a reporter object. The client uses this object to tell
the repository what the working copy looks like, and then the
repository edits the working copy.
> For instance, I'm not sure how an authentication method that relied
> on a series of challenges and responses would be implemented with
> the method you described. But that might just be lack of
> imagination on my part :-)
No, this would be very tricky. I'm not sure how we'd do this either.
Hmm.
>
> > But a single "opaque shared secret" -- is that enough?
>
> I don't see why not. It's really just an index into a matrix of actions and
> whether they are allowed or not. The matrix would be constructed at
> authentication time by the RA. After authentication it doesn't matter how
> many pieces of information were required to generate the matrix. But I
> think maybe I'm misunderstanding something and the client session handle is
> all you really need. I guess it just seems like you only need the user
> authentication information to set up the permission matrix.
True -- but the authorization matrix exists not in the RA library, but
*beyond* it, in the actual repository/filesystem libraries. It might
be created by successful authentication, or it may have existed
already.
Either way, the critical idea here is that once libsvn_client has
opened a "session" with an RA library, it can repeatedly use the
session_baton to make different kinds of repository requests.
> After that's done the info is not only superfluous but potentially
> damaging, given that for at least some authentication schemes it
> will contain a cleartext password, isn't it?
Sure... but why are you assuming that the sensitive information
continues to live on, either in libsvn_client *or* in the RA layer?
For example -- perhaps the RA layer opened up a continuous, encrypted
network channel to a repository. Like ssh, the sensitive info was
needed only once to create the secure channel; but after its
creation, only a temporary throw-away keypair is used for encryption.
The original sensitive data can be freed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006