Interestingly, {0,1,3}.{freebsd,fedora,debian,ubuntu}.pool.ntp.org support only IPv4. While 2.{freebsd,fedora,debian,ubuntu}.pool.ntp.org all support IPv4 and IPv6.

What Linux did was a hack. (Remember PAM was written by Sun Microsysystems 20, 25 years ago). Short of changing the spec or adding some kind of kernel interface the linux-pam maintainer implemented a hack.

Agreed. No.

Why is this surprising? /etc/master.passwd is 0600 (or we repeat the mistakes of the 1980's and 1990's again). pam_unix.so is loaded into and runs in the process's own address space under the UID of the user, a user who must not have read access to /etc/master.passwd (FreeBSD) or /etc/shadow (Linux, Solaris).

The other option might be to create a port that would provide an alternate pam_unix.so with an accompanying daemon. Or possibly add a linux-pam port. Either option is ugly and not recommended either.

The case construct is probably the most elegant solution.

Further to my previous comment, I'm thinking:

I see that.

Works

My mistake. The randomness issue was fixed a while ago.

Agreed. I commented, before, that a rate limit that is adjusted by a 16 bit value was a regression. Reducing the randomness from 32 to the original 16 bits will duplicate the same mistake WPA made with WPS. This change would allow any attacker to guess the port number more easily. @rpokala expressed it better than I did. I would be OK with this if the random adjustment remained a 32 bit value.