Don't allow negative date components in ParseCertificateDate(), or ones starting with a plus.

net/cert/x509_cert_types_unittest.cc

Index: net/cert/x509_cert_types_unittest.cc
diff --git a/net/cert/x509_cert_types_unittest.cc b/net/cert/x509_cert_types_unittest.cc
index f3bf8fccb11cce3e02cee9c5abf32497c5a40fe3..529fa3c95f5f0c506b8bbe961d4f806952f7746a 100644
--- a/net/cert/x509_cert_types_unittest.cc
+++ b/net/cert/x509_cert_types_unittest.cc
@@ -148,50 +148,37 @@ const struct CertDateTestData {
   bool is_valid;
   base::Time::Exploded expected_result;
 } kCertDateTimeData[] = {
-  { CERT_DATE_FORMAT_UTC_TIME,
-    "120101000000Z",
-    true,
-    { 2012, 1, 0, 1, 0, 0, 0 } },
-  { CERT_DATE_FORMAT_GENERALIZED_TIME,
-    "20120101000000Z",
-    true,
-    { 2012, 1, 0, 1, 0, 0, 0 } },
-  { CERT_DATE_FORMAT_UTC_TIME,
-    "490101000000Z",
-    true,
-    { 2049, 1, 0, 1, 0, 0, 0 } },
-  { CERT_DATE_FORMAT_UTC_TIME,
-    "500101000000Z",
-    true,
-    { 1950, 1, 0, 1, 0, 0, 0 } },
-  { CERT_DATE_FORMAT_GENERALIZED_TIME,
-    "19500101000000Z",
-    true,
-    { 1950, 1, 0, 1, 0, 0, 0 } },
-  { CERT_DATE_FORMAT_UTC_TIME,
-    "AB0101000000Z",
-    false,
-    { 0 } },
-  { CERT_DATE_FORMAT_GENERALIZED_TIME,
-    "19AB0101000000Z",
-    false,
-    { 0 } },
-  { CERT_DATE_FORMAT_UTC_TIME,
-    "",
-    false,
-    { 0 } },
-  { CERT_DATE_FORMAT_UTC_TIME,
-    "A",
-    false,
-    { 0 } },
- { CERT_DATE_FORMAT_GENERALIZED_TIME,
-    "20121301000000Z",
-    false,
-    { 0 } },
- { CERT_DATE_FORMAT_GENERALIZED_TIME,
-    "20120101123000Z",
-    true,
-    { 2012, 1, 0, 1, 12, 30, 0 } },
+    {CERT_DATE_FORMAT_UTC_TIME,
+     "120101000000Z",
+     true,
+     {2012, 1, 0, 1, 0, 0, 0}},
+    {CERT_DATE_FORMAT_UTC_TIME, "-90101000000Z", false, {0}},

[eroman, 2016/03/23 19:39:10]

Stupid reformatting! The only changes are addition of these two tests (-9 and
+9) as the year. Both were recognized, where -9 was interpreted as 2000-9  O_o

[mmenke, 2016/03/23 19:58:36]

Should we have tests where some other field is weird?

"09+101000000Z", "0901-1000000Z", and/or "090101 00000Z"?  Last would have
failed before, too, but I'm paranoid.

[eroman, 2016/03/23 20:03:09]

   -90101000000Z
Yes, although because the parsing expects each component to be 2 bytes long, an
even stronger test is to change like "01" --> "+1" so it doesn't violate the
size constraint (otherwise would have failed in pervious version too).

Will add such tests shortly and ping back...

[mmenke, 2016/03/23 20:05:52]

Isn't that what I did?  I changed each subsequent even position byte, without
modifying the size.

[eroman, 2016/03/23 20:33:43]

Ah sg then!

Done.

+    {CERT_DATE_FORMAT_UTC_TIME, "+90101000000Z", false, {0}},
+    {CERT_DATE_FORMAT_GENERALIZED_TIME,
+     "20120101000000Z",
+     true,
+     {2012, 1, 0, 1, 0, 0, 0}},
+    {CERT_DATE_FORMAT_UTC_TIME,
+     "490101000000Z",
+     true,
+     {2049, 1, 0, 1, 0, 0, 0}},
+    {CERT_DATE_FORMAT_UTC_TIME,
+     "500101000000Z",
+     true,
+     {1950, 1, 0, 1, 0, 0, 0}},
+    {CERT_DATE_FORMAT_GENERALIZED_TIME,
+     "19500101000000Z",
+     true,
+     {1950, 1, 0, 1, 0, 0, 0}},
+    {CERT_DATE_FORMAT_UTC_TIME, "AB0101000000Z", false, {0}},
+    {CERT_DATE_FORMAT_GENERALIZED_TIME, "19AB0101000000Z", false, {0}},
+    {CERT_DATE_FORMAT_UTC_TIME, "", false, {0}},
+    {CERT_DATE_FORMAT_UTC_TIME, "A", false, {0}},
+    {CERT_DATE_FORMAT_GENERALIZED_TIME, "20121301000000Z", false, {0}},
+    {CERT_DATE_FORMAT_GENERALIZED_TIME,
+     "20120101123000Z",
+     true,
+     {2012, 1, 0, 1, 12, 30, 0}},
 };
 
 // GTest pretty printer.