On 9/19/06, Philip Martin <philip@codematters.co.uk> wrote:
> "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
>
> > Ok, one catch... ra_svn_sasl.h depends on ra_svn.h for one constant
> > (SVN_RA_SVN__READBUF_SIZE). Now there's no way in hell that
> > SVN_RA_SVN__READBUF_SIZE should live in ra_svn_sasl.h, and similarly,
> > I'm not all that thrilled about ra_svn.h living in private/, since
> > it's really not used outside of libsvn_ra_svn. Any thoughts on a
> > proper home for that constant?
>
> Ahh, the 4096 I queried in the original patch :) How about getting rid
> of SVN_RA_SVN__DEFAULT_SECPROPS and using
>
> void svn_ra_svn__default_secprops(sasl_security_properties_t *secprops);
Good idea. Unfortunately, this isn't the only instance of svnserve
sticking its nose into libsvn_ra_svn's business. In
svnserve/sasl_auth.c I accidentally used conn->sock directly, but
svn_ra_svn_conn_t is supposed to be opaque to the server. This worked
precisely because ra_svn_sasl.h includes ra_svn.h, and that's where
svn_ra_svn_conn_t is defined.
Anyway, the attached patch attempts to fix both issues.
[[[
Isolate svnserve from internal libsvn_ra_svn implementation details.
* subversion/include/private/svn_sasl.h: New file.
* subversion/libsvn_ra_svn/ra_svn_sasl.h: Deleted.
* subversion/libsvn_ra_svn/sasl_auth.c:
Include svn_sasl.h instead of ra_svn_sasl.h.
(svn_ra_svn__default_secprops): New function.
(new_sasl_ctx): Use svn_ra_svn__default_secprops instead of
initializing secprops directly.
(svn_ra_svn__get_addresses): Take an svn_ra_svn_conn_t parameter
instead of an apr_socket_t. Check that conn->sock is non-NULL before
using it.
(svn_ra_svn__do_auth): Adjust for the change to
svn_ra_svn__get_addresses.
* subversion/svnserve/sasl_auth.c:
Include svn_sasl.h instead of ra_svn_sasl.h.
(get_local_hostname): Deleted.
(sasl_auth_request): Call svn_ra_svn__get_addresses unconditionally.
Use apr_gethostname instead of get_local_hostname. Call
svn_ra_svn__default_secprops.
]]]
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 19 23:10:27 2006