Branko Čibej wrote:
> Here's a transcript of my discussion on IRC with Ben about this.
Sorry about the mess... I hope this is better:
sussman: brane: what I mean is, rather than putting #ifdef win32 into libsvn_subr
sussman: why not just put that into the build system
brane : huh?
sussman: if you're building on win32, poof, you get these extra providers built
sussman: hm, I guess that's no different.
brane : oh, that -- well yes, certainly, something alng the lines of the bits in svn_config that fiddle with the registry
sussman: is there any way to get crypted passwords on unix too?
brane : but then we'd suddenty have a different *API* on windows
sussman: or is win32 the only api that makes this convenient?
brane : and we've never had one of those yet
sussman: mmmm
brane : i don't know about other oses
brane : on linux, i'd probably mount an encrypted file to ~/.subversion/auth through the loop device
brane : but that's equivaent to the ntfs encryption hack on Windows, and doesn't always work
brane : i'd much rather see a generic API that lets the auth provider say, "this bit of data is sensitive, do your best with it"
brane : on windows, we could use strong encryption
brane : on most unices, we could eventually be persuaded to ROT-13
brane : (really, all those who request this do have a point)
brane : althouth the false-sense-of-security argument still holds, of course
sussman: yup, I've been arguing for it for a long time.
sussman: but breser is really against rot-13. :-)
brane : i understand his pov completely
sussman: maybe it could be a run-time option, that the user chooses
sussman: "please rot-13 my cache"
sussman: or something
brane : no
brane : if i write code that encrypts the password on disk, i definitely don't want ti give the user a knob to turn that off
sussman: so unix folks really have no equivalent.
sussman: no real crypto available.
brane : sure they do
brane : openssl has it
brane : the difference is in the conriguration
sussman: ah.
sussman: so maybe svn could learn to detect and use openssl.
brane : on windows, the crypto framework maintains a per-user symmetric key in a "secure" place, so that the crypto functions don't have to ask for passwords and such
brane : (it hangs off the login session)
sussman: it just makes me sad to think that after so many requests for this feature, we're only fixing it on one OS. :-/
brane : see, that's why i started this discussion
sussman: I wish APR were doing this
brane : if we design our api correctly, then a packager can set up real encryption with the correct *compile time* options
brane : yes, well, apr isn't
sussman: can you elaborate?
sussman: with some hypothetical examples?
brane : let's suppose we have an encrypt/decrypt pair
brane : and compile-time configuration to select the implementation (crypto provider)
brane : on windows, of course, there's nothing to decide about
brane : on unix, we could supply a no-op and rot-13 provider
brane : (don't want to go into selecting defaults yet)
sussman: ah.
brane : a bright boy at RedHat could, for example, do some PAM magic that unlocks a user-specific key when you log in
brane : and compile in a special provider that could use that key
sussman: ahhhh
sussman: so, can you followup to the dev@ mail with these excellent hypothetical ideas?
sussman: this is what I was looking for
brane : i think i'll just paste a transcript
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 16 16:41:24 2005