Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...

On Apr 5, 2012 6:39 PM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
>...
> Is there anyone who is game for helping me tackle a new design for our
> client-side authn cache using SQLite?

A little bit, sure.

>
> Should we also, then, attempt to redesign the whole of the auth provider
> system?

Preferable, if you're up for taking point.

> If not, any suggestions on where the master passphrase fetch/store
> bits might best fit in?

A new callback. But you definitely need a DSO option so core svn does not
have GNOME/KDE dependencies. Instead, they load a small DSO that implements
the master get/set functionality. Maybe a tiny vtable.

I think the OS-based ones are not DSO since there is no heavy dep chain to
be concerned about.

Dunno where GPG comes in. Is there a library and heavy deps associated with
that?

>
> If "yes" on redesigning the auth subsystem, can the new hotness be
> introduced via private APIs instead of public ones? (I'm not quite sure
why
> the current stuff is part of the public Subversion API anyway, unless it's
> just because way back then, we just didn't *do* "private-yet-exported
> APIs".)

Correct. We did not do cross-library private APIs that I can recall. It was
all public because we (I, really) didn't know what all we truly needed.

> I mean, do third-party clients really need to pick and choose which
> providers they want to use?

Not the types of auth, but the client needs a way to prompt. The client_ctx
prompt callback may be enough, but I dunno (does that support two inputs?
such as username and password).

But yes: the set of providers is likely fixed, given it is defined by our
RA layers. And if we add an RA layer, we can fine-tune the set.

(Of course, if we really support third-party RA layers, then we may need
more pluggable auth)

>...

Cheers,
-g
Received on 2012-04-06 04:34:01 CEST