On Apr 5, 2012 6:39 PM, "C. Michael Pilato" <cmpil...@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