[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Question Re: Bug with "--non-interactive" (issue 3059)

From: Garrett Reinard <garrett.reinard_at_vanderbilt.edu>
Date: Wed, 2 Jan 2008 20:29:10 -0600

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_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-04 04:57:00 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.