On Mon 2003-01-13 at 15:25:23 -0800, email@example.com wrote:
> > > What is the argument for not caching the username?
> Granted, they are potentially sensitive in some cases. Usually because
> they allow an attacker a place to start when they are trying to guess
> username/password combinations. But in real-life, is this really an issue
> for an SCM system?
Why decide for others if there is no compelling reason / advantage to
do so? (If there is one, what's it?)
> The chances that you would need to protect your username from
> somebody who shares the system with you is slim (there are better
> ways to get valid usernames). The chances that you would need to
> protect your username from somebody that you give your wc to is even
> slimmer (They most likely already know your username).
Another case: A WC that is "used" by several people, e.g. several
people doing releases and using a central WC for that (size too big
for anyone's workstation's disks). Of course there are work-arounds.
That doesn't matter. The fact is: there are use cases where people
reasonably don't like any auth-data to be stored.
> So, while usernames are sensitive, I don't agree that they are sensitive
> in the context of an SCM system, especially since every other SCM I have
> ever used stores the username inside of the checked out code.
CVS does not if you use it with :ext: and SSH (you can, but you don't
have to). I like the fact very much that a WC checked out this way can
be copied by a co-worker and it works without change for him.
> > Also, suppose I want to treat a working copy as read-only, then I
> > don't want 'svn st -u' to write auth data.
> 'svn st -u' shouldn't be adding auth data to the wc if it wasn't
> there to begin with. IMHO, only checkout and update should be
> modifying the cached auth information.
Why? The only reason I can imagine is because 'svn stat' doesn't
change the WC, only checkout and update do.
But... that is about versioned data. Authentication data is not part
of the repository, it is not part of the versioned data. It *may* be
stored within the WC, but that's all. It's simply a cached data.
In other words, it is *not* inconsistent for a 'repository, read-only'
operation to write to some cache which happens to be in the WC. That's
not only true for authentication data, but for any kind of caching
that is able to speed up network operations. And 'svn st -u' is such
Received on Tue Jan 14 01:55:41 2003
- application/pgp-signature attachment: stored