You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2008/06/09 19:26:19 UTC
Re: Call for assistance (Was: [Issue 3061] username + password +
non-interactive caches creds wrong)
On Mon, Jun 09, 2008 at 10:32:33AM -0700, Jack Repenning wrote:
> > ------- Additional comments from danielsh@tigris.org Mon Jun 9
> > 01:05:37 -0700 2008 -------
> > In non-interactive mode, it defaults to saving it (for
> > compatibility)
That's wrong. See the comments in these code snippets from
subversion/libsvn_subr/simple_providers.c (on trunk).
They document the current behaviour.
if (svn_cstring_casecmp(store_plaintext_passwords,
SVN_CONFIG_ASK) == 0)
{
if (non_interactive)
/* In non-interactive mode, the default behaviour is
* to not store the password, because it is usually
* passed on the command line. */
may_save_password = FALSE;
else if (b->plaintext_prompt_func)
{
/* We're interactive, and the client provided a
* prompt callback. So we can ask the user.
*
// some stuff omitted here, this function call asks the user:
SVN_ERR((*b->plaintext_prompt_func)(&may_save_password,
realmstring,
b->prompt_baton,
pool));
// some stuff omitted here
}
else
{
/* TODO: We might want to default to not storing if the
* prompt callback is NULL, i.e. have may_save_password
* default to FALSE here, in order to force clients to
* implement the callback.
*
* This would change the semantics of old API though.
*
* So for now, clients that don't implement the callback
* and provide no explicit value for
* SVN_AUTH_PARAM_STORE_PLAINTEXT_PASSWORDS
* cause unencrypted passwords to be stored by default.
* Needless to say, our own client is sane, but who knows
* what other clients are doing.
*/
may_save_password = TRUE;
}
The above comment means that if you use any client other than the
svn command line client (such as svnX), by the time we release 1.6,
you should ask the developers of your client to implement the callback
that asks the user whether saving passwords in plaintext is OK.
Else their client will cause our library to save the password in plaintext,
except in --non-interactive mode. We don't ever store plaintext passwords
in non-interactive mode anymore in current trunk (and thus 1.6).
> Here's the necessary test case, in case it's not apparent in the issue:
>
> 1. OS X Tiger + SVN 1.4.x history, with some credentials stored in
> keychain, none in ~/.subversion/auth/svn.simple
> 2. also nuke relevant creds from Apple Keychain
> 3. upgrade to Leopard (or, if you're already on Leopard, nuke any auth/
> svn.simple/* containing passwords)
> 4. no 1.5-specific configuration changes (no use of new "store-
> plaintext-passwords" setting)
That setting is trunk-specific, not 1.5-specific :)
> 5. build SVN trunk
> 6. install svnX, preferences point to your trunk SVN
> 7. Use svnX to browse some repository that requires credentials to
> browse
>
> Definition of "fail":
> Password appears in ~/.subversion/auth/svn.simple/*
>
> Definition of "pass":
> No password stored. I could live with failure of the operation,
> though it would be really cool if the op worked and the password was
> properly stuffed into the keychain
As explained above, if the tool uses --non-interactive, the password
should not be stored in plaintext with svn from current trunk.
So I guess Daniel is right -- this could be used to somewhat steer around
the fact that SecKeychainSetUserInteractionAllowed(FALSE); renders Keychain
unable to give us the cached password for some bizarre reason.
(For those who don't know what I'm talking about, see
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133862
which details the reason behind Jack's problem).
But isn't there a catch? To authenticate during --non-interactive without
having access to a cached password from Keychain, you need to pass
--password on the command line. Which probably means that your password
is saved in your shell's history instead of the svn auth area, right?
No idea which is the lesser evil :/
Stefan
Re: Call for assistance (Was: [Issue 3061] username + password +
non-interactive caches creds wrong)
Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
Stefan Sperling wrote on Mon, 9 Jun 2008 at 21:26 +0200:
> On Mon, Jun 09, 2008 at 10:32:33AM -0700, Jack Repenning wrote:
> > > ------- Additional comments from danielsh@tigris.org Mon Jun 9 01:05:37 -0700 2008 -------
> > > In non-interactive mode, it defaults to saving it (for
> > > compatibility)
>
> That's wrong. See the comments in these code snippets from
> subversion/libsvn_subr/simple_providers.c (on trunk).
> They document the current behaviour.
>
Oops, sorry. Thanks for correcting me. (I already posted earlier a
correction on the issue (#desc7) when I realised my mistake.)
> As explained above, if the tool uses --non-interactive, the password
> should not be stored in plaintext with svn from current trunk.
>
> So I guess Daniel is right -- this could be used to somewhat steer around
> the fact that SecKeychainSetUserInteractionAllowed(FALSE); renders Keychain
> unable to give us the cached password for some bizarre reason.
> (For those who don't know what I'm talking about, see
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133862
> which details the reason behind Jack's problem).
>
> But isn't there a catch? To authenticate during --non-interactive without
> having access to a cached password from Keychain, you need to pass
> --password on the command line. Which probably means that your password
> is saved in your shell's history instead of the svn auth area, right?
> No idea which is the lesser evil :/
>
There is also the option to use kwallet or gnome-keyring. (If they are
they available on OS X?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Call for assistance (Was: [Issue 3061] username + password + non-interactive caches creds wrong)
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jun 9, 2008 at 5:00 PM, Jack Repenning <ja...@tigris.org> wrote:
> On Jun 9, 2008, at 1:50 PM, Mark Phippard wrote:
>
>> FWIW, Subclipse (and other JavaHL consumers) also create these creds.
>> When the keychain support was added in 1.4, it was not added to
>> JavaHL. Until the recent Gnome/KDE stuff was added, I did not know it
>> needed to be.
>
> You mean, "in cleartext, in the file system," I take it. So that's a good
> argument for the fix I already made, to use such creds if they exist.
>
> Any idea how these behave under the broken Leopard
> SecKeychainSetUserInteractionAllowed()?
>
> Do they even call that? If not, they needn't care that it's broken.
If there is even an equivalent of --non-interactive in JavaHL, we do
not use it. I have never noticed any problem going between the
command line and Subclipse. Although perhaps I was prompted to cache
credentials twice and just did not pay attention. Basically, I never
noticed it until looking at the code to add the new stuff in and
seeing that the command line had code to use the Keychain and JavaHL
did not.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Call for assistance (Was: [Issue 3061] username + password + non-interactive caches creds wrong)
Posted by Jack Repenning <ja...@tigris.org>.
On Jun 9, 2008, at 1:50 PM, Mark Phippard wrote:
> FWIW, Subclipse (and other JavaHL consumers) also create these creds.
> When the keychain support was added in 1.4, it was not added to
> JavaHL. Until the recent Gnome/KDE stuff was added, I did not know it
> needed to be.
You mean, "in cleartext, in the file system," I take it. So that's a
good argument for the fix I already made, to use such creds if they
exist.
Any idea how these behave under the broken Leopard
SecKeychainSetUserInteractionAllowed()?
Do they even call that? If not, they needn't care that it's broken.
-==-
Jack Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Call for assistance (Was: [Issue 3061] username + password + non-interactive caches creds wrong)
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jun 9, 2008 at 4:45 PM, Jack Repenning <ja...@tigris.org> wrote:
> In any case, I'm in an odd spot, here: I don't maintain any of these
> wrappers, and indeed they don't fit my personal work style, so I don't even
> use them. My project, SCPlugin, uses the SVN APIs. I discovered the
> problem indirectly: because of the odd fail-through sequence in the
> command-line tool, these GUI wrappers _were_ storing creds in cleartext in
> svn.simple/, even though the command-line binary they use stores them in the
> keychain; when I cam along later, I couldn't find the creds (because I was
> not looking in svn.simple/, only in the keychain). I fixed that, so I will
> find svn.simple/ creds if necessary, so I have no more problem, really. I
> am now trying to represent these several GUI wrapper developer communities
> by proxy. I've tried to contact them, without response, but since many of
> my users are also users of theirs, I want these things to work right.
FWIW, Subclipse (and other JavaHL consumers) also create these creds.
When the keychain support was added in 1.4, it was not added to
JavaHL. Until the recent Gnome/KDE stuff was added, I did not know it
needed to be.
So your credentials could also be coming from those tools.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Call for assistance (Was: [Issue 3061] username + password + non-interactive caches creds wrong)
Posted by Jack Repenning <ja...@tigris.org>.
On Jun 10, 2008, at 3:45 AM, Stefan Sperling wrote:
> But 3rd party client developers may need to take some action in order
> for plaintext password caching to work properly with their client.
> They need to implement a way our library can use to ask the user
> whether plaintext password caching is OK, in case users do not
> indicate
> any preference in their config files.
>
> How 3rd party developers can do this is straightforward and well
> documented in our API, so I don't expect many problems with clients
> that use the API directly.
I'll certainly second that. Prompted by this discussion, I went
looking. I'm a "3rd party developer" (on scplugin), and the member of
my community who last touched our interface to all this, and it took
me less than five minutes to figure out what we'll need to do; may
take me a day to code and verify.
-==-
Jack Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Call for assistance (Was: [Issue 3061] username + password +
non-interactive caches creds wrong)
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jun 09, 2008 at 01:45:21PM -0700, Jack Repenning wrote:
>
> On Jun 9, 2008, at 12:26 PM, Stefan Sperling wrote:
>
> > The above comment means that if you use any client other than the
> > svn command line client (such as svnX), by the time we release 1.6,
> > you should ask the developers of your client to implement the callback
> > that asks the user whether saving passwords in plaintext is OK.
>
> Not sure I parse this, so just for clarity: svnX does use the command
> line (building command-line invocations and parsing command-line
> output).
What I said above only applies to clients that use the API directly.
> > Else their client will cause our library to save the password in
> > plaintext,
> > except in --non-interactive mode. We don't ever store plaintext
> > passwords
> > in non-interactive mode anymore in current trunk (and thus 1.6).
>
> That's going to be a problem for the likes of svnX, since they do
> everything --non-interactive, yet rely upon SVN to cache credentials
> (and users would prefer this cache be secure).
Well, what I said above lacks an important exception:
Our command line client only defaults to not storing plaintext
passwords in non-interactive mode if the user has not configured
any other behaviour in the config file.
Once users configure Subversion to use the plaintext cache,
the creds will be stored there. So for svnX, the plaintext cache
isn't broken, it just won't be used by default anymore.
It would be nicer if they could use Keychain, of course. But because
of the --non-interactive bug we're seeing with the Keychain API I don't
see much chance that we can make this work from our side.
We (that includes us as well as the svnX developer and user community)
need to get Apple to fix this.
Or people who are affected by this decide to cut their ties to a
closed-source vendor and switch to a free OS where this kind of bug
could be comparatively trivially fixed by the end user *cough* ;)
> > But isn't there a catch? To authenticate during --non-interactive
> > without
> > having access to a cached password from Keychain, you need to pass
> > --password on the command line. Which probably means that your
> > password
> > is saved in your shell's history instead of the svn auth area, right?
> > No idea which is the lesser evil :/
>
> Not the shell's history, since these wrappers don't use an interactive
> shell; they invoke the command-line tool via popen() (or language-
> specific equivalent). There may be a copy of the user's login shell
> involved there, but it's not interactive and doesn't save history.
> There's some risk of leakage through "ps" and the like.
OK, but leakage via ps is also pretty bad.
> I am now trying to
> represent these several GUI wrapper developer communities by proxy.
> I've tried to contact them, without response, but since many of my
> users are also users of theirs, I want these things to work right.
They should certainly work right. But not at the expense of leaking
plaintext passwords to disk without the user's consent. That's what
the dont-save-plaintext-passwords-by-default branch was all about,
after all.
If anyone has any further questions regarding the new plaintext caching
behaviour in 1.6 and its consequences, don't hesitate to ask.
We certainly don't want to break 3rd party tools with this.
But 3rd party client developers may need to take some action in order
for plaintext password caching to work properly with their client.
They need to implement a way our library can use to ask the user
whether plaintext password caching is OK, in case users do not indicate
any preference in their config files.
How 3rd party developers can do this is straightforward and well
documented in our API, so I don't expect many problems with clients
that use the API directly.
As for tools that simply wrap the command line client, they will
get safe default behaviour anyway. It's unfortunate that the Keychain
cache is currently so broken that svnX can't use it, but that's not
our fault.
Stefan
Re: Call for assistance (Was: [Issue 3061] username + password + non-interactive caches creds wrong)
Posted by Jack Repenning <ja...@tigris.org>.
On Jun 9, 2008, at 12:26 PM, Stefan Sperling wrote:
> The above comment means that if you use any client other than the
> svn command line client (such as svnX), by the time we release 1.6,
> you should ask the developers of your client to implement the callback
> that asks the user whether saving passwords in plaintext is OK.
Not sure I parse this, so just for clarity: svnX does use the command
line (building command-line invocations and parsing command-line
output).
> Else their client will cause our library to save the password in
> plaintext,
> except in --non-interactive mode. We don't ever store plaintext
> passwords
> in non-interactive mode anymore in current trunk (and thus 1.6).
That's going to be a problem for the likes of svnX, since they do
everything --non-interactive, yet rely upon SVN to cache credentials
(and users would prefer this cache be secure).
> But isn't there a catch? To authenticate during --non-interactive
> without
> having access to a cached password from Keychain, you need to pass
> --password on the command line. Which probably means that your
> password
> is saved in your shell's history instead of the svn auth area, right?
> No idea which is the lesser evil :/
Not the shell's history, since these wrappers don't use an interactive
shell; they invoke the command-line tool via popen() (or language-
specific equivalent). There may be a copy of the user's login shell
involved there, but it's not interactive and doesn't save history.
There's some risk of leakage through "ps" and the like.
In any case, I'm in an odd spot, here: I don't maintain any of these
wrappers, and indeed they don't fit my personal work style, so I don't
even use them. My project, SCPlugin, uses the SVN APIs. I discovered
the problem indirectly: because of the odd fail-through sequence in
the command-line tool, these GUI wrappers _were_ storing creds in
cleartext in svn.simple/, even though the command-line binary they use
stores them in the keychain; when I cam along later, I couldn't find
the creds (because I was not looking in svn.simple/, only in the
keychain). I fixed that, so I will find svn.simple/ creds if
necessary, so I have no more problem, really. I am now trying to
represent these several GUI wrapper developer communities by proxy.
I've tried to contact them, without response, but since many of my
users are also users of theirs, I want these things to work right.
-==-
Jack Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org