Closed
Bug 999477
Opened 10 years ago
Closed 10 years ago
Fix FindInReadable calls in ApplicationReputation
Categories
(Core :: DOM: Security, defect)
Tracking
()
RESOLVED
FIXED
mozilla31
People
(Reporter: mmc, Assigned: mmc)
References
(Blocks 1 open bug)
Details
(Whiteboard: [qa-])
Attachments
(1 file)
1.87 KB,
patch
|
gcp
:
review+
lsblakk
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
In practice, binaries appear in only one list so FindInReadable on the table names is equivalent to equality checking. However, it's still a bug.
Assignee | ||
Comment 1•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mmc
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•10 years ago
|
||
Comment on attachment 8410300 [details] [diff] [review] Fix FindInReadable calls in ApplicationReputation ( Review of attachment 8410300 [details] [diff] [review]: ----------------------------------------------------------------- Previous comment should have been: URLs typically appear only on one list.
Attachment #8410300 -
Flags: review?(gpascutto)
Comment 3•10 years ago
|
||
Comment on attachment 8410300 [details] [diff] [review] Fix FindInReadable calls in ApplicationReputation ( Review of attachment 8410300 [details] [diff] [review]: ----------------------------------------------------------------- This may be testable? Construct update that inserts entry in both block and allow DB. Check for expected behavior on a double hit. That seems like it might be useful outside this bug as well?
Attachment #8410300 -
Flags: review?(gpascutto) → review+
Assignee | ||
Updated•10 years ago
|
Blocks: downloadprotection
Assignee | ||
Comment 4•10 years ago
|
||
(In reply to Gian-Carlo Pascutto [:gcp] from comment #3) > Comment on attachment 8410300 [details] [diff] [review] > Fix FindInReadable calls in ApplicationReputation ( > > Review of attachment 8410300 [details] [diff] [review]: > ----------------------------------------------------------------- > > This may be testable? Construct update that inserts entry in both block and > allow DB. Check for expected behavior on a double hit. That seems like it > might be useful outside this bug as well? Good idea -- it'll take a little time to construct due to the binary nature of the test data and I'm gone later this week, so I filed bug 662819 for this.
Assignee | ||
Comment 5•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/ec50db58f17b
https://hg.mozilla.org/mozilla-central/rev/ec50db58f17b
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8410300 [details] [diff] [review] Fix FindInReadable calls in ApplicationReputation ( [Approval Request Comment] Bug caused by (feature/regressing bug #): initial implementation User impact if declined: Not much risk since the string comparison is most likely to be an equality check, but this is a bug (see comment 1) Testing completed (on m-c, etc.): m-c Risk to taking this patch (and alternatives if risky): very low risk String or IDL/UUID changes made by this patch: none
Attachment #8410300 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
Attachment #8410300 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 8•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/f154d04c6c08
status-firefox30:
--- → fixed
status-firefox31:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•