This somehow similar to the previous issue with IPs with leading zeros #30999

/cc @bradfitz @rsc @ianlancetaylor

(It's not that similar... the problem there was that other software interpreted IPs with leading 0s as being a different address, whereas here, we're just accepting values that other software would reject as invalid.)

RFC 4632 Section 3.1 states that only valid prefixes are integer values, also reinforced by RFC 4291 Section 2.3:

is a decimal value specifying how many of the leftmost contiguous bits of the address comprise the prefix.

I feel like we should be more rigorous in the validation of what we accept as a valid prefix, instead of relying simply on what the Atoi function can parse.

The doc comment for ParsePrefix also assumes only valid values are the ones that conform to this:

The string can be in the form "192.168.1.0/24" or "2001:db8::/32"

cc @neild

Yeah, I think we should tighten this down and not accept + or leading zeros.

/cc @danderson

Yup, makes sense to me. I assume we're accepting + here due to strconv.ParseUint or somesuch?

Yup, makes sense to me. I assume we're accepting + here due to strconv.ParseUint or somesuch?

Exactly, we rely on strconv.Atoi to parse the bits, which allow +, - and leading zeroes.

Question now is, we want to transform these into an error or silently ignore non-digits and leading zeroes from the prefix?

This somehow similar to the previous issue with IPs with leading zeros #30999

netip.ParsePrefix("1.2.3.0/+24")

that should be an error IMHO

Change https://go.dev/cl/538860 mentions this issue: net/netip: allow only valid prefix digits in ParsePrefix

@bradfitz is this something can be backported?

Backports are for critical issues with no workaround, and minor releases prioritize backwards compatibility as much as possible. (https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance) This doesn't seem critical and can be worked around, so I don't think a backport is apprpriate.

@neild, it probably should be backported. It's low risk and there's no good workaround when the invalid input is a dozen layers deep in some JSON structure you're unmarshaling and expected to be well-formed.