As documented in pam_unix(8), the nullok_secure option means that null passwords are allowed for this module only when connected via one of the "secure" (that is, generally speaking, "local") ttys listed in /etc/securetty. The tty is not determined directly by pam_unix, but is instead provided to the PAM stack by the calling application setting the PAM_TTY value with pam_set_item(). This is further documented in pam_set_item(3) to be:
PAM_TTY
The terminal name: prefixed by /dev/ if it is a device file; for graphical, X-based, applications the value for this item should be
the $DISPLAY variable.
If gdm is not setting the PAM_TTY item, then that's a bug in gdm, not in PAM.
The /etc/securetty list of values is regrettably not comprehensive (because e.g. it doesn't support pattern matching), so if your system has been changed to run gdm on an X display beyond :3, the default value will not work for you. However, I don't see any reason this would occur unless the settings of gdm itself had been changed away from the defaults, and if you've done this you will need to adjust the contents of /etc/securetty to match.
As documented in pam_unix(8), the nullok_secure option means that null passwords are allowed for this module only when connected via one of the "secure" (that is, generally speaking, "local") ttys listed in /etc/securetty. The tty is not determined directly by pam_unix, but is instead provided to the PAM stack by the calling application setting the PAM_TTY value with pam_set_item(). This is further documented in pam_set_item(3) to be:
PAM_TTY
graphical, X-based, applications the value for this item should be
The terminal name: prefixed by /dev/ if it is a device file; for
the $DISPLAY variable.
If gdm is not setting the PAM_TTY item, then that's a bug in gdm, not in PAM.
The /etc/securetty list of values is regrettably not comprehensive (because e.g. it doesn't support pattern matching), so if your system has been changed to run gdm on an X display beyond :3, the default value will not work for you. However, I don't see any reason this would occur unless the settings of gdm itself had been changed away from the defaults, and if you've done this you will need to adjust the contents of /etc/securetty to match.