Description of problem: x509watch always reports "not valid" for some files in ca-certificates-2012.87-10.4.fc19.noarch as lited in the Actual results. This doesn't happed in a x86_64 machine with same version-release of perl. I reviewed /usr/bin/x509watch mktime at line 205 returns undef in case $ year > 2038 and the Y2K38 workaround hard coded in the script from line 226 to 241 limits the perl patchlevel less than 12 but I ran the script with perl 5.16.3 in fc19 then the wrok around skipped. Version-Release number of selected component (if applicable): Name : x509watch Version : 0.5.0 Release : 4.fc19 Architecture: noarch Name : perl Epoch : 4 Version : 5.16.3 Release : 265.fc19 Architecture: i686 Name : ca-certificates Version : 2012.87 Release : 10.4.fc19 Architecture: noarch How reproducible: Just run /usr/bin/x509watch in i686 fc19 machine with the versions of perl and ca-certificates. Steps to Reproduce: 1. run /usr/bin/x509watch 2. check console and mailed report 3. Actual results: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem (Chambers of Commerce Root - 2008) is not valid since 2038-07-31 /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem (Global Chambersign Root - 2008) is not valid since 2038-07-31 /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem (StartCom Certification Authority G2) is not valid since 2039-12-31 /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem (Chambers of Commerce Root - 2008) is not valid since 2038-07-31 /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem (Global Chambersign Root - 2008) is not valid since 2038-07-31 /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem (StartCom Certification Authority G2) is not valid since 2039-12-31 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (AffirmTrust Premium) is not valid since 2040-12-31 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (AffirmTrust Premium ECC) is not valid since 2040-12-31 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (Buypass Class 2 Root CA) is not valid since 2040-10-26 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (Buypass Class 3 Root CA) is not valid since 2040-10-26 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (Chambers of Commerce Root - 2008) is not valid since 2038-07-31 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (Global Chambersign Root - 2008) is not valid since 2038-07-31 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (StartCom Certification Authority G2) is not valid since 2039-12-31 Expected results: All files should be valid and nothing reported Additional info: Best regards, - Kazuro
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.