On 11 December 2015 at 04:12, Branko Čibej <br...@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
