You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2005/02/16 03:33:26 UTC
RFA: Encrypting auth info
Well, here I am, opening this issue again myself.
It turns out that, for some applications, having encrypted auth data
would be a Good Thing indeed. The situation I'm specifically looking at
is this:
* Most developers in a company have Windows boxes on their desks
* Most Subversion servers are Unix boxes of one flavour or another
* Everyone wants to use thir Windows password to access the SVN
repositories
So, your friendly neighbour administrator teaches the Apaches on the
Unixen (via pam_smb, pam_winbindd, pam_ldap, or whatever) to
authenticate against a Windows domain or Active Directory.
The trouble is, now, that everybody's Windows password gets stored in
plaintext in their Subversion config area. Same friendly administrator
gets the bright idea to encdypt (using filsystem encryption) the auth
area. But... some people don't or can't use NTFS; some of the user
config areas are in fact mounted on Samba shares.
Luckily for said administrator, the Win32 CryptoAPI provides functions
for encrypting and decrypting thata with a session key that Windows
magically associates with the logged-on user. So he gets the bright idea
to add generic encryption support to the svn auth functions. (And I
really _do_ mean encryption, not som ROT-13 obfuscation scheme.)
End of story, and here's the question:
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
* add encryption functions to libsvn_subr, and let the auth
providers use them as they see fit.
If I decide on the second solution, I'd initially only encrypt the
passwords stored by the simple auth provider, and perhaps later for the
cert_pw provider. In any case, I don't propose to add a full-blown
crypto API to Subversion.
I think doing it this way would be better and simpler than writing some
kind of svn agent to store plaintext passwords, and would certainly be
less intrusive.
So: Any suggestions or ideas?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Jani Averbach wrote:
>On 2005-02-16 04:33+0100, Branko ??ibej wrote:
>
>
>>I basically see two ways to go about this:
>>
>>
>...
>
>
>>So: Any suggestions or ideas?
>>
>>
>>
>
>Please check with our lovely turtle how it is doing that, TSVN has
>implemented this already.
>
>
I know it has, and I have looked. I'm not interested in techniques, I'm
asking for advice WRT the Subversion auth API. TortoiseSVN circumvents
quite a bit of that, it doesn't even share the auth info with the
command-line client (which is understandable, given that they're
encrypting it).
What I want first is a generic interface for auth info encryption that
other platforms can use. I don't want more platform-specific hacks in
the code than strictly necessary.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-02-16 04:33+0100, Branko ??ibej wrote:
>
> I basically see two ways to go about this:
...
> So: Any suggestions or ideas?
>
Please check with our lovely turtle how it is doing that, TSVN has
implemented this already.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 16, 2005 5:00 PM +0100 "Branko ?ibej" <br...@xbc.nu>
wrote:
> Why? I know I said "encrypt the password", but what I really mean is "handle
> sensitive data", and nobody should know or care about what the
> implementation does. Right now we face the situation that it's not even
> obvious from the code /which/ data are sensitive.
>
> Why should the average user have to worry about encrypting their
> ~/.subversion/auth, if the package maintainer can do it provided we give
> them the right hooks (which they currently don't have)?
Sure we do. We can add platform-specific auth providers 'til the cows come
home. In fact, we could add one 'encrypting' provider which has a bunch of
platform-specific #ifdef's if we think that's better. The drawback of a
shared provider means that we'd jeopardize WC portability. So in fact, yes, I
think each crypto-providing auth provider needs to be distinct with its own
namespace under ~/.subversion/auth/.
I feel the details of the crypto engine need not leak from the auth provider.
And, I'm against providing a fake veneer of security - such as claiming ROT-13
provides the same degree of security as Win32's special CryptoAPI.
> And because we don't have this mechanism in our API, other clients
> (TortoiseSVN is an example here) aren't sharing auth info with the
> command-line client.
I think it says more about those clients than it does our design. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Mark Phippard <Ma...@softlanding.com>.
Justin Erenkrantz <ju...@erenkrantz.com> wrote on 02/17/2005 09:57:32 AM:
> --On Thursday, February 17, 2005 1:07 PM +0100 "Branko ?ibej"
<br...@xbc.nu>
> wrote:
>
> > Wow. This looks like it, all right. Now if only Apache grew a module
that
> > could handle this on Unix (passing on to an NT domain or ADS
server)...
>
> mod_auth_ldap works just fine against AD servers. -- justin
But isn't the issue they are talking about the "automatic" SSPI
authentication where the username/passwords are all exchanged
automatically based on your login to the Windows client? Yes, LDAP
authenticates against AD, but the problem is that Subversion will prompt
for and cache in plain text your AD password. With SSPI it is all handled
at a lower level so the user would never be prompted and nothing would
need to be cached.
There is an SSPI module for Windows Apache, but not other platforms.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, February 17, 2005 1:07 PM +0100 "Branko ?ibej" <br...@xbc.nu>
wrote:
> Wow. This looks like it, all right. Now if only Apache grew a module that
> could handle this on Unix (passing on to an NT domain or ADS server)...
mod_auth_ldap works just fine against AD servers. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Nicklas Norling wrote:
> Greg Stein wrote:
>
>> On Wed, Feb 16, 2005 at 05:00:27PM +0100, Branko ??ibej wrote:
>>
>>
>>> Justin Erenkrantz wrote:
>>> ...
>>>
>>>
>>>> And, there is the fundamental problem: we have no way of
>>>> guaranteeing cross-platform strong encryption. If Win32 can do
>>>> this, then just add a Win32-only provider. Yet, one API that has
>>>> strong encryption on Win32, but ROT-13 on Unix is incredibly
>>>> dangerous.
>>>>
>>>
>>> Why? I know I said "encrypt the password", but what I really mean is
>>> "handle sensitive data",
>>>
>>
>>
>> Frankly, I'd rather see Neon grow an understanding of how to send an
>> HTML
>> challenge/response. Then SVN could simply use Windows' single sign-on,
>> assuming that Apache was also configured with mod_ntlm or somesuch.
>>
>>
>>
> Is this what you where looking for?
> http://mailman.webdav.org/pipermail/neon/2005-January/001849.html
> /Nicke
Wow. This looks like it, all right. Now if only Apache grew a module
that could handle this on Unix (passing on to an NT domain or ADS server)...
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Nicklas Norling <ex...@exinor.net>.
Greg Stein wrote:
>On Wed, Feb 16, 2005 at 05:00:27PM +0100, Branko ??ibej wrote:
>
>
>>Justin Erenkrantz wrote:
>>...
>>
>>
>>>And, there is the fundamental problem: we have no way of guaranteeing
>>>cross-platform strong encryption. If Win32 can do this, then just add
>>>a Win32-only provider. Yet, one API that has strong encryption on
>>>Win32, but ROT-13 on Unix is incredibly dangerous.
>>>
>>>
>>Why? I know I said "encrypt the password", but what I really mean is
>>"handle sensitive data",
>>
>>
>
>Frankly, I'd rather see Neon grow an understanding of how to send an HTML
>challenge/response. Then SVN could simply use Windows' single sign-on,
>assuming that Apache was also configured with mod_ntlm or somesuch.
>
>
>
Is this what you where looking for?
http://mailman.webdav.org/pipermail/neon/2005-January/001849.html
/Nicke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>Frankly, I'd rather see Neon grow an understanding of how to send an HTML
>challenge/response. Then SVN could simply use Windows' single sign-on,
>assuming that Apache was also configured with mod_ntlm or somesuch.
>
>
Yes, that would certainly be the nicest solution (provided that the
apache module worked on Unix, too -- which should be doable).
Unfortunately, that's a _much_ more complex job than what I'm doing now.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-02-16 at 17:52, Greg Stein wrote:
> Frankly, I'd rather see Neon grow an understanding of how to send an HTML
> challenge/response. Then SVN could simply use Windows' single sign-on,
> assuming that Apache was also configured with mod_ntlm or somesuch.
You mean, HTTP negotiate auth? That's already supported in neon,
although it might only work on Unix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 16, 2005 at 05:00:27PM +0100, Branko ??ibej wrote:
> Justin Erenkrantz wrote:
>...
> >And, there is the fundamental problem: we have no way of guaranteeing
> >cross-platform strong encryption. If Win32 can do this, then just add
> >a Win32-only provider. Yet, one API that has strong encryption on
> >Win32, but ROT-13 on Unix is incredibly dangerous.
>
> Why? I know I said "encrypt the password", but what I really mean is
> "handle sensitive data",
This seems to be a bit counter to your "don't want a crypto API" comment.
Note that the "secure" place in Unix could be an environment variable. It
could even be like ssh-agent and have an env variable describe how to ask
the agent process for the information.
But as pointed out, the auth framework was designed specifically to enable
these kinds of variances. And I would *much* rather see a custom Windows
auth provider than some sort of pseudo-optional-thingy in the config apis.
And yes, I saw the note that you're going with the custom provider. Cool!
Frankly, I'd rather see Neon grow an understanding of how to send an HTML
challenge/response. Then SVN could simply use Windows' single sign-on,
assuming that Apache was also configured with mod_ntlm or somesuch.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Wednesday, February 16, 2005 4:40 PM +0100 "Branko ?ibej"
> <br...@xbc.nu> wrote:
>
>> 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
>
>
> And, there is the fundamental problem: we have no way of guaranteeing
> cross-platform strong encryption. If Win32 can do this, then just add
> a Win32-only provider. Yet, one API that has strong encryption on
> Win32, but ROT-13 on Unix is incredibly dangerous.
Why? I know I said "encrypt the password", but what I really mean is
"handle sensitive data", and nobody should know or care about what the
implementation does. Right now we face the situation that it's not even
obvious from the code /which/ data are sensitive.
Why should the average user have to worry about encrypting their
~/.subversion/auth, if the package maintainer can do it provided we give
them the right hooks (which they currently don't have)?
And because we don't have this mechanism in our API, other clients
(TortoiseSVN is an example here) aren't sharing auth info with the
command-line client.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 16, 2005 4:40 PM +0100 "Branko ?ibej" <br...@xbc.nu>
wrote:
> 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
And, there is the fundamental problem: we have no way of guaranteeing
cross-platform strong encryption. If Win32 can do this, then just add a
Win32-only provider. Yet, one API that has strong encryption on Win32, but
ROT-13 on Unix is incredibly dangerous. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
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
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Here's a transcript of my discussion on IRC with Ben about this.
sussman <irc://irc.eu.freenode.net/sussman,isnick> brane: what I mean
is, rather than putting #ifdef win32 into libsvn_subr
sussman <irc://irc.eu.freenode.net/sussman,isnick> why not just put
that into the build system
brane huh?
sussman <irc://irc.eu.freenode.net/sussman,isnick> if you're building
on win32, poof, you get these extra providers built
sussman <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> is there any way to
get crypted passwords on unix too?
brane but then we'd suddenty have a different *API* on windows
sussman <irc://irc.eu.freenode.net/sussman,isnick> or is win32 the
only api that makes this convenient?
brane and we've never had one of those yet
sussman <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> yup, I've been
arguing for it for a long time.
sussman <irc://irc.eu.freenode.net/sussman,isnick> but breser is
really against rot-13. :-)
brane i understand his pov completely
sussman <irc://irc.eu.freenode.net/sussman,isnick> maybe it could be a
run-time option, that the user chooses
sussman <irc://irc.eu.freenode.net/sussman,isnick> "please rot-13 my
cache"
sussman <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> so unix folks
really have no equivalent.
sussman <irc://irc.eu.freenode.net/sussman,isnick> no real crypto
available.
brane sure they do
brane openssl has it
brane the difference is in the conriguration
sussman <irc://irc.eu.freenode.net/sussman,isnick> ah.
sussman <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> can you elaborate?
sussman <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> 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 <irc://irc.eu.freenode.net/sussman,isnick> ahhhh
sussman <irc://irc.eu.freenode.net/sussman,isnick> so, can you
followup to the dev@ mail with these excellent hypothetical ideas?
sussman <irc://irc.eu.freenode.net/sussman,isnick> this is what I was
looking for
brane i think i'll just paste a transcript
Branko Čibej wrote:
> Well, here I am, opening this issue again myself.
>
> It turns out that, for some applications, having encrypted auth data
> would be a Good Thing indeed. The situation I'm specifically looking
> at is this:
>
> * Most developers in a company have Windows boxes on their desks
> * Most Subversion servers are Unix boxes of one flavour or another
> * Everyone wants to use thir Windows password to access the SVN
> repositories
>
> So, your friendly neighbour administrator teaches the Apaches on the
> Unixen (via pam_smb, pam_winbindd, pam_ldap, or whatever) to
> authenticate against a Windows domain or Active Directory.
>
> The trouble is, now, that everybody's Windows password gets stored in
> plaintext in their Subversion config area. Same friendly administrator
> gets the bright idea to encdypt (using filsystem encryption) the auth
> area. But... some people don't or can't use NTFS; some of the user
> config areas are in fact mounted on Samba shares.
>
> Luckily for said administrator, the Win32 CryptoAPI provides functions
> for encrypting and decrypting thata with a session key that Windows
> magically associates with the logged-on user. So he gets the bright
> idea to add generic encryption support to the svn auth functions. (And
> I really _do_ mean encryption, not som ROT-13 obfuscation scheme.)
>
> End of story, and here's the question:
>
> 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
> * add encryption functions to libsvn_subr, and let the auth
> providers use them as they see fit.
>
> If I decide on the second solution, I'd initially only encrypt the
> passwords stored by the simple auth provider, and perhaps later for
> the cert_pw provider. In any case, I don't propose to add a full-blown
> crypto API to Subversion.
>
> I think doing it this way would be better and simpler than writing
> some kind of svn agent to store plaintext passwords, and would
> certainly be less intrusive.
>
> So: Any suggestions or ideas?
>
> -- Brane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 16, 2005 4:33 AM +0100 "Branko ?ibej" <br...@xbc.nu>
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
> * add encryption functions to libsvn_subr, and let the auth
> providers use them as they see fit.
Based on your description, I'd just add a new Win32-only auth provider that
handles the encryption/decryption using those APIs. I doubt it will be
portable, so placing it in libsvn_subr doesn't make sense. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
steveking wrote:
> Branko Čibej wrote:
>
>> Oh, certainly I can write a Windows-specific provider. Doing so will
>> make Windows users happy (at least, those using Win2k and newer). It
>> will add about the same amount of #fdefing into the code as the other
>> way would. But I'm hoping for a more generic solution that can be
>> used on other systems, too.
>
>
> If you're interested in such a provider: TSVN already has one:
> https://svn.collab.net/repos/tortoisesvn/trunk/src/SVN/auth_providers.h
> https://svn.collab.net/repos/tortoisesvn/trunk/src/SVN/auth_providers.cpp
Saw that, thanks!
/me checked out the tsvn trunk yesterday
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by steveking <st...@gmx.ch>.
Branko Čibej wrote:
> Oh, certainly I can write a Windows-specific provider. Doing so will
> make Windows users happy (at least, those using Win2k and newer). It
> will add about the same amount of #fdefing into the code as the other
> way would. But I'm hoping for a more generic solution that can be used
> on other systems, too.
If you're interested in such a provider: TSVN already has one:
https://svn.collab.net/repos/tortoisesvn/trunk/src/SVN/auth_providers.h
https://svn.collab.net/repos/tortoisesvn/trunk/src/SVN/auth_providers.cpp
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Wednesday, February 16, 2005 5:04 PM +0100 "Branko ?ibej"
> <br...@xbc.nu> wrote:
>
>> Oh, certainly I can write a Windows-specific provider. Doing so will
>> make
>> Windows users happy (at least, those using Win2k and newer). It will add
>> about the same amount of #fdefing into the code as the other way
>> would. But
>> I'm hoping for a more generic solution that can be used on other
>> systems,
>> too.
>
>
> I don't see how that many #ifdef's would be added. You'd plop in a
> new provider file that is only built on Win32 and add an #ifdef
> pushing that provider to the auth stack to
> subversion/clients/cmdline/main.c.
Yes, that's about the number of #ifdefs I'd expect in any case :-)
> I don't think it's going to be possible to find a generic solution
> that can be used on all other platforms. However, if we start to
> spawn 10 different crypto-based auth providers, we could then think
> about ways to abstract it out later on. However, it just seems too
> early for abstraction. -- justin
All right. I'll go with a custom provider, then.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 16, 2005 5:04 PM +0100 "Branko ?ibej" <br...@xbc.nu>
wrote:
> Oh, certainly I can write a Windows-specific provider. Doing so will make
> Windows users happy (at least, those using Win2k and newer). It will add
> about the same amount of #fdefing into the code as the other way would. But
> I'm hoping for a more generic solution that can be used on other systems,
> too.
I don't see how that many #ifdef's would be added. You'd plop in a new
provider file that is only built on Win32 and add an #ifdef pushing that
provider to the auth stack to subversion/clients/cmdline/main.c.
I don't think it's going to be possible to find a generic solution that can be
used on all other platforms. However, if we start to spawn 10 different
crypto-based auth providers, we could then think about ways to abstract it out
later on. However, it just seems too early for abstraction. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Wednesday, February 16, 2005 4:49 PM +0100 "Branko ?ibej"
> <br...@xbc.nu> wrote:
>
>> And ntfs has native encryption on Windows, too. But that's not the
>> point.
>
>
> Yes, it is. You are trying to sneak in bloated functionality into
> Subversion that is best handled elsewhere - preferably by the OS itself.
I explained in my original post why that isn't always an option.
Oh, certainly I can write a Windows-specific provider. Doing so will
make Windows users happy (at least, those using Win2k and newer). It
will add about the same amount of #fdefing into the code as the other
way would. But I'm hoping for a more generic solution that can be used
on other systems, too.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 16, 2005 4:49 PM +0100 "Branko ?ibej" <br...@xbc.nu>
wrote:
>> There is no real portable way to encrypt and decrypt sensitive data.
>> And, only the simple auth provider has passwords that would need to be
>> encrypted. So, none of the other auth providers would benefit from this.
>
> At least one of thos we have now would, the cert_pw provider.
That provider doesn't write anything to disk.
>> Furthermore, on most Unix OSes, you are far better off using an
>> encrypted file system. Linux (dm-crypt), Darwin (FileVault), and
>> FreeBSD (gdbe) all have this functionality to various degrees.
>
> And ntfs has native encryption on Windows, too. But that's not the point.
Yes, it is. You are trying to sneak in bloated functionality into Subversion
that is best handled elsewhere - preferably by the OS itself. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Wednesday, February 16, 2005 4:29 PM +0100 "Branko ?ibej"
> <br...@xbc.nu> wrote:
>
>> I really disagree with this. I don't want the idea of encrypting
>> sensitive
>> data to be specific to one OS, or to a particular auth provid
>> configuration .
>
>
> There is no real portable way to encrypt and decrypt sensitive data.
> And, only the simple auth provider has passwords that would need to be
> encrypted. So, none of the other auth providers would benefit from this.
At least one of thos we have now would, the cert_pw provider.
> Furthermore, on most Unix OSes, you are far better off using an
> encrypted file system. Linux (dm-crypt), Darwin (FileVault), and
> FreeBSD (gdbe) all have this functionality to various degrees.
And ntfs has native encryption on Windows, too. But that's not the point.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 16, 2005 4:29 PM +0100 "Branko ?ibej" <br...@xbc.nu>
wrote:
> I really disagree with this. I don't want the idea of encrypting sensitive
> data to be specific to one OS, or to a particular auth provid configuration .
There is no real portable way to encrypt and decrypt sensitive data. And,
only the simple auth provider has passwords that would need to be encrypted.
So, none of the other auth providers would benefit from this.
Furthermore, on most Unix OSes, you are far better off using an encrypted file
system. Linux (dm-crypt), Darwin (FileVault), and FreeBSD (gdbe) all have
this functionality to various degrees. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Ben Collins-Sussman <su...@collab.net>.
On Feb 16, 2005, at 9:29 AM, Branko Čibej wrote:
>>
>> I think creating that interface just goes too far. You can just
>> create a new auth provider which happens to encrypt or decrypt using
>> that fancy Win32 API as it stores/reads things on disk. But, nothing
>> else even needs to be aware of this particular functionality. --
>> justin
>>
> I really disagree with this. I don't want the idea of encrypting
> sensitive data to be specific to one OS, or to a particular auth
> provid configuration .
>
The authn system is designed around the idea of many provider
implementations for managing the same type of credentials.
So the idea of encrypting sensitive data wouldn't be specific to one
OS, it would be specific to one (or a set) of providers. And then a
particular *provider* would be specific to one OS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> --On Wednesday, February 16, 2005 4:08 PM +0100 "Branko ?ibej"
> <br...@xbc.nu> wrote:
>
>> 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?
>
>
> I think creating that interface just goes too far. You can just
> create a new auth provider which happens to encrypt or decrypt using
> that fancy Win32 API as it stores/reads things on disk. But, nothing
> else even needs to be aware of this particular functionality. -- justin
>
I really disagree with this. I don't want the idea of encrypting
sensitive data to be specific to one OS, or to a particular auth provid
configuration .
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 16, 2005 4:08 PM +0100 "Branko ?ibej" <br...@xbc.nu>
wrote:
> 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?
I think creating that interface just goes too far. You can just create a new
auth provider which happens to encrypt or decrypt using that fancy Win32 API
as it stores/reads things on disk. But, nothing else even needs to be aware
of this particular functionality. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFA: Encrypting auth info
Posted by Branko Čibej <br...@xbc.nu>.
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
Re: RFA: Encrypting auth info
Posted by Ben Collins-Sussman <su...@collab.net>.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org