[ 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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-04-06 00:39:15 CEST