golang.org/x/net contains a fix for CVE-2022-41717, which was addressed
in stdlib in go1.19.4 and go1.18.9;
> net/http: limit canonical header cache by bytes, not entries
>
> An attacker can cause excessive memory growth in a Go server accepting
> HTTP/2 requests.
>
> HTTP/2 server connections contain a cache of HTTP header keys sent by
> the client. While the total number of entries in this cache is capped,
> an attacker sending very large keys can cause the server to allocate
> approximately 64 MiB per open connection.
>
> This issue is also fixed in golang.org/x/net/http2 v0.4.0,
> for users manually configuring HTTP/2.
full diff: https://github.com/golang/net/compare/v0.2.0...v0.4.0
other dependency updates (due to (circular) dependencies):
- golang.org/x/sys v0.3.0: https://github.com/golang/sys/compare/3c1f35247d10...v0.3.0
- golang.org/x/text v0.5.0: https://github.com/golang/text/compare/v0.3.7...v0.5.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 9337b8df6644390f427162143ee8c83ad3db7c96 rewrote the fuzzers to
native go fuzzers, so the script was no longer needed. With this, the
script directory is no longer used, so we can remove it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is just cosmetic; alighn the fields with the order in which they appear
in the struct (and JSON output).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
I am looking at aligning the types defined in this repository with the
OCI image specification, and potentially exchanging local types with
those from the specification.
This patch is a stepping-stone towards that effort, but as this changes
the format of the serialized JSON, I wanted to put this up first before
proceeding with the other work in case there are concerns.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This makes them easier to find between the non-exported ones, and puts
them as separate sections in the generated docs. While updating, also
extended documentation for some to be more descriptive.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Localhost is treated special when parsing references, and always considered
to be a domain, despite not having a "." nor a ":port". Adding a const for
this, to allow documenting this special case (making it more visible).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This pattern was used in two places, so adding an intermediate variable allows
documenting its purpose. The "remote-name" grammer (which is interchangably
used with "path") also seemed to be missing from the grammar, so adding it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `domain` variable didn't make it clear that this could include port-numbers
as well, so renaming it makes that more visible.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The remaining uses of "expression()" were quite trivial; probably goes without
saying, but just using string-concatenating for these is more performant as well,
and removing the extra abstraction may make it easier to read;
pkg: github.com/distribution/distribution/v3/reference
BenchmarkExpression
BenchmarkExpression-10 27260877 43.10 ns/op 24 B/op 1 allocs/op
BenchmarkConcat
BenchmarkConcat-10 1000000000 0.3154 ns/op 0 B/op 0 allocs/op
PASS
ok github.com/distribution/distribution/v3/reference 1.762s
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With the exception of ".", none of the literals used required escaping, which made
the function rather redundant (and the extra abstraction made it harder to read).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
NameRegexp does not have capturing groups, so updating the documentation
to reflect that.
To verify if this was an unintentional regression, I looked up the commit
that introduced this regex (31a448a628b61bc50d4790b49c489b5747ebeca5), and
it looks like it never had capturing groups, so this was just a mistake in
the docs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch:
- makes regexp strings that are constant a const
- moves some variables closer to where they're used
- removes some intermediate vars
- un-wraps some lines; they're lengthy, but probably more readable than having
them wrapped over multiple lines.
- touches-up some docs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was removed in 6d4f62d7fdfa25bd4bb42a18995c50aeededc0d6, which forgot
to remove it from the grammar.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
My mistake; I added this TODO in 552b1526c6821a84daab48cbc7f5456ae215d6c4, but it
only applies to familiarizeName.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Not all tests have been rewritten to use sub-tests; for those
I enabled t.Parallel() for the parent test only.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`registry/storage/driver/inmemory/driver_test.go` times out after ~10min. The slow test is `testsuites.go:TestWriteReadLargeStreams()` which writes a 5GB file.
Root cause is inefficient slice reallocation algorithm. The slice holding file bytes grows only 32K on each allocation. To fix it, this PR grows slice exponentially.
Signed-off-by: Wei Meng <wemeng@microsoft.com>
Go 1.18 and up now provides a strings.Cut() which is better suited for
splitting key/value pairs (and similar constructs), and performs better:
```go
func BenchmarkSplit(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_ = strings.SplitN(s, "=", 2)[0]
}
}
}
func BenchmarkCut(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_, _, _ = strings.Cut(s, "=")
}
}
}
```
BenchmarkSplit
BenchmarkSplit-10 8244206 128.0 ns/op 128 B/op 4 allocs/op
BenchmarkCut
BenchmarkCut-10 54411998 21.80 ns/op 0 B/op 0 allocs/op
While looking at occurrences of `strings.Split()`, I also updated some for alternatives,
or added some constraints;
- for cases where an specific number of items is expected, I used `strings.SplitN()`
with a suitable limit. This prevents (theoretical) unlimited splits.
- in some cases it we were using `strings.Split()`, but _actually_ were trying to match
a prefix; for those I replaced the code to just match (and/or strip) the prefix.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Embed the interface that we're mocking; calling any of it's methods
that are not implemented will panic, so should give the same result
as before.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- use strings.HasPrefix() to check for the prefix we're interested in instead
of doing a strings.Split() without limits. This makes the code both easier
to read, and prevents potential situations where we end up with a long slice.
- use consts for defaults; these should never be modified, so better to use
consts for them to indicate they're fixed values.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
