Somewhat related to https://en.wikipedia.org/wiki/Year_2038_problem
int overflows in submit-u.c could happen if someone specified 3600w .
3600w
int overflows in prefs.c happen when timestamps are over 68 years apart.
This patch was done while reviewing potential year-2038 issues in openSUSE.
Signed-off-by: Bernhard M. Wiedemann bwiedemann@suse.de
Thanks for the PR.
The prefs.c is fine though probably unnecessary. It is more qsort-like though. It doesn't actually need the true difference. Note that this is controlled by /etc/certmonger/certmonger.conf which is owned by root so any risk here should be minimal unless someone is configuring gigantic values. But still, it's fine.
The second change is similar in that it should be administratively controlled (e.g. root) and who is issuing a 3600w certificate? But it is still a possibility. I don't believe the suggested change covers all possible overflows though. A long string could still overflow an integer, e.g. 999999999999y will overflow val in val = (val * 10) + (c - '0'). An int is also generally 32-bit so can still overflow where time_t would not. Finally, the values of now_tm are ints so could overflow.
So maybe check the return value of mktime, -1 is a failure, log and return a failure in cm_submit_u_delta_from_string(). The log would be important so an admin would understand why the default value is applied.
Somewhat related to https://en.wikipedia.org/wiki/Year_2038_problem
int overflows in submit-u.c could happen if someone specified
3600w.int overflows in prefs.c happen when timestamps are over 68 years apart.
This patch was done while reviewing potential year-2038 issues in openSUSE.
Signed-off-by: Bernhard M. Wiedemann bwiedemann@suse.de