Page MenuHome GnuPG

Year 2038 issue for key validity date
Testing, NormalPublic

Description

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
[...]

Details

Version
all

Event Timeline

werner triaged this task as Normal priority.
werner added projects: gnupg22, gnupg24, Bug Report.
werner added a subscriber: werner.

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).

werner changed the task status from Open to Testing.Oct 26 2023, 9:33 AM
werner moved this task from Backlog to QA on the gnupg24 board.
werner changed the task status from Testing to Open.Oct 26 2023, 9:41 AM
werner moved this task from QA to WiP on the gnupg22 board.

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.

werner changed the task status from Open to Testing.Oct 26 2023, 4:25 PM
werner moved this task from WiP to QA on the gnupg24 board.
ebo edited projects, added gnupg22 (gnupg-2.2.42); removed gnupg22.
ebo moved this task from gnupg-2.2.42 to QA on the gnupg22 board.
ebo edited projects, added gnupg22; removed gnupg22 (gnupg-2.2.42).

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.

ebo changed the task status from Testing to Open.Oct 30 2023, 4:01 PM
ebo moved this task from QA to WiP on the gnupg22 board.

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.

werner changed the task status from Open to Testing.Thu, Nov 9, 2:17 PM
werner moved this task from QA to gnupg-2.2.42 on the gnupg22 board.
werner edited projects, added gnupg22 (gnupg-2.2.42); removed gnupg22.