Remove two-digit-year variants from certificate validity date decoding #461
Comments
|
fixed in v1.3.3 and merged into current develop branch |
|
This fix is wrong, it broke support for UTCTime, I published a pull request with a fix, but it would be probably better to revert this commit and move the conversion to string inside the if/else blocks (the original problem was that premature conversion to string broke the isinstance() test). |
|
I agree with bdauvergne that the fix is not working. This break since my certificate do report the year using only two digits... |
|
@bear Another +1 to this being an problematic fix - 1.3.3 is currently broken on all hipchat servers due to invalid cert, 1.3.2 works fine. |
|
I think, that library should support both variants. I have proposed a pull request #472, that uses pyasn1 library methods for dates conversion, rather than parsing String representation. I think this will help with your problem as well, but I have not tested it with hipchat servers. |
|
I agree, library should support both formats. |
|
Please reopen this bug. IMHO, the "fix" was wrong. See also https://bugs.debian.org/864257 which is reopened. |
|
There is a real fix?
|
1.3.3 is broken as of fritzy/SleekXMPP#461. Someone seems to have forget to adapt the requirements after the first deployment in 2017 of 7e9e016. Fore reference the exception is ``` ValueError time data '190530023040Z' does not match format '%Y%m%d%H%M%SZ' ```
and others
Issue reported via Debian - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864257
Patch was given so i'm applying it and will spin up a point release.
The text was updated successfully, but these errors were encountered: