Noticed when testing T6519 on Windows:
Giving a date higher than 19.01.2038 and lower than 06.02.2106 on key generation in Kleopatra results in a "General Error":
On the command line the error message is "Invalid value".
C:\Users\g10code.WIN-TEST3\Documents>gpg -v --quick-gen-key abc default default 2038-01-20 [...] gpg: Schlüsselerzeugung fehlgeschlagen: Ungültiger Wert [...]
| rG GnuPG | |||
| rGa4fe307b5535 gpg: Allow expiration time after 2038-01-19 on 32 bit Windows. | |||
| rG164c687cb6a1 common: New functions timegm_u64, isotime2epoch_u64. | |||
| rG5da8fe1c402d gpg: Allow expiration time after 2013-01-19 on 32 bit Windows. | |||
| rGbb70089d5757 common: New functions timegm_u64, isotime2epoch_u64. | |||
| rG606933dfb48d gpg: Allow to specify seconds since Epoch beyond 2038. | |||
| rG5eaf2e926637 gpg: Allow to specify seconds since Epoch beyond 2038. | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T4195 Fix time API in gpgme | ||
| Resolved | • werner | T6736 Year 2038 issue for key validity date | ||
| Resolved | • werner | T6806 Fix off by one day in the expiry date calculation |
I am not sure whether we need to fix things in kleo but at some places gpg uses atoi() to parse the seconds since epoch. This should be fixed because that is the way gpgme provides the expiry time. I will also look into the ISO date string parser.
Some time ago, I have checked and hopefully fixed all usage of time_t in Kleopatra and GpgME to make sure we always use unsigned 32-bit integer arithmetic. Dates entered by the users are capped to some date in 2106 (a few days before the overflow date).
Or better wait. We can now pass "seconds=2147483648" as expire value but that is added to the creation date which might not want we want. I'll look again into this.
For 32 bit WIndows I now hacked some extra code to handle the expiration time if given as ISO string. Although gpg won't display the time correctly on the command line, Kleopatra does this and also allows to set the expiration time.
hmm, almost. With VS-Desktop-3.1.90.258-Beta I do not get an error any more, a key is generated. But the "vaild until" date is off by one day, it is one day later as the one given at key generation.
Eva tested a few expiration dates for new keys: For 2038-01-18 the date is correct. For 2038-01-20 and 2106-02-05 the expiration date of the new key is 2038-01-21 and 2106-02-06 respectively. Kleopatra passes the date as ISO date.
I assume that for the first date mktime succeeds, but for the later two dates it fails, so that the alternative code path using isotime2epoch_u64 is used. One difference is that mktime converts midnight of the given date (possibly taking DST into account), while the second code path uses noon (UTC).
And then we calculate the seconds from now like this:
seconds = (abs_date+86400/2) - curtime;
i.e. we add another 12 hours. My guess is that the combination of twice 12 hours causes the offset of 1 day.