|
|
Created:
3 years, 9 months ago by vakh (use Gerrit instead) Modified:
3 years, 9 months ago CC:
chromium-reviews, vakh+watch_chromium.org, woz Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionPVer4: Filter out the safe crxs before calling OnCheckExtensionsResult
The argument for OnCheckExtensionsResult should only contain the bad
extensions, but PVer4 code was including all CRXs (blacklisted or not).
BUG=700145
Review-Url: https://codereview.chromium.org/2742913002
Cr-Commit-Position: refs/heads/master@{#456212}
Committed: https://chromium.googlesource.com/chromium/src/+/ec975c1d7990d87c1be9c03e0d94e38e20a7389b
Patch Set 1 #
Total comments: 4
Patch Set 2 : Rebase #Patch Set 3 : Fix date format #
Total comments: 2
Messages
Total messages: 26 (15 generated)
The CQ bit was checked by vakh@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
vakh@chromium.org changed reviewers: + nparker@chromium.org, shess@chromium.org
Rebase
The CQ bit was checked by vakh@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... File components/safe_browsing_db/v4_local_database_manager.cc (right): https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... components/safe_browsing_db/v4_local_database_manager.cc:523: DCHECK(it != full_hashes.end()); If the server returns a full hash which we didn't request, would this crash? Or have we filtered those out already? https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... File components/safe_browsing_db/v4_local_database_manager_unittest.cc (right): https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... components/safe_browsing_db/v4_local_database_manager_unittest.cc:892: // TODO(vakh): By 03/15: Add tests for March 2015?
Rebase
The CQ bit was checked by vakh@chromium.org to run a CQ dry run
Patchset #2 (id:20001) has been deleted
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Fix date format
The CQ bit was checked by vakh@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Thanks. PTAL. https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... File components/safe_browsing_db/v4_local_database_manager.cc (right): https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... components/safe_browsing_db/v4_local_database_manager.cc:523: DCHECK(it != full_hashes.end()); On 2017/03/10 01:36:23, Nathan Parker wrote: > If the server returns a full hash which we didn't request, would this crash? Or > have we filtered those out already? Yes, those have been filtered out already in V4GetHashProtocolManager::MergeResults() https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... File components/safe_browsing_db/v4_local_database_manager_unittest.cc (right): https://codereview.chromium.org/2742913002/diff/1/components/safe_browsing_db... components/safe_browsing_db/v4_local_database_manager_unittest.cc:892: // TODO(vakh): By 03/15: Add tests for On 2017/03/10 01:36:23, Nathan Parker wrote: > March 2015? March 15, 2017 but likely sooner.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm
The CQ bit was checked by vakh@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 60001, "attempt_start_ts": 1489187392187870, "parent_rev": "aa394d93072283f792da83ae88412562169539e3", "commit_rev": "ec975c1d7990d87c1be9c03e0d94e38e20a7389b"}
Message was sent while issue was closed.
Description was changed from ========== PVer4: Filter out the safe crxs before calling OnCheckExtensionsResult The argument for OnCheckExtensionsResult should only contain the bad extensions, but PVer4 code was including all CRXs (blacklisted or not). BUG=700145 ========== to ========== PVer4: Filter out the safe crxs before calling OnCheckExtensionsResult The argument for OnCheckExtensionsResult should only contain the bad extensions, but PVer4 code was including all CRXs (blacklisted or not). BUG=700145 Review-Url: https://codereview.chromium.org/2742913002 Cr-Commit-Position: refs/heads/master@{#456212} Committed: https://chromium.googlesource.com/chromium/src/+/ec975c1d7990d87c1be9c03e0d94... ==========
Message was sent while issue was closed.
Committed patchset #3 (id:60001) as https://chromium.googlesource.com/chromium/src/+/ec975c1d7990d87c1be9c03e0d94...
Message was sent while issue was closed.
LGTM. https://codereview.chromium.org/2742913002/diff/60001/components/safe_browsin... File components/safe_browsing_db/v4_local_database_manager.h (right): https://codereview.chromium.org/2742913002/diff/60001/components/safe_browsin... components/safe_browsing_db/v4_local_database_manager.h:157: std::vector<SBThreatType> full_hash_threat_types; This feels clunky, like it should be a vector<pair<FullHash,SBThreatType>> in the first place (or some other vector-of-combo). But that also feels clunky. So I guess I'll just encourage thought on whether this has a more-elegant alternative.
Message was sent while issue was closed.
https://codereview.chromium.org/2742913002/diff/60001/components/safe_browsin... File components/safe_browsing_db/v4_local_database_manager.h (right): https://codereview.chromium.org/2742913002/diff/60001/components/safe_browsin... components/safe_browsing_db/v4_local_database_manager.h:157: std::vector<SBThreatType> full_hash_threat_types; On 2017/03/13 21:43:06, Scott Hess wrote: > This feels clunky, like it should be a vector<pair<FullHash,SBThreatType>> in > the first place (or some other vector-of-combo). But that also feels clunky. > So I guess I'll just encourage thought on whether this has a more-elegant > alternative. Yes, I had the exact same argument in my head and chose to go with a this because: 1. that would have been a bigger patch. 2. initializing full_hashes would have become less concise. |