Bug#1007226: g_time_zone_new_offset() assertion failure if offset >= 25 hours

[Simon McVittie]

Control: retitle -1 g_time_zone_new_offset() assertion failure if offset >= 25 hours
Control: tags -1 = upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/2620

On Tue, 15 Mar 2022 at 11:53:24 -0400, Robbie Harwood (frozencemetery) wrote:
> #4  0x00007ffff7ddc6a6 in g_time_zone_new_offset (seconds=158400) at ../../../glib/gtimezone.c:1960
> #5  0x00007ffff7f2be1e in get_tzone (token=token at entry=0x7fffffffd930) at ./gmime/gmime-utils.c:505
> #6  0x00007ffff7f2da1c in parse_rfc822_date (tokens=0x55555567bf40) at ./gmime/gmime-utils.c:557
> #7  g_mime_utils_header_decode_date (str=str at entry=0x55555567d650 "Sun, 13 Mar 2022 21:00:43 +4400")
>     at ./gmime/gmime-utils.c:758

The problem appears to be that the message sender is claiming to be
in a time zone 44 hours away from UTC, but g_time_zone_new_offset()
crashes with an assertion failure if the offset is at least 25 hours
(offsets more than 24 hours make little sense, and the function that
parses them returns NULL, but g_time_zone_new_offset() asserts that it
always gets a non-NULL result).

I'm not sure whether this is a GMime bug for calling
g_time_zone_new_offset() with an excessive offset, or a GLib bug for
not accepting the excessive offset, but it's certainly a bug *somewhere*...
I'll see what upstream think.

    smcv