Lieven Govaerts <svnlgo_at_mobsol.be> writes:
> Karl Fogel wrote:
>> lgo_at_tigris.org writes:
>>> --- trunk/subversion/libsvn_ra_serf/serf.c (r31549)
>>> +++ trunk/subversion/libsvn_ra_serf/serf.c (r31550)
>>> @@ -1163,6 +1163,15 @@ svn_ra_serf__get_repos_root(svn_ra_sessi
>>> return SVN_NO_ERROR;
>>> }
>>> +/* TODO: to fetch the uuid from the repository, we need:
>>> + 1. a path that exists in HEAD
>>> + 2. a path that's readable
>>> +
>>> + get_uuid handles the case where a path doesn't exist in HEAD and also the
>>> + case where the root of the repository is not readable.
>>> + However, it does not handle the case where we're fetching path not existing
>>> + in HEAD of a repository with unreadable root directory.
>>> + */
>>> static svn_error_t *
>>> svn_ra_serf__get_uuid(svn_ra_session_t *ra_session,
>>> const char **uuid,
>>
>> This doc string raises the question of whether a client *should* be able
>> to get the UUID of a repository if the client cannot provide a readable
>> path for that repository. I mean, why should the server confirm that a
>> repository even *exists* at (or above) a given URL, if the root of that
>> repository is not readable and the client does not know a readable path
>> inside it?
>
> The doc string is supposed to refer to the case where the user knows a
> valid path in an older revision, by providing an url and a peg
> rev. Seeing you misread it means I have to improve the doc string.
Specifically: where the doc string says "get_uuid", it should probably
write out the full name of the function, or say "this function" or
something, so there's no ambiguity. And, it's not clear what the doc
string means by the verb "handles": does that mean it returns an error,
for example, and if so which one?
>> If there is no other way to determine that a repository is there, giving
>> the UUID is an information leak, because it confirms the existence of
>> the repository. But if there are other ways to determine that a
>> repository is there (such as by getting read errors), then the question
>> is, are those other ways also information leaks, or do we just decide
>> that this is okay to confirm?
>
> Good question.
> The get uuid call to the server will return 403 Forbidden on queries
> to non-existant paths. That doesn't mean we don't spill the existence
> of a repository in another way, but at least get_uuid doesn't seem to.
Ok. But 403 Forbidden isn't an svn_error_t code :-), so the question
is, how does that get represented back to caller?
> I do think we should try to avoid confirming the existence of a
> repository if at all possible, but I have no idea how far of we are
> from that principle.
Neither do I, but at least this won't bring us any farther.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-02 15:15:47 CEST