Request for advice - subversion FTBFS in precise

[Scott Kitterman]

On Friday, April 13, 2012 12:01:45 AM Max Bowsher wrote:
> Hi all,
> 
> Subversion currently FTBFS in precise.
> 
> The reason is because apr 1.4.6 changed its hashtable implementation to
> incorporate randomness into the hash function. This was to prevent
> possible DoS attacks which are based on feeding a server data which it
> will put into a hash, which will cause the hash function to perform
> pathologically badly.
> 
> Unfortunately, it's easy to see how this can completely break a
> testsuite's comparisons against hardcoded expected values - hence the FTBFS.
> 
> More interestingly, this change also creates at least one behaviour in
> Subversion which some might deem a bug: the output of 'svnadmin dump' is
> no longer identical if performed multiple times on an unchanging
> repository. Bad news for anyone trying to use it to verify intactness of
> a repository mirror, for example.
> 
> 
> I have a workaround, but it's not exactly pretty.
> 
> It is to use the C preprocessor to modify all the calls which create
> hashtables to override the hash function back to the one used in APR
> 1.4.5 and earlier, by placing a #define in a key header file, and then
> to use sed in the debian/rules install target to remove the #define from
> the installed copy of the header file.
> 
> Like I said, not exactly pretty. But potentially better than shipping
> precise with a subversion package we can't rebuild, or liberally
> disabling large tracts of its testsuite.
> 
> Here's the diff:
> 
> 
> === modified file 'debian/rules'
> --- debian/rules        2011-12-17 15:01:54 +0000
> +++ debian/rules        2012-04-12 22:38:11 +0000
> @@ -330,6 +330,7 @@
>         $(MAKE_B) local-install install-tools \
>                 DESTDIR=$(CURDIR)/debian/tmp toolsdir=/usr/bin
>         sed -i 's:/usr/lib/\([^/]*/\)?lib\([^ ]*\).la:-l\1:g'
> debian/tmp/usr/lib/*/*.la +       sed -i '/^#define apr_hash_make/d'
> debian/tmp/usr/include/subversion-1/svn_types.h
> 
>         $(call allpydbg, \
>           $(MAKE_B) install-swig-py DESTDIR=$(CURDIR)/debian/tmp \
> 
> === modified file 'subversion/include/svn_types.h'
> --- subversion/include/svn_types.h      2009-11-17 02:16:23 +0000
> +++ subversion/include/svn_types.h      2012-04-12 22:38:11 +0000
> @@ -32,6 +32,7 @@
>  #include <apr_tables.h>  /* for apr_array_push() */
>  #include <apr_time.h>    /* for apr_time_t */
>  #include <apr_strings.h> /* for apr_atoi64() */
> +#define apr_hash_make(pool) apr_hash_make_custom((pool),
> apr_hashfunc_default)
> 
>  #ifdef __cplusplus
>  extern "C" {
> 
> 
> 
> I invite your thoughts.
> 
> Additional datapoint: There's already a 1.6.18 new upstream version out,
> with some fairly important repository corruption fixes. Assuming we can
> overcome the FTBFS, and subject to the release team being happy with it,
> it could well be a good idea to get it into precise-release. If we
> don't, the new upstream version, or a substantial part of its diff, is
> almost certain to be a SRU immediately after release.

I think it would make sense to upload 1.6.18 to oneiric-proposed so it's easy 
to remove if it doesn't test out well.  svn releases are not consistently 
regression free.  I don't think reverting an upstream security improvement to 
make a test suite work is a good idea.  What do svn and apr devs say about 
this?

Scott K