Re: apr_hash_overlay returns hash with duplicate keys

On 11 December 2015 at 04:12, Branko Čibej <brane_at_apache.org> wrote:
> On 10.12.2015 18:23, Ivan Zhakov wrote:
>> I think returning
>> hash with non-standard hash function from public API is a bug (and API
>> regression). Other API users may get to the same situation. So proper
>> fix would be revert these optimizations from public API imo.
>
> I really can't agree with this. A user of the APR public API cannot
> assume which hash function is used by any instance of apr_hash_t that
> she did not create herself. In other words, no-one should be calling
> apr_hash_overlay() (with APR <= 1.4.5) unless they know that the hashes
> use the same hash function.
>
> The only "bug" here is a design bug in older versions of
> apr_hash_overlay() (and apr_hash_merge()), and even that is debatable.
>
This sounds good in theory, but in reality even Subversion developers
encounters this really weird behavior.

Btw is it possible to backport apr_hash_overlay()/apr_hash_merge() fix
to APR 1.3.x?

> As far as the Subversion code is concerned, we should, IMO, be using
> svn_hash__make() everywhere, since we have it.
>
We cannot use svn_hash__make() everywhere at least it doesn't immune
to hash-collision attacks like CVE-2012-0840 [1]

[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0840

-- 
Ivan Zhakov