| Summary: | Work around certificates valid > 2037 in /usr/bin/x509watch doesn't work for perl 5.16.3-265.fc19.i686 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kazuro Hozono <kazuro.hozono> | ||||
| Component: | x509watch | Assignee: | Robert Scheck <redhat-bugzilla> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 19 | CC: | lnie, redhat-bugzilla | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | x509watch-0.6.0-1.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-12-09 01:58:35 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | 1021161 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Kazuro Hozono
2013-08-26 05:57:41 UTC
http://search.cpan.org/~jesse/perl-5.12.0/pod/perl5120delta.pod#Y2038_compliance In theory, Perl 5.12 (and later) should be Y2K38 aware. Hrmpf! Looks not like it really is? Created attachment 814162 [details]
test case POSIX::mktime vs Time::Local::timelocal()
I attached a test case using to get time value by POSIX mktime and Time::Local::timelocal(). The script prints the time value of 2037-12-31, 2038-01-19 and 2038-01-20 using mktime and timelocal.
In my 32bit environment, mktime returns undef for 20 Jan 2038.
It seems this is not the perl issue but a POSIX mktime issue.
Best regards,
-Kazuro
[Result in 32 bit host]
$ uname -i
i386
$ perl ./timetest.pl
POSIX qw(mktime)
Valid 2145798000 2037-12-31
Valid 2147439600 2038-01-19
Invalid 2038-01-20
Time::Local::timelocal()
Valid 2145798000 2037-12-31
Valid 2147439600 2038-01-19
Valid 2147526000 2038-01-20
[Result in 64 bit host]
$ uname -i
x86_64
$ perl ./timetest.pl
POSIX qw(mktime)
Valid 2145798000 2037-12-31
Valid 2147439600 2038-01-19
Valid 2147526000 2038-01-20
Time::Local::timelocal()
Valid 2145798000 2037-12-31
Valid 2147439600 2038-01-19
Valid 2147526000 2038-01-20
Same using older Perl on 32 bit host: $ perl test.pl POSIX qw(mktime) Valid 2145826800 2037-12-31 Valid 2147468400 2038-01-19 Invalid 2038-01-20 Time::Local::timelocal() Valid 2145826800 2037-12-31 Day too big - 24855 > 24853 Cannot handle date (0, 0, 0, 19, 0, 2038) at test.pl line 67 $ That means upstream made Perl Y2K38 compatible - except for POSIX?! Referring to following two documents, my undtastanding is POSIX::mktime is the wrapper of system call which would not be Y2K38 compatible in most 32 bit systems due to time_t limitation. Time::Local::timelocal is the perl implemention free from time_t. http://perldoc.perl.org/POSIX.html In mktime description; " Consult your system's mktime() manpage for details about these and the other arguments. " http://perldoc.perl.org/Time/Local.html In Limits of time_t explanation; As of version 5.12.0, perl has stopped using the underlying time library of the operating system it's running on and has its own implementation of those routines with a safe range of at least +/ 2**52 (about 142 million years). timelocal checks the ranges of given values so it would casue a trouble in older perl. I think it is better to use mktime and evaluate the return value regardless the perl version in x509watch. x509watch-0.6.0-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/x509watch-0.6.0-1.fc20 x509watch-0.6.0-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/x509watch-0.6.0-1.fc19 x509watch-0.6.0-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/x509watch-0.6.0-1.fc18 x509watch-0.6.0-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/x509watch-0.6.0-1.el6 x509watch-0.6.0-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/x509watch-0.6.0-1.el5 0.6.0-1.fc20 works fine Package x509watch-0.6.0-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing x509watch-0.6.0-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22373/x509watch-0.6.0-1.fc20 then log in and leave karma (feedback). x509watch-0.6.0-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. x509watch-0.6.0-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. x509watch-0.6.0-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. x509watch-0.6.0-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. x509watch-0.6.0-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. |