Why not let the administrator decide?

> Not because it's too much of a burden to maintain,

Are you sure? It *is* much of a burden, IMO.

The patch set that removed the expiry(1) program is +2/-2916. The patch set that removed .sp_min is +24/-1241.

The draft patch set that will remove the rest of password aging is going to remove 19.5k lines of text (including source code, tests, docs, ...).

And prior to this, we already significantly reduced related features, such as the allowed date formats, since parsing dates is really hard. Just in source code, we've removed thousands of lines of code, and will remove hundreds more.

Handling of dates is hard. We've had to fix a large number of bugs in that code (including integer overflows) in the recent years.

> and now the code to implement them has to be removed.

That's the nicest part. That includes removing some of the ugliest code we have in the project. Adding dates is something "interesting", which I'm happy to not need to do anymore.

> That decision is just as opaque as the original decision that passwords should be expired periodically.

I believe linking to scientific research that shows that password expiration provides no tangible benefits is not being opaque. I invite you to read that paper thoroughly: <https://people.scs.carleton.ca/~paulv/papers/expiration-a...>.

> wouldn't it be better to have the infrastructure be mostly policy-neutral, and let the admin decide? At least if the support for expiration is already there and working.

Support for expiration is already there, but "working" is probably too much to say about it.