Fix case-sensitivity problems in extension content verification

Fix case-sensitivity problems in extension content verification

On case-insensitive filesystems, extensions can generate requests
(script src tags, XHR's, etc.) to their own resources using a
relative path with incorrect case and have those requests
work (see crbug.com/29941 for some history). However, for
extension content verification, we were looking up the expected
file content hashes using the relative path given in the request,
not the actual filename, which meant that any difference in case
would be treated as "no hashes for this file".

This patch switches to using case-insensitive lookups, but uses a
multimap so that case-sensitive filesystems should not experience
problems.

BUG=412693
TEST=Install the test extension at http://goo.gl/rOpGDu, and turn
on content verification to Enforce mode in about:flags. Without
this patch, the extension will get force disabled on
windows/mac. With the patch, this should be fixed.

Committed: https://crrev.com/49264e03b28ad3813382bef032839eddf893fa7e
Cr-Commit-Position: refs/heads/master@{#297032}

[asargent_no_longer_on_chrome, 2014-09-19 17:23:28]

asargent@chromium.org changed reviewers:
+ rockot@chromium.org

[asargent_no_longer_on_chrome, 2014-09-19 17:23:28]

I'm going to follow up with a separate patch with automated tests to keep this
patch small and possibly merge-able to a branch. (Also the tests require a bit
of refactoring throughout the code because they are testing that something
*didn't* happen)

[Ken Rockot(use gerrit already), 2014-09-19 18:03:05]

https://codereview.chromium.org/585583003/diff/1/extensions/browser/extension...
File extensions/browser/extension_protocols.cc (right):

https://codereview.chromium.org/585583003/diff/1/extensions/browser/extension...
extensions/browser/extension_protocols.cc:271:
directory_path_.AppendRelativePath(file_path_, &actual_relative_path);
It looks like this may not actually work on Windows. We can trace any potential
case translation back to file_util::MakeAbsolutePath, which in turn calls
_wfullpath. I've verified however that this function makes no effort to reflect
the case of the filename as it's known by the filesystem. It will preserve the
case of its input string.

[Ken Rockot(use gerrit already), 2014-09-19 19:43:31]

On 2014/09/19 18:03:05, Ken Rockot wrote:
>
https://codereview.chromium.org/585583003/diff/1/extensions/browser/extension...
> File extensions/browser/extension_protocols.cc (right):
> 
>
https://codereview.chromium.org/585583003/diff/1/extensions/browser/extension...
> extensions/browser/extension_protocols.cc:271:
> directory_path_.AppendRelativePath(file_path_, &actual_relative_path);
> It looks like this may not actually work on Windows. We can trace any
potential
> case translation back to file_util::MakeAbsolutePath, which in turn calls
> _wfullpath. I've verified however that this function makes no effort to
reflect
> the case of the filename as it's known by the filesystem. It will preserve the
> case of its input string.

It looks like the right Windows API to get the a case-correct filename is
GetLongPathName. I've tested locally and I get good results. This is used in
file_util but not to implement anything that would help here.

Alternatively you could go with the other approach we discussed and just flatten
the case of all filenames and JSON entries during lookup. This implies a policy
of no case-insensitive dupes being allowed in CRXes (i.e. no foo/Foo.js and
foo/FOO.js in the same CRX), but that should be implied anyway as this would
always break on Windows.

[asargent_no_longer_on_chrome, 2014-09-26 18:31:46]

Ok, ready for re-review. Switched from trying to determine actual path to just
using multimap based on lower-cased path. Life is imperfect.

[Ken Rockot(use gerrit already), 2014-09-26 18:48:13]

lgtm

https://codereview.chromium.org/585583003/diff/40001/extensions/browser/verif...
File extensions/browser/verified_contents.cc (right):

https://codereview.chromium.org/585583003/diff/40001/extensions/browser/verif...
extensions/browser/verified_contents.cc:220: const std::string*
VerifiedContents::GetTreeHashRoot(
Do you really want to keep this around for some reason?

[asargent_no_longer_on_chrome, 2014-09-26 18:51:55]

https://codereview.chromium.org/585583003/diff/40001/extensions/browser/verif...
File extensions/browser/verified_contents.cc (right):

https://codereview.chromium.org/585583003/diff/40001/extensions/browser/verif...
extensions/browser/verified_contents.cc:220: const std::string*
VerifiedContents::GetTreeHashRoot(
On 2014/09/26 18:48:13, Ken Rockot (slow this week) wrote:
> Do you really want to keep this around for some reason?

No.

[asargent_no_longer_on_chrome, 2014-09-26 18:52:00]

The CQ bit was checked by asargent@chromium.org

[commit-bot: I haz the power, 2014-09-26 18:52:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/585583003/60001

[commit-bot: I haz the power, 2014-09-26 21:15:37]

Committed patchset #4 (id:60001) as 5d87331afd6b0e4484e6c0b6815a326b7612af2f

[commit-bot: I haz the power, 2014-09-26 21:16:19]

Patchset 4 (id:??) landed as
https://crrev.com/49264e03b28ad3813382bef032839eddf893fa7e
Cr-Commit-Position: refs/heads/master@{#297032}