[ The following is pretty much stream-of-consciousness. Quite honestly, ] [ if I could organize my thoughts well enough to craft a better email, I'd ] [ probably not feel the need to write the mail so badly! ]
On the trunk, I have -- with vast amounts of help from gstein and danielsh -- implemented some routines for using a so-called master passphrase (see http://wiki.apache.org/subversion/MasterPassphrase) to encrypt and decrypt an arbitrary string of text, ostensibly a Subversion server password. I'll not claim that these functions would pass a security review -- in fact, I would welcome as many eyes as possible on libsvn_subr/crypto.[ch]! But they "work", at least enough to start wrapping other code around. Now I find myself trying to figure out how to best wrap code around them. Originally, I thought that I'd need a suite of "svn.masterpassphrase" providers -- siblings to the "svn.simple", "svn.username", "svn.ssl.client-cert" and "svn.ssl.client-passphrase" providers we already offer -- whose job it was to fetch/store the master passphrase from various OS-provided keyings or from the user (via prompt). But this seems wrong. The existing providers plug into a collection thereof used by consumers outside of libsvn_subr (such as the RA layer) to fetch network credentials. This ain't that kind of provider -- the master passphrase is an entirely system-local concept, the knowledge of which is really only required by the auth system itself (or specific providers within that system, depending on how we implement things). So, fine. The master passphrase stuff isn't a true svn_auth_provider_t. What is it, then? Some new provider-like thing that's simpler (only fetches and stores a single string, after all, not a whole set of various credential pieces) and private? Elsebrain, I'm looking at the existing auth provider code and hearing voices in my head, echoes of recent IRC conversations: "Our authn provider system is overly complex and needs a rewrite." "It's silly that every time we add a new caching store, we have to implement N differing provider flavors of it to cover all the cases." "Our auth cache storage layer needs a rewrite." I fully agree with these statements, but want to be careful not to find myself rewriting Subversion just to implement one feature, you know? I've been also frustrated when considering the situation that occurs when a user changes his/her master password, forcing a re-encryption of all cached credentials using the new password. The existing storage framework is a bunch of little files -- I've had as many as 50 of these things at times in my ~/.subversion/auth/ area. You'd really, really like to make a sweeping change such as a re-encryption of all cached passwords transactionally, not leaving half the credentials encrypted with an old passphrase if something goes wrong midstream. And for compatibility reasons, I really need to introduce brand new storage for this encrypted stuff anyway so new and old clients can co-exist on the same machine without trampling each other's (shared) runtime configuration directory. It would seem, then, that now *is* a good time to revisit at least the storage aspect of our authn subsystem, moving to SQLite's ACID goodness. I've taken a bit of a look-see at the existing storage, capturing my findings thus far at http://wiki.apache.org/subversion/AuthenticationCredentialCacheStorageOverhaul, and trying to find some commonality that would make for a decent DB schema. So. Wow. Is there anyone who is game for helping me tackle a new design for our client-side authn cache using SQLite? Should we also, then, attempt to redesign the whole of the auth provider system? If not, any suggestions on where the master passphrase fetch/store bits might best fit in? 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".) I mean, do third-party clients really need to pick and choose which providers they want to use? Sorry. I know the above reads like a train wreck of thought. That's what I've got to offer right now. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
