-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
confusion between ASN1_UTCTIME and ASN1_GENERALIZEDTIME #208
Comments
By using ASN1_TIME_diff() instead of manually parsing the data, we make globus_gsi_cert_utils_make_time() a lot simpler and also work for ASN1_GENERALIZEDTIME and not just ASN1_UTCTIME (i.e. it can use ASN1_TIME). ASN1_TIME_diff requires OpenSSL >= 1.0.2. Also rework globus_gsi_cred_get_lifetime() to just use time(NULL) to get the current UNIX timestamp which means it no longer needs globus_gsi_cert_utils_make_time(). This fixes issue gridcf#208
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. :-) |
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.The text was updated successfully, but these errors were encountered: