Re: [PATCH] Add key expiration date to key menu for classic PGP and GPGME.

Alejandro Colomar via Mutt-dev <[email protected]> Tue, 7 Jul 2026 01:06:52 +0200
Newsgroups gmane.mail.mutt.devel
Message-ID <akw0fEmrhukLILZr@devuan>
--qe7r7hs4ky47nhre
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <[email protected]>
To: [email protected]
Subject: Re: [PATCH] Add key expiration date to key menu for classic PGP and
 GPGME.
Message-ID: <akw0fEmrhukLILZr@devuan>
References: <[email protected]>
 <aku5OQsmkciVoO_M@devuan>
 <[email protected]>
MIME-Version: 1.0
In-Reply-To: <[email protected]>

Hi Kevin,

On 2026-07-07T07:01:38+0800, Kevin J. McCarthy wrote:
[...]
> > > +/* Compare 2 creation dates and the addresses.  For sorting. */
> > > +static int _crypt_compare_expires(const void *a, const void *b)
> > > +{
> > > +  const crypt_key_t * const *s =3D (const crypt_key_t * const *) a;
> > > +  const crypt_key_t * const *t =3D (const crypt_key_t * const *) b;
> > > +  unsigned long ts =3D 0, tt =3D 0;
> >=20
> > Why don't we use time_t?  Can it overflow?
>=20
> The field according to the GPGME doc is a unsigned long:
>=20
> https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html
>=20
>   unsigned long int timestamp

Ahhh, that explains it; thanks!

>   This is the creation timestamp of the subkey. This is (unsigned
> long)(-1) if the timestamp is invalid, and 0 if it is not   available. No=
te
> that an invalid timestamp indicates a bug in the engine.
>=20
>   unsigned long int expires
>=20
>   This is the expiration timestamp of the subkey, or 0 if the subkey does
> not expire.
>=20
[...]
> > > +    strncpy(tstr, p, 11);
> > > +    tstr[4] =3D '\0';
> > > +    tstr[7] =3D '\0';
> >=20
> > strncpy(3) should never be used for copying strings with truncation.
> >=20
> > Some of its issues are:
> >=20
> > -  It forces you to terminate explicitly, which is error-prone.
> > -  It doesn't detect truncation.
> > -  It makes it more difficult to know if the zeroing is superfluous or
> >   necessary.
>=20
> I agree.  As you noticed in this case, I was moving very old code around.
> We can certainly rewrite it, but I'd prefer to do that in a separate comm=
it.

Yup; certainly.

> > In this case, I'd use the following to replace the code above:
> >=20
> > 	const char  *y, *m, *d;
> >=20
> > 	if (strlen(p) >=3D sizeof(tstr))
> > 		goto bail;
> > 	strcpy(tstr, p);
> > 	p =3D tstr;
> > 	y =3D strsep(&p, "-");
> > 	m =3D strsep(&p, "-");
> > 	d =3D strsep(&p, "-");
> > 	if (p !=3D NULL)
> > 		goto bail;
> >=20
> > > +    if (mutt_atoi(tstr, &time.tm_year, 0) < 0)
> >=20
> > And then here, I'd use y (and in the next two calls, m and d).
> > > +    {
> > > +      p =3D tstr;
> >=20
> > Setting p here seems dead code; am I missing something?
>=20
> No, this was a goofup on my part.  I failed to notice that it was
> resetting p so that it could print a readable error message:
>=20
> bail:
>   muttdbg(5, "invalid number: '%s'", p);
>   return NULL;
>=20
> I will rework the function to that it passes p by reference and updates
> it on error.

[...]

> > > +bail:
> > > +  return -1;
> >=20
> > Why not return -1 directly instead of goto?
>=20
> Yeah this was also because of the refactor, trying the keep the code the
> exact same.  I'll change this too.

Actually, I see value in having the refactor essentially move code.
Maybe the improvement to return early can go in a separate commit.
(I guess you'll figure out the best way forward.)


Have a lovely night!
Alex

--=20
<https://www.alejandro-colomar.es>

--qe7r7hs4ky47nhre
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmpMNQUACgkQ64mZXMKQ
wqk58w/+PheAt3WBkoJqPFx91MM7cRq3WXYXKc6/qOuVcybaVyU/gyaWHelOMAjg
m+yKDH7Sp7N+iEEnUZvJ5nQJ1P+2wVUs8/XaALy+hm5r1s6jHn72bi8s+rWOxFED
EQUdXeROTDE/91fY+zgF/OeJrQliO+Yp/Id2DAMl2blAce3Ci2pbXdWHgHLb3AI5
qBx1ToESgE/kLMybGRm0epAYhoNG8fagUd/4dbYhn5ysi1l1ODkiAjgP0XKr7i87
cgWiwCD+fIgaaGhEIaVbdAHRcFlMYMnXl19uQYWjpN5vwkLpPWLWB+52mLnbnv/J
yLLlz8nAW60WsknMhJk0iYnR2XLcBZQNmuCQXlGDR1VkpTMbgg6JZMTTpIIMIc/K
HbPN7B7TLb8l/GPzplZDPWc5xvg8EK9ofu61wpr/j0q/TQJQFX1P+Ijb3ST3kFVX
p8Pq3u1UbR5yGkDQaetZDJopguKj6VWVK14ML5Uj1wYGhE2mgxLpdEG7LIagNZ1Q
G6nEIWkB/nuij12n5D5Zo71c2WsMCJHxRKXK96mNztaICupEYHpwy6Yr3mmX9ztK
4JVIncQ0geKiUiC1ZrImdtCxkQajSuZ/++P4YSsn6J9Q7h8kq9u+EZrXrz7NB1lr
+TkaZDWlbxpv4DClAbRrqdwQY5iLxajAxOhrBIq55WNM+mQMzrM=
=D46v
-----END PGP SIGNATURE-----

--qe7r7hs4ky47nhre--