SF bug 847019 datetime.datetime initialization needs more strict checking
It's possible to create insane datetime objects by using the constructor
"backdoor" inserted for fast unpickling. Doing extensive range checking
would eliminate the backdoor's purpose (speed), but at least a little
checking can stop honest mistakes.
Bugfix candidate.
diff --git a/Lib/test/test_datetime.py b/Lib/test/test_datetime.py
index c6dbb48..347b1a9 100644
--- a/Lib/test/test_datetime.py
+++ b/Lib/test/test_datetime.py
@@ -1029,6 +1029,26 @@
self.assertEqual(dt1.toordinal(), dt2.toordinal())
self.assertEqual(dt2.newmeth(-7), dt1.year + dt1.month - 7)
+ def test_backdoor_resistance(self):
+ # For fast unpickling, the constructor accepts a pickle string.
+ # This is a low-overhead backdoor. A user can (by intent or
+ # mistake) pass a string directly, which (if it's the right length)
+ # will get treated like a pickle, and bypass the normal sanity
+ # checks in the constructor. This can create insane objects.
+ # The constructor doesn't want to burn the time to validate all
+ # fields, but does check the month field. This stops, e.g.,
+ # datetime.datetime('1995-03-25') from yielding an insane object.
+ base = '1995-03-25'
+ if not issubclass(self.theclass, datetime):
+ base = base[:4]
+ for month_byte in '9', chr(0), chr(13), '\xff':
+ self.assertRaises(TypeError, self.theclass,
+ base[:2] + month_byte + base[3:])
+ for ord_byte in range(1, 13):
+ # This shouldn't blow up because of the month byte alone. If
+ # the implementation changes to do more-careful checking, it may
+ # blow up because other fields are insane.
+ self.theclass(base[:2] + chr(ord_byte) + base[3:])
#############################################################################
# datetime tests