Open msalle opened 1 year ago
Fixed with #209.
Kept open until next release.
@ellert do you think you could add the changes from PR #209 into EPEL and Debian? Alternatively could we make a new release? I again bumped into the issue, this time on a client machine trying to run myproxy-get-delegation which hit the same code. Updating to my temporary RPMs from https://copr.fedorainfracloud.org/coprs/msalle/gct-quickfixes/ fixed it as expected.
@msalle: I think a release is overdue since a while already. And sorry for being practically absent for quite a while, but I was heavily occupied otherwise. I will work on this (the release) and see that it gets done until end of the year. But I count on your help with this. :-)
@ellert do you think you could add the changes from PR #209 into EPEL and Debian?
I have now created updates in Fedora, EPEL and Debian.
In various places the GCT is confusing
ASN1_UTCTIME
andASN1_GENERALIZEDTIME
, assumingASN1_TIME
is always aASN1_UTCTIME
.globus_gsi_cert_utils_make_time
in globus_gsi_cert_utils.c is only valid forASN1_UTCTIME
, since it assumes 2-digit years, but is also used to parse anyASN1_TIME
, for example in myproxy'sssl_get_times()
and numerous other places.In particular globus_gsi_cert_utils.c lines 245-250 assumes that the year is always 2 digits. That is only true when the type is
V_ASN1_UTCTIME
, i.e. 23. However, from 1/1/2050, it will get encoded as aV_ASN1_GENERALIZEDTIME
(i.e. 24) and will take 4 digits.See https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.5 and https://stackoverflow.com/q/10975542 but more in particular https://stackoverflow.com/a/59721373. The last link also points to ASN1_TIME_to_tm which will work from 1.1.1 onwards. Since we still need to support 1.0.2 we cannot use it always unfortunately.
We probably can rework the whole code to use
ASN1_TIME_diff()
instead, which does already work for 1.0.2 and can even directly get the current time.