This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1000912 - Work around certificates valid > 2037 in /usr/bin/x509watch doesn't work for perl 5.16.3-265.fc19.i686
Work around certificates valid > 2037 in /usr/bin/x509watch doesn't work for ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: x509watch (Show other bugs)
19
i686 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
:
Depends On: 1021161
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-26 01:57 EDT by Kazuro Hozono
Modified: 2013-12-15 15:24 EST (History)
2 users (show)

See Also:
Fixed In Version: x509watch-0.6.0-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-08 20:58:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test case POSIX::mktime vs Time::Local::timelocal() (1.86 KB, application/x-perl)
2013-10-20 03:17 EDT, Kazuro Hozono
no flags Details

  None (edit)
Description Kazuro Hozono 2013-08-26 01:57:41 EDT
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
Comment 1 Robert Scheck 2013-10-19 20:40:41 EDT
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?
Comment 2 Kazuro Hozono 2013-10-20 03:17:07 EDT
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
Comment 3 Robert Scheck 2013-10-20 07:36:51 EDT
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?!
Comment 4 Kazuro Hozono 2013-10-20 12:42:49 EDT
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.
Comment 5 Fedora Update System 2013-11-29 03:02:20 EST
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
Comment 6 Fedora Update System 2013-11-29 03:03:10 EST
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
Comment 7 Fedora Update System 2013-11-29 03:04:01 EST
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
Comment 8 Fedora Update System 2013-11-29 03:04:31 EST
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
Comment 9 Fedora Update System 2013-11-29 03:05:05 EST
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
Comment 10 lnie 2013-11-29 04:05:52 EST
0.6.0-1.fc20 works fine
Comment 11 Fedora Update System 2013-11-29 11:00:33 EST
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).
Comment 12 Fedora Update System 2013-12-08 20:58:35 EST
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.
Comment 13 Fedora Update System 2013-12-08 21:04:21 EST
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.
Comment 14 Fedora Update System 2013-12-13 22:28:13 EST
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.
Comment 15 Fedora Update System 2013-12-15 15:24:11 EST
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.
Comment 16 Fedora Update System 2013-12-15 15:24:24 EST
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.

Note You need to log in before you can comment on or make changes to this bug.