github.com/opentofu/opentofu@v1.7.1/internal/ipaddr/README.md (about)

     1  # Forked IP address parsing functions
     2  
     3  This directory contains a subset of code from the Go project's `net` package
     4  as of Go 1.16, used under the Go project license which we've included here
     5  in [`LICENSE`](LICENSE) and [`PATENTS`](PATENTS), which are also copied from
     6  the Go project.
     7  
     8  OpenTofu has its own fork of these functions because Go 1.17 included a
     9  breaking change to reject IPv4 address octets written with leading zeros.
    10  
    11  The Go project rationale for that change was that Go historically interpreted
    12  leading-zero octets inconsistently with many other implementations, trimming
    13  off the zeros and still treating the rest as decimal rather than treating the
    14  octet as octal.
    15  
    16  The Go team made the reasonable observation that having a function that
    17  interprets a non-normalized form in a manner inconsistent with other
    18  implementations may cause naive validation or policy checks to produce
    19  incorrect results, and thus it's a potential security concern. For more
    20  information, see [Go issue #30999](https://golang.org/issue/30999).
    21  
    22  After careful consideration, it was concluded that OpenTofu's
    23  use of these functions as part of the implementation of the `cidrhost`,
    24  `cidrsubnet`, `cidrsubnets`, and `cidrnetmask` functions has a more limited
    25  impact than the general availability of these functions in the Go standard
    26  library, and so we can't justify a similar exception to our compatibility
    27  promises as the Go team made to their Go 1.0 compatibility promises.
    28  
    29  If you're considering using this package for new functionality _other than_ the
    30  built-in functions mentioned above, please do so only if consistency with the
    31  behavior of those functions is important. Otherwise, new features are not
    32  burdened by the same compatibility constraints and so should typically prefer
    33  to use the stricter interpretation of the upstream parsing functions.