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

Travis P.: my apologies for not replying to your message personally,
I've been busy all weekend. The gist of what is said below would simply
be regurgitated if I were also to reply to your message. :)

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.

> >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).

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.

> "Windy" indeed. :-)

Your argument appeared to be "because others claim to know what they're
doing and get it wrong, so should we". :)

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.

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.

Cheers,

David.

-- 
(This signature left intentionally blank)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org