Replace RELEASE_ASSERT_WITH_SECURITY_IMPLICATION with SECURITY_CHECK.

third_party/WebKit/Source/wtf/Assertions.h

Index: third_party/WebKit/Source/wtf/Assertions.h
diff --git a/third_party/WebKit/Source/wtf/Assertions.h b/third_party/WebKit/Source/wtf/Assertions.h
index 3962562ffd6f36121f90cd2ff3a97a00b36e33f2..a6917d62b85b8b8074dd6ce5b85d61a7c405da8a 100644
--- a/third_party/WebKit/Source/wtf/Assertions.h
+++ b/third_party/WebKit/Source/wtf/Assertions.h
@@ -215,10 +215,9 @@ private:
 
 #endif
 
-// ASSERT_WITH_SECURITY_IMPLICATION / RELEASE_ASSERT_WITH_SECURITY_IMPLICATION
-// They are deprecated.  ASSERT_WITH_SECURITY_IMPLICATION should be replaced
-// with SECURITY_DCHECK, and RELEASE_ASSERT_WITH_SECURITY_IMPLICATION should be
-// replaced with RELEASE_ASSERT.
+// ASSERT_WITH_SECURITY_IMPLICATION
+// It is deprecated.  ASSERT_WITH_SECURITY_IMPLICATION should be replaced
+// with SECURITY_DCHECK.

[haraken, 2016/03/31 00:54:58]

SECURITY_DCHECK => SECURITY_CHECK ?

[dcheng, 2016/03/31 01:09:40]

I'm not sure how expensive this will be, all the toDerivedClass macros use
ASSERT_WITH_SECURITY_IMPLICATIONS right now.

[tkent, 2016/03/31 05:26:12]

SECURITY_DCHECK is correct here.

ASSERT -> DCHECK
RELEASE_ASSERT -> CHECK
ASSERT_WITH_S_I -> SECURITY_DCHECK
RELEASE_ASSERT_WITH_S_SI -> SECURITY_CHECK
We'll replace all ASSERT_WITH_S_Is with SECURITY_DCHECKs.

 #ifdef ADDRESS_SANITIZER
 
 #define ASSERT_WITH_SECURITY_IMPLICATION(assertion) \
@@ -227,13 +226,8 @@ private:
             CRASH()) : \
         (void)0)
 
-#define RELEASE_ASSERT_WITH_SECURITY_IMPLICATION(assertion) ASSERT_WITH_SECURITY_IMPLICATION(assertion)
-
 #else
-
 #define ASSERT_WITH_SECURITY_IMPLICATION(assertion) ASSERT(assertion)
-#define RELEASE_ASSERT_WITH_SECURITY_IMPLICATION(assertion) RELEASE_ASSERT(assertion)
-
 #endif
 
 // Users must test "#if ENABLE(SECURITY_ASSERT)", which helps ensure
@@ -244,16 +238,20 @@ private:
 #define ENABLE_SECURITY_ASSERT 0
 #endif
 
-// SECURITY_DCHECK
+// SECURITY_DCHECK and SECURITY_CHECK
 // Use in places where failure of the assertion indicates a possible security
 // vulnerability. Classes of these vulnerabilities include bad casts, out of
 // bounds accesses, use-after-frees, etc. Please be sure to file bugs for these
 // failures using the security template:
-//    http://code.google.com/p/chromium/issues/entry?template=Security%20Bug
+//    https://bugs.chromium.org/p/chromium/issues/entry?template=Security%20Bug
 #if ENABLE_SECURITY_ASSERT
 #define SECURITY_DCHECK(condition) LOG_IF(FATAL, !(condition)) << "Security check failed: " #condition ". "
+// TODO(tkent): Should we make SECURITY_CHECK different from SECURITY_DCHECK?
+// A SECURITY_CHECK failure is actually not vulnerable.

[haraken, 2016/03/31 00:54:58]

Maybe failures that are not vulnerable should use CHECK?

BTW, I don't think Blink has distinguished
RELEASE_ASSERT_WITH_SECURITY_IMPLICATION and RELEASE_ASSERT very well. Is it
worth having the difference?

[dcheng, 2016/03/31 01:09:40]

(I think) the security team uses this as a signal of how critical a reported
issue might be.

[inferno, 2016/03/31 04:04:18]

Yes correct, otherwise we won't be able to distinguish these. and hard to
prioritize stuff everything shows as plain checks.

[Oliver Chang, 2016/03/31 06:13:39]

Why do we need to distinguish between CHECK and SECURITY_CHECK here? As tkent
mentioned, SECURITY_CHECK failures don't indicate any exploitable vulnerability,
so there's no reason to prioritise SECURITY_CHECK over CHECK or make this
distinction? The one advantage I see is that it could deter someone from
unknowingly removing a security sensitive CHECK (or turning it into a DCHECK).

Either way, as this is right now it can actually cause confusion for us during
fuzzing since we just see the "Security check failed:" message for both
SECURITY_CHECK and SECURITY_DCHECK, but only the latter represents a real
vulnerability.

+#define SECURITY_CHECK(condition) SECURITY_DCHECK(condition)
 #else
 #define SECURITY_DCHECK(condition) ((void)0)
+#define SECURITY_CHECK(condition) CHECK(condition)
 #endif
 
 // WTF_LOG