Using chpass, add an account expiration of a large date. e.g. January 1, 2119 and save. Using chpass again, attempt to fix the date to something more reasonable. e.g. January 1, 2019. When editing a date other than the one originally entered is displayed. For the above example it shows November 24, 1982. Changing the date to January 1, 2019 and saving fails. Error messages displayed: chpass: entry inconsistent chpass: pw_copy: Invalid argument Workaround: zero out the expiration field for the given user using vipw. chpass now works again.
pwd_mkdb.c and getpwent.c store the password change and expire fields as 32-bit ints so cannot be set beyond Jan 19 2038.
Thank you for the report. In the near future I'll add a band-aid to disallow y2038+ dates, before we can implement a full fix.
Proposed patch to disallow y2038 dates in chpass: https://github.com/emaste/freebsd/commit/d69eea06fcc51bf92bccebea3cb25ac84974d664 (y2048 in commit message is a typo)
Ah, it's actually a y2106 problem: on all archs but i386 we have 64-bit time_t but are storing 32-bit unsigned ints in the pwd db. signed 32 bit int goes to 2038, unsigned 32 bit to 2106. i386 has 32-bit time_t and chpass will already reject post-y2038 dates.
A commit references this bug: Author: emaste Date: Thu Apr 19 12:50:49 UTC 2018 New revision: 332769 URL: https://svnweb.freebsd.org/changeset/base/332769 Log: chpass: reject change/expiry dates beyond y2106 The pwd.db and spwd.db files store the change and expire dates as unsigned 32-bit ints, which overflow in 2106. Reject larger values for now, until the introduction of a v5 password database. i386 has 32-bit time_t and so dates beyond y2038 are already rejected by mktime. PR: 227589 Reviewed by: lidl MFC after: 1 week Sponsored by: The FreeBSD Foundation Changes: head/usr.bin/chpass/util.c
Review to add a note about the y2106 issue in v4 db: https://reviews.freebsd.org/D47731