You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jack Repenning <jr...@collab.net> on 2008/01/02 23:44:56 UTC
Question Re: Bug with "--non-interactive" (issue 3059)
Recall: OS X Leopard just plain breaks the API that implements "--non-
interactive" around access to the keychain. The original description
was that this, therefore, breaks --non-interactive.
However, it turns out that operations that use --non-interactive plus
--username plus --password do succeed (never have to go to the
keychain for creds anyway). Small yay.
However however, this also means that such operations end up caching
the creds into svn.simple/ in the classic way.
It seems to me that this makes it a security bug. My reasoning:
someone on OS X, having read the documentation, expects credentials to
be stored in the very secure keychain. Through this bug, however,
they are stored in the much less secure svn.simple/. If this poor
user trusted our promise to do the safe thing (even verified it under
Tiger), they do not expect their creds to be stored in the file
system. This may seduce them into relaxing the file system
protections in some way, exposing their password.
My question for this list: does this constitute a security bug for
Subversion?
On the basis of the reasoning above, I marked my bug at Apple as a
security issue. They have just notified me that they don't consider
this a security issue. They didn't give me detailed reasoning on that
decision, but I do admit that the chain that leads to a breach
contains components other than those supplied by Apple, and even some
user configuration acts. I am considering bumping the Subversion bug
up to reflect the "security" concern.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Jack Repenning <jr...@collab.net>.
On Jan 3, 2008, at 12:01 AM, Branko Čibej wrote:
> That's what I meant, too. It's hardly a bug if the change in behaviour
> was intentional. But it's damn inconvenient.
Well, my argument was that it's a bug because (1) it violates the
documentation, and (2) it makes the AllowInteraction() call absolutely
bloody worthless.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Branko Čibej <br...@xbc.nu>.
Jack Repenning wrote:
> On Jan 2, 2008, at 6:29 PM, Garrett Reinard wrote:
>
>> By OS bug, I believe Jack's referring to the "--non-interactive
>> failure" bug itself, not the fact that the work around (i.e.
>> --username --password) causes it to store the credentials on disk...
>
> You are correct about my meaning.
That's what I meant, too. It's hardly a bug if the change in behaviour
was intentional. But it's damn inconvenient.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Jack Repenning <ja...@tigris.org>.
On Feb 14, 2008, at 4:41 PM, Toby Peterson wrote:
> On 02 Jan 2008, at 18.46.21, Jack Repenning wrote:
>
>> On Jan 2, 2008, at 6:29 PM, Garrett Reinard wrote:
>>
>>> On a slight tangent, is there any way I can view the status of the
>>> Apple defect? I've tried using the Apple Bug Reporter to find it,
>>> but it only allows me to see my originated issues, and there is no
>>> way for me to search as far as I can tell...
>>
>> You can, so they tell me, send an email to <de...@apple.com>,
>> referencing Bug ID# 5665212, or the earlier report (now closed),
>> Bug ID# 5658459.
>
> The current bug tracking the issue is #5607927. I'll do what I can
> to get it into a future SU, although I can't make any promises.
Thanks for your efforts, Toby! (And, thanks for the updated issue #).
-==-
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: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Toby Peterson <to...@apple.com>.
On 02 Jan 2008, at 18.46.21, Jack Repenning wrote:
> On Jan 2, 2008, at 6:29 PM, Garrett Reinard wrote:
>
>> On a slight tangent, is there any way I can view the status of the
>> Apple defect? I've tried using the Apple Bug Reporter to find it,
>> but it only allows me to see my originated issues, and there is no
>> way for me to search as far as I can tell...
>
> You can, so they tell me, send an email to <de...@apple.com>,
> referencing Bug ID# 5665212, or the earlier report (now closed), Bug
> ID# 5658459.
The current bug tracking the issue is #5607927. I'll do what I can to
get it into a future SU, although I can't make any promises.
- Toby
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Jack Repenning <jr...@collab.net>.
On Jan 2, 2008, at 6:29 PM, Garrett Reinard wrote:
> By OS bug, I believe Jack's referring to the "--non-interactive
> failure" bug itself, not the fact that the work around (i.e. --
> username --password) causes it to store the credentials on disk...
You are correct about my meaning.
> I'm surprised there hasn't been more exposure/discovery of this
> problem as of yet... The problem appeared for us while using maven
> since the SCM plugin uses the --non-interactive parameter for all
> SVN related calls while preparing and performing releases...
>
> Must be there aren't as many Maven/SVN/Leopard users building
> releases as I would have expected yet... :)
svnX as well, apparently (there is one thread about this in their mail
list).
> On a slight tangent, is there any way I can view the status of the
> Apple defect? I've tried using the Apple Bug Reporter to find it,
> but it only allows me to see my originated issues, and there is no
> way for me to search as far as I can tell...
You can, so they tell me, send an email to <de...@apple.com>,
referencing Bug ID# 5665212, or the earlier report (now closed), Bug
ID# 5658459.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Garrett Reinard <ga...@vanderbilt.edu>.
By OS bug, I believe Jack's referring to the "--non-interactive
failure" bug itself, not the fact that the work around (i.e. --
username --password) causes it to store the credentials on disk...
He's suggesting that it may be a bit too much work considering the
main reason its needed is to simply allow for this workaround which
should not be needed in the first place...
I'm surprised there hasn't been more exposure/discovery of this
problem as of yet... The problem appeared for us while using maven
since the SCM plugin uses the --non-interactive parameter for all SVN
related calls while preparing and performing releases...
Must be there aren't as many Maven/SVN/Leopard users building releases
as I would have expected yet... :)
Again, thanks much for looking into this problem Jack... I've been
actively following the thread in hopes of solution sometime in the
near future...
On a slight tangent, is there any way I can view the status of the
Apple defect? I've tried using the Apple Bug Reporter to find it, but
it only allows me to see my originated issues, and there is no way for
me to search as far as I can tell...
Thanks much...
-Garrett
On Jan 2, 2008, at 7:41 PM, Branko Čibej wrote:
> Jack Repenning wrote:
>> On Jan 2, 2008, at 4:02 PM, Branko Čibej wrote:
>>
>>> I think it is a security issue. If Subversion was compiled with
>>> keychain
>>> support, it should IMHO never try to store passwords outside the
>>> keychain, regardless --(non-)interactive. Same goes for password
>>> encryption on Windows, although AFAIK that never requires the user
>>> to
>>> interactively enter a password.
>>>
>>> I see two possible solutions here:
>>>
>>> * Update our whole authn-provider-chain infrastructure so that an
>>> authn plugin can tell the authn store code to stop walking the
>>> chain -- effectively causing it to not store authentication
>>> info.
>>
>> Interesting thought. This is similar to what auth-providers can do
>> within Apache and PAM, I believe: say "yes, it's OK" or "beats me,
>> ask
>> someone else" or "absolutely not, don't bother asking anyone else."
>>
>> In as much as we're only in this conversation due to an OS bug,
>> though, is it worth this much work?
>
> I'd hesitate to call it an OS bug. The behaviour on Leopard seems
> reasonable to me, it's just unfortunate that it's different than in
> older Mac OS versions. So that's a gratuitous change of behaviour, not
> quite the same as a bug.
>
> Maybe it wouldn't be such a bad thing to learn from more "experienced"
> authn provider architectures. :)
>
>>> * A more Mac-specific solution would cause the keychain provider
>>> to
>>> lie that it had stored the username and password, even if it in
>>> fact didn't. This option seems like a bit of a wart, though.
>>
>>
>> Pretty icky. And what if we ever bite the bullet and solve the
>> secure-cache problem on Unix somehow? We'd be setting a precedent.
>
> I absolutely agree. This would be marginally acceptable for a
> security-fix backport, but not for a real solution.
>
> -- Brane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Branko Čibej <br...@xbc.nu>.
Jack Repenning wrote:
> On Jan 2, 2008, at 4:02 PM, Branko Čibej wrote:
>
>> I think it is a security issue. If Subversion was compiled with keychain
>> support, it should IMHO never try to store passwords outside the
>> keychain, regardless --(non-)interactive. Same goes for password
>> encryption on Windows, although AFAIK that never requires the user to
>> interactively enter a password.
>>
>> I see two possible solutions here:
>>
>> * Update our whole authn-provider-chain infrastructure so that an
>> authn plugin can tell the authn store code to stop walking the
>> chain -- effectively causing it to not store authentication info.
>
> Interesting thought. This is similar to what auth-providers can do
> within Apache and PAM, I believe: say "yes, it's OK" or "beats me, ask
> someone else" or "absolutely not, don't bother asking anyone else."
>
> In as much as we're only in this conversation due to an OS bug,
> though, is it worth this much work?
I'd hesitate to call it an OS bug. The behaviour on Leopard seems
reasonable to me, it's just unfortunate that it's different than in
older Mac OS versions. So that's a gratuitous change of behaviour, not
quite the same as a bug.
Maybe it wouldn't be such a bad thing to learn from more "experienced"
authn provider architectures. :)
>> * A more Mac-specific solution would cause the keychain provider to
>> lie that it had stored the username and password, even if it in
>> fact didn't. This option seems like a bit of a wart, though.
>
>
> Pretty icky. And what if we ever bite the bullet and solve the
> secure-cache problem on Unix somehow? We'd be setting a precedent.
I absolutely agree. This would be marginally acceptable for a
security-fix backport, but not for a real solution.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Jack Repenning <jr...@collab.net>.
On Jan 2, 2008, at 4:02 PM, Branko Čibej wrote:
> I think it is a security issue. If Subversion was compiled with
> keychain
> support, it should IMHO never try to store passwords outside the
> keychain, regardless --(non-)interactive. Same goes for password
> encryption on Windows, although AFAIK that never requires the user to
> interactively enter a password.
>
> I see two possible solutions here:
>
> * Update our whole authn-provider-chain infrastructure so that an
> authn plugin can tell the authn store code to stop walking the
> chain -- effectively causing it to not store authentication info.
Interesting thought. This is similar to what auth-providers can do
within Apache and PAM, I believe: say "yes, it's OK" or "beats me, ask
someone else" or "absolutely not, don't bother asking anyone else."
In as much as we're only in this conversation due to an OS bug,
though, is it worth this much work?
> * A more Mac-specific solution would cause the keychain provider to
> lie that it had stored the username and password, even if it in
> fact didn't. This option seems like a bit of a wart, though.
Pretty icky. And what if we ever bite the bullet and solve the secure-
cache problem on Unix somehow? We'd be setting a precedent.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Question Re: Bug with "--non-interactive" (issue 3059)
Posted by Branko Čibej <br...@xbc.nu>.
Jack Repenning wrote:
> Recall: OS X Leopard just plain breaks the API that implements
> "--non-interactive" around access to the keychain. The original
> description was that this, therefore, breaks --non-interactive.
>
> However, it turns out that operations that use --non-interactive plus
> --username plus --password do succeed (never have to go to the
> keychain for creds anyway). Small yay.
>
> However however, this also means that such operations end up caching
> the creds into svn.simple/ in the classic way.
>
> It seems to me that this makes it a security bug. My reasoning:
> someone on OS X, having read the documentation, expects credentials to
> be stored in the very secure keychain. Through this bug, however,
> they are stored in the much less secure svn.simple/. If this poor
> user trusted our promise to do the safe thing (even verified it under
> Tiger), they do not expect their creds to be stored in the file
> system. This may seduce them into relaxing the file system
> protections in some way, exposing their password.
>
> My question for this list: does this constitute a security bug for
> Subversion?
>
> On the basis of the reasoning above, I marked my bug at Apple as a
> security issue. They have just notified me that they don't consider
> this a security issue. They didn't give me detailed reasoning on that
> decision, but I do admit that the chain that leads to a breach
> contains components other than those supplied by Apple, and even some
> user configuration acts. I am considering bumping the Subversion bug
> up to reflect the "security" concern.
I think it is a security issue. If Subversion was compiled with keychain
support, it should IMHO never try to store passwords outside the
keychain, regardless --(non-)interactive. Same goes for password
encryption on Windows, although AFAIK that never requires the user to
interactively enter a password.
I see two possible solutions here:
* Update our whole authn-provider-chain infrastructure so that an
authn plugin can tell the authn store code to stop walking the
chain -- effectively causing it to not store authentication info.
I think that would even make sense in the --non-interactive case.
o An alternative implementation of the above: each authn
provider could grow a flag that told the chain walker if it
was allowed to write or only to read auth info.
* A more Mac-specific solution would cause the keychain provider to
lie that it had stored the username and password, even if it in
fact didn't. This option seems like a bit of a wart, though.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org