netinet: Disallow connections to INADDR_ANY

[emaste]

Summary

Previously connect() or sendto() to INADDR_ANY reached some socket bound to some host interface address. Although this was intentional it was an artifact of a different era, and is not desirable now.

In 417b35a97b7669eb0bf417b43e97cccbedbce6f9 @markj added support to disallow connect() to INADDR_ANY. Take the next logical step and disable it by default.

[We can do a call for testing on -current first if desired. I'm certain that all potential fallout will not be found by such a request, though.]

Relnotes: Yes
PR: 280705

[markj]

[We can do a call for testing on -current first if desired. I'm certain that all potential fallout will not be found by such a request, though.]

It might be worth giving a heads-up anyway, just so people have a hint if something stops working.

[emaste]

It might be worth giving a heads-up anyway, just so people have a hint if something stops working.

Yeah, at least a post to -net and -current stating that the default changed, ask people to test if possible but at least be on the lookout for new misbehaviour, and advice on setting the sysctl to revert if necessary.

[jhb]

Does this need an entry in RELNOTES as a followup commit perhaps?

[emaste]

Does this need an entry in RELNOTES as a followup commit perhaps?

It will need a release note, indeed. We have at least two ways that can happen today -- as a result of Relnotes: Yes and by adding to RELNOTES. I believe RELNOTES was originally introduced to capture release notes where Relnotes: Yes was forgotten. It is probably better to capture the important aspect of the change at the time it happens and by the author of the change though, and perhaps we should deprecate Relnotes: Yes

[jhb]

In D47740#1088770, @emaste wrote:

Does this need an entry in RELNOTES as a followup commit perhaps?

It will need a release note, indeed. We have at least two ways that can happen today -- as a result of Relnotes: Yes and by adding to RELNOTES. I believe RELNOTES was originally introduced to capture release notes where Relnotes: Yes was forgotten. It is probably better to capture the important aspect of the change at the time it happens and by the author of the change though, and perhaps we should deprecate Relnotes: Yes

I think of Relnotes: yes as being a quick way to signal that someone _else_ should write a release note, whereas adding an entry to RELNOTES means that the release engineering team can just use that language without rewriting it. For trivial things like a version bump that is obvious from the commit log, I think Relnotes: yes is ok, but for anything non-trivial I think RELNOTES is better and we should encourage it.

[markj]

Ed, is there any particular reason you didn't go ahead with this?

[emaste]

Ed, is there any particular reason you didn't go ahead with this?

It just slipped my mind, thanks for the reminder. I probably put it aside temporarily while pondering a RELNOTES entry and didn't get back to it.