Author m-parry
Recipients m-parry
Date 2017-03-27.13:48:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1490622527.46.0.936939014549.issue29921@psf.upfronthosting.co.za>
In-reply-to
Content
The change in issue #29100 - intended AFAICS simply to fix a regression in 3.6 - seems to have made datetime validation via certain code paths stricter than it was in 2.7 or 3.5. I think it's the case that some routes via the C API now reject out of range values that were previously permitted. Even if this previous behaviour was incorrect, was it intentional to alter that in a maintenance release?

Here's a quick example using pywin32:

---

> import getpass, sspi, sspicon, win32security
> client_name = getpass.getuser()
> auth_info = (client_name, 'wherever.com', None)
> pkg_info = win32security.QuerySecurityPackageInfo('Kerberos')
> win32security.AcquireCredentialsHandle(
>     client_name, pkg_info['Name'],
>     sspicon.SECPKG_CRED_OUTBOUND,
>     None, auth_info)

ValueError: year 30828 is out of range

---

Of course, this is probably a mishandling of the 'never expires' value returned by the Windows API in this case, and indeed I have also created a pywin32 ticket. However, I'm guessing that the linked issue wasn't supposed to break such code.
History
Date User Action Args
2017-03-27 13:48:47m-parrysetrecipients: + m-parry
2017-03-27 13:48:47m-parrysetmessageid: <1490622527.46.0.936939014549.issue29921@psf.upfronthosting.co.za>
2017-03-27 13:48:47m-parrylinkissue29921 messages
2017-03-27 13:48:47m-parrycreate