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

Re: Feature Request: clients shouldn't store auth-creds

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-01-10 00:40:52 CET

David Wilson wrote:

>On Sun, Jan 09, 2005 at 09:15:50PM +0100, Branko ??ibej wrote:
>
>
>
>>>An agent program also introduces the following (especially on Windows):
>>>
>>>
>
>
>
>>*sigh* ... I'm so tired of "experts" who keep guessing about what
>>Windows can or can't do.
>>
>>
>Can you point to the part where I claimed to be an "expert", or said
>Windows can't lock memory? I merely hinted that it is less trivial to
>keep a hold of said memory on Windows, which as far as I know is true.
>
>
I could say, "less trivial than where?" but I'll just note that it's
easy to do and therefore we can ignore this issue.

>>>There are plenty of security books out there (eg. Writing Secure Code)
>>>that would tell you it is a very bad thing. In my opinion, the current
>>>practice of the Subversion folk is the ideal one - leave the
>>>complicated security (certificates, public keys, encryption, etc) to
>>>other people *who know what they are doing*.
>>>
>>>
>>The trouble is, of course, that they usually don't.
>>
>>
>
>Well, I'd rather leave the blame on their doorstep for claiming to be
>security products than bring it to Subversion's, it has already had
>enough security problems in its short life than enough ("zero" or "as
>low as humanly possible" being enough).
>
>
We can claim it's not our fault, but that isn't enough to change
people's perceptions.

>Like any project, it is understaffed enough for the problems at hand
>(ie. writing a version control system), without trying to take on the
>mammoth task of implementing a complex yet secure authentication /
>encryption / whatever system in C.
>
>
This thread is not about implementing authentication or encryption
mechanisms, it's about temporarily cacheing credentials so that a)
they're not stored on disk, and b) users don't have to provide them
(type passwords) all the time. There's a world of difference between the
two.

>>"Windy" indeed. :-)
>>
>>
>
>Your argument appeared to be "because others claim to know what they're
>doing and get it wrong, so should we". :)
>
>
Ah... that would be the case only if you were right, something I don't
agree with. :-)

>The intent of my first post was to shoot down a clearly bad design, and
>to praise the Subversion folk on not attempting anything like this.
>
>
But the whole point is that there /was/ no design to shoot down. I said
"agent", and you replied, "ssh-agent is bad, therefore any agent is
bad". I never claimed that an svn-agent should be a clone of ssh-agent.

For example, "sudo" will temporarily cache the fact that you've
confirmed your identity in a particular login session, and whilst it
doesn't use a separate process for that, I'd still classify it as having
an "agent". Interestingly enough, what "sudo" does is quite similar to
storing session tokens.

>I don't have any 'better' solution, and I doubt few, if any on this list
>do. What I do know, is that it takes many years and bad experiences
>before someone can come up with such a solution. That is the route I
>recommended we don't take.
>
>
Others have walked that path several times, and there's nothing wrong
with learning from their experience.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 10 00:40:40 2005

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.