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?
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?
> @@ -1173,19 +1182,25 @@ svn_ra_serf__get_uuid(svn_ra_session_t *
>
> props = apr_hash_make(pool);
>
> - SVN_ERR(svn_ra_serf__retrieve_props(props, session, session->conns[0],
> - session->repos_url_str,
> - SVN_INVALID_REVNUM, "0", uuid_props,
> - pool));
> - *uuid = svn_ra_serf__get_prop(props, session->repos_url_str,
> - SVN_DAV_PROP_NS_DAV, "repository-uuid");
> -
> - if (!*uuid)
> + if (!session->uuid)
I don't care if we have a convention about space-after-! or not. Maybe
it's nice to leave people a little room for, uh, self-expression :-).
-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 04:24:17 CEST