Ben Collins-Sussman wrote:
>
> On Feb 15, 2005, at 9:33 PM, Branko Čibej wrote:
>
>>
>> I basically see two ways to go about this:
>>
>> * modify svn_config_(read|write)_auth_data to crypt everything, thus
>> localising the change in those functions, or define a second set
>> of config read/write functions that encrypt the data
>
>
> How would this happen? Through a bunch of "#ifdef win32" directives?
> This can't be generic, right?
>
>
>> * add encryption functions to libsvn_subr, and let the auth
>> providers use them as they see fit.
>>
>
> You say you "don't want to add a full-blown crypto API to
> Subversion"... but then I read the sentence above and get confused.
> What's the middle ground you're proposing? Some sort of "mini" crypto
> API? :-)
>
> Can you be more specific?
A full-blown crypto API is a beatie that encapsulates different
cryptographic providers, selectable ctypto and hash algorithms, and all
that. It can be a huge thing.
All we need is a pair of encrypt/decrypt functions that hide all that
compexity. Certainly, the implementation of said functions would be
OS-specific, and they might be no-ops on many systems. I'm most
emphatically /not/ proposing to add a buch of #ifdefs into the
implementation of svn_config_read_auth_data, for example.
The real question is then, should those encryption/decrypyion functions
be private th svn_config_auth, or should they be exported from
libsvn_subr for the various providers to use?
And, what form should those functions have? Is it a simple
svn_error_t *svn_auth_(en|de)crypt(svn_string_t *out, const
svn_string_t *in);
or do we want a slightly more generic interface that lets the auth
providers send in more than just, e.g., the password?
-- 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:09:17 2005