Given you're consistent with P4D's behaviour I wouldn't push too hard on it.

I think allowing an invalid password for an account with no password is poor form though and given how long its been like that I can't imagine p4d can fix it (though our higher level apps certainly could).

Tristan, in swarm (to be more technically correct) we reject loging in with a password if no password is required. i.e. an attempt to auth as gnicol with 'password-guess' will fail if gnicol has no password.

https://swarm.perforce.com/projects/swarm/files/main/library/P4/Connection/AbstractConnection.php#612

I'd suggest the HWS would behave more sanely if it shared this approach.

You very much shouldn't include -f here.

A number of our systems have auto-trust behaviour (Swarm and GitSwarm for example) and it seems to be received well.

The logic however is always to trust if you've never seen it before (trust -y) its quite intentionally not to always trust all the things (trust -y -f).

The latter scenario basically invalidates the MITM protection normally provided by SSL p4 connections and is not a good idea.

Quick glance it looks like 'jsh:' is also a thing and will allow arbitrary command execution.

Blocking rsh: and jsh: when it lands just anywhere isn't a good idea.

It would block blundersh:1666 for example which is a perfectly viable port.

Given your architecture, I'd strongly suggest looking into having p4-api parse the port then asking it to tell you if its this sorta style.
Or adding a flag to the api (if there isn't one) to get it to block execing for port.

No idea. I wouldn't be shocked if whitespace was ignored by p4d (haven't tested don't know) though.

Perhaps there is a more secure way to just inform p4-api you don't want to permit rsh ports?
Or to ask p4-api to parse the report and tell you its type before using it?