I had a CI run fail to "Upload reports":

    Exponential backoff for retry #1. Waiting for 4565 milliseconds before continuing the upload at offset 0
    Finished backoff for retry #1, continuing with upload
    Total file count: 211 ---- Processed file moby#160 (75.8%)
    ...
    Total file count: 211 ---- Processed file moby#164 (77.7%)
    Total file count: 211 ---- Processed file moby#164 (77.7%)
    Total file count: 211 ---- Processed file moby#164 (77.7%)
    A 503 status code has been received, will attempt to retry the upload
    ##### Begin Diagnostic HTTP information #####
    Status Code: 503
    Status Message: Service Unavailable
    Header Information: {
      "content-length": "592",
      "content-type": "application/json; charset=utf-8",
      "date": "Mon, 21 Aug 2023 14:08:10 GMT",
      "server": "Kestrel",
      "cache-control": "no-store,no-cache",
      "pragma": "no-cache",
      "strict-transport-security": "max-age=2592000",
      "x-tfs-processid": "b2fc902c-011a-48be-858d-c62e9c397cb6",
      "activityid": "49a48b53-0411-4ff3-86a7-4528e3f71ba2",
      "x-tfs-session": "49a48b53-0411-4ff3-86a7-4528e3f71ba2",
      "x-vss-e2eid": "49a48b53-0411-4ff3-86a7-4528e3f71ba2",
      "x-vss-senderdeploymentid": "63be6134-28d1-8c82-e969-91f4e88fcdec",
      "x-frame-options": "SAMEORIGIN"
    }
    ###### End Diagnostic HTTP information ######
    Retry limit has been reached for chunk at offset 0 to https://pipelinesghubeus5.actions.githubusercontent.com/Y2huPMnV2RyiTvKoReSyXTCrcRyxUdSDRZYoZr0ONBvpl5e9Nu/_apis/resources/Containers/8331549?itemPath=integration-reports%2Fubuntu-22.04-systemd%2Fbundles%2Ftest-integration%2FTestInfoRegistryMirrors%2Fd20ac12e48cea%2Fdocker.log
    Warning: Aborting upload for /tmp/reports/ubuntu-22.04-systemd/bundles/test-integration/TestInfoRegistryMirrors/d20ac12e48cea/docker.log due to failure
    Error: aborting artifact upload
    Total file count: 211 ---- Processed file moby#165 (78.1%)
    A 503 status code has been received, will attempt to retry the upload
    Exponential backoff for retry #1. Waiting for 5799 milliseconds before continuing the upload at offset 0

As a result, the "Download reports" continued retrying:

    ...
    Total file count: 1004 ---- Processed file moby#436 (43.4%)
    Total file count: 1004 ---- Processed file moby#436 (43.4%)
    Total file count: 1004 ---- Processed file moby#436 (43.4%)
    An error occurred while attempting to download a file
    Error: Request timeout: /Y2huPMnV2RyiTvKoReSyXTCrcRyxUdSDRZYoZr0ONBvpl5e9Nu/_apis/resources/Containers/8331549?itemPath=integration-reports%2Fubuntu-20.04%2Fbundles%2Ftest-integration%2FTestCreateWithDuplicateNetworkNames%2Fd47798cc212d1%2Fdocker.log
        at ClientRequest.<anonymous> (/home/runner/work/_actions/actions/download-artifact/v3/dist/index.js:3681:26)
        at Object.onceWrapper (node:events:627:28)
        at ClientRequest.emit (node:events:513:28)
        at TLSSocket.emitRequestTimeout (node:_http_client:839:9)
        at Object.onceWrapper (node:events:627:28)
        at TLSSocket.emit (node:events:525:35)
        at TLSSocket.Socket._onTimeout (node:net:550:8)
        at listOnTimeout (node:internal/timers:559:17)
        at processTimers (node:internal/timers:502:7)
    Exponential backoff for retry #1. Waiting for 5305 milliseconds before continuing the download
    Total file count: 1004 ---- Processed file moby#436 (43.4%)

And, it looks like GitHub doesn't allow cancelling the job, possibly
because it is defined with `if: always()`?

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

I had a CI run fail to "Upload reports":

    Exponential backoff for retry #1. Waiting for 4565 milliseconds before continuing the upload at offset 0
    Finished backoff for retry #1, continuing with upload
    Total file count: 211 ---- Processed file moby#160 (75.8%)
    ...
    Total file count: 211 ---- Processed file moby#164 (77.7%)
    Total file count: 211 ---- Processed file moby#164 (77.7%)
    Total file count: 211 ---- Processed file moby#164 (77.7%)
    A 503 status code has been received, will attempt to retry the upload
    ##### Begin Diagnostic HTTP information #####
    Status Code: 503
    Status Message: Service Unavailable
    Header Information: {
      "content-length": "592",
      "content-type": "application/json; charset=utf-8",
      "date": "Mon, 21 Aug 2023 14:08:10 GMT",
      "server": "Kestrel",
      "cache-control": "no-store,no-cache",
      "pragma": "no-cache",
      "strict-transport-security": "max-age=2592000",
      "x-tfs-processid": "b2fc902c-011a-48be-858d-c62e9c397cb6",
      "activityid": "49a48b53-0411-4ff3-86a7-4528e3f71ba2",
      "x-tfs-session": "49a48b53-0411-4ff3-86a7-4528e3f71ba2",
      "x-vss-e2eid": "49a48b53-0411-4ff3-86a7-4528e3f71ba2",
      "x-vss-senderdeploymentid": "63be6134-28d1-8c82-e969-91f4e88fcdec",
      "x-frame-options": "SAMEORIGIN"
    }
    ###### End Diagnostic HTTP information ######
    Retry limit has been reached for chunk at offset 0 to https://pipelinesghubeus5.actions.githubusercontent.com/Y2huPMnV2RyiTvKoReSyXTCrcRyxUdSDRZYoZr0ONBvpl5e9Nu/_apis/resources/Containers/8331549?itemPath=integration-reports%2Fubuntu-22.04-systemd%2Fbundles%2Ftest-integration%2FTestInfoRegistryMirrors%2Fd20ac12e48cea%2Fdocker.log
    Warning: Aborting upload for /tmp/reports/ubuntu-22.04-systemd/bundles/test-integration/TestInfoRegistryMirrors/d20ac12e48cea/docker.log due to failure
    Error: aborting artifact upload
    Total file count: 211 ---- Processed file moby#165 (78.1%)
    A 503 status code has been received, will attempt to retry the upload
    Exponential backoff for retry #1. Waiting for 5799 milliseconds before continuing the upload at offset 0

As a result, the "Download reports" continued retrying:

    ...
    Total file count: 1004 ---- Processed file moby#436 (43.4%)
    Total file count: 1004 ---- Processed file moby#436 (43.4%)
    Total file count: 1004 ---- Processed file moby#436 (43.4%)
    An error occurred while attempting to download a file
    Error: Request timeout: /Y2huPMnV2RyiTvKoReSyXTCrcRyxUdSDRZYoZr0ONBvpl5e9Nu/_apis/resources/Containers/8331549?itemPath=integration-reports%2Fubuntu-20.04%2Fbundles%2Ftest-integration%2FTestCreateWithDuplicateNetworkNames%2Fd47798cc212d1%2Fdocker.log
        at ClientRequest.<anonymous> (/home/runner/work/_actions/actions/download-artifact/v3/dist/index.js:3681:26)
        at Object.onceWrapper (node:events:627:28)
        at ClientRequest.emit (node:events:513:28)
        at TLSSocket.emitRequestTimeout (node:_http_client:839:9)
        at Object.onceWrapper (node:events:627:28)
        at TLSSocket.emit (node:events:525:35)
        at TLSSocket.Socket._onTimeout (node:net:550:8)
        at listOnTimeout (node:internal/timers:559:17)
        at processTimers (node:internal/timers:502:7)
    Exponential backoff for retry #1. Waiting for 5305 milliseconds before continuing the download
    Total file count: 1004 ---- Processed file moby#436 (43.4%)

And, it looks like GitHub doesn't allow cancelling the job, possibly
because it is defined with `if: always()`?

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit d6f340e)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

…f v1.5.4

full diffs:

- protocolbuffers/protobuf-go@v1.31.0...v1.33.0
- golang/protobuf@v1.5.3...v1.5.4

From the Go security announcement list;

> Version v1.33.0 of the google.golang.org/protobuf module fixes a bug in
> the google.golang.org/protobuf/encoding/protojson package which could cause
> the Unmarshal function to enter an infinite loop when handling some invalid
> inputs.
>
> This condition could only occur when unmarshaling into a message which contains
> a google.protobuf.Any value, or when the UnmarshalOptions.UnmarshalUnknown
> option is set. Unmarshal now correctly returns an error when handling these
> inputs.
>
> This is CVE-2024-24786.

In a follow-up post;

> A small correction: This vulnerability applies when the UnmarshalOptions.DiscardUnknown
> option is set (as well as when unmarshaling into any message which contains a
> google.protobuf.Any). There is no UnmarshalUnknown option.
>
> In addition, version 1.33.0 of google.golang.org/protobuf inadvertently
> introduced an incompatibility with the older github.com/golang/protobuf
> module. (golang/protobuf#1596) Users of the older
> module should update to github.com/golang/protobuf@v1.5.4.

govulncheck results in our code:

    govulncheck ./...
    Scanning your code and 1221 packages across 204 dependent modules for known vulnerabilities...

    === Symbol Results ===

    Vulnerability #1: GO-2024-2611
        Infinite loop in JSON unmarshaling in google.golang.org/protobuf
      More info: https://pkg.go.dev/vuln/GO-2024-2611
      Module: google.golang.org/protobuf
        Found in: google.golang.org/protobuf@v1.31.0
        Fixed in: google.golang.org/protobuf@v1.33.0
        Example traces found:
          #1: daemon/logger/gcplogs/gcplogging.go:154:18: gcplogs.New calls logging.Client.Ping, which eventually calls json.Decoder.Peek
          #2: daemon/logger/gcplogs/gcplogging.go:154:18: gcplogs.New calls logging.Client.Ping, which eventually calls json.Decoder.Read
          #3: daemon/logger/gcplogs/gcplogging.go:154:18: gcplogs.New calls logging.Client.Ping, which eventually calls protojson.Unmarshal

    Your code is affected by 1 vulnerability from 1 module.
    This scan found no other vulnerabilities in packages you import or modules you
    require.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

api: Make EnableIPv6 optional (impl #1 - pointer-based)

When a port mapping is created with a HostIP specified, we insert a DNAT
rule in nat-DOCKER to replace the dest addr with the container IP. Then,
in filter chains, we allow access to the container port for any packet
not coming from the container's network itself (if hairpinning is
disabled), nor from another host bridge. (see below)

However we don't set any rule that prevent a rogue neighbor located in
another L2 segment / subnet from sending packets destined to that
HostIP.

For instance, if a port binding is created with HostIP == '127.0.0.1',
this port should not be accessible from anything but the lo interface.
That's currently not the case and this provides a false sense of
security.

Since nat-DOCKER mangles the dest addr, and the nat table rejects DROP
rules, this change adds rules into raw-PREROUTING to filter ingress
packets destined to mapped ports based on the input interface, the dest
addr and the dest port.

Interfaces are resolved by making a fib lookup of the HostIP (if it's
not unspecified). In most cases, this should be fine - even in HA
scenarios where multiple links might be aggregated, the HostIP would
match the address assigned to a bond / bridge interface. However, the
env var `DOCKER_DISABLE_FILTER_BY_INPUT_IFACE` can be set to skip this
input filtering rule.

```
$ iptables-tracer -skip-modprobe -filter 'udp port 5000'
INFO[0000] Waiting for trace events...
IN=eth-test OUT= SRC=192.168.123.3 DST=172.17.0.2 LEN=35 TOS=00 TTL=64 ID=63941 PROTO=UDP SPT=48601 DPT=5000 CSUM=e7df
	nat DOCKER NFMARK=0x0
		MATCH RULE (#3): -d 172.17.0.2/32 ! -i br-fb571312de21 -p udp -m udp --dport 5000 -j DNAT --to-destination 172.19.0.2:5000
		=> DNAT: --to-destination 172.19.0.2:5000
	filter DOCKER NFMARK=0x0
		MATCH RULE (#1): -d 172.19.0.2/32 ! -i br-fb571312de21 -o br-fb571312de21 -p udp -m udp --dport 5000 -j ACCEPT
		=> ACCEPT
```

Signed-off-by: Albin Kerouanton <albinker@gmail.com>

When a port mapping is created with a HostIP specified, we insert a DNAT
rule in nat-DOCKER to replace the dest addr with the container IP. Then,
in filter chains, we allow access to the container port for any packet
not coming from the container's network itself (if hairpinning is
disabled), nor from another host bridge. (see below)

However we don't set any rule that prevent a rogue neighbor located in
another L2 segment / subnet from sending packets destined to that
HostIP.

For instance, if a port binding is created with HostIP == '127.0.0.1',
this port should not be accessible from anything but the lo interface.
That's currently not the case and this provides a false sense of
security.

Since nat-DOCKER mangles the dest addr, and the nat table rejects DROP
rules, this change adds rules into raw-PREROUTING to filter ingress
packets destined to mapped ports based on the input interface, the dest
addr and the dest port.

Interfaces are resolved by making a fib lookup of the HostIP (if it's
not unspecified). In most cases, this should be fine - even in HA
scenarios where multiple links might be aggregated, the HostIP would
match the address assigned to a bond / bridge interface. However, the
env var `DOCKER_DISABLE_FILTER_BY_INPUT_IFACE` can be set to skip this
input filtering rule.

```
$ iptables-tracer -skip-modprobe -filter 'udp port 5000'
INFO[0000] Waiting for trace events...
IN=eth-test OUT= SRC=192.168.123.3 DST=172.17.0.2 LEN=35 TOS=00 TTL=64 ID=63941 PROTO=UDP SPT=48601 DPT=5000 CSUM=e7df
	nat DOCKER NFMARK=0x0
		MATCH RULE (#3): -d 172.17.0.2/32 ! -i br-fb571312de21 -p udp -m udp --dport 5000 -j DNAT --to-destination 172.19.0.2:5000
		=> DNAT: --to-destination 172.19.0.2:5000
	filter DOCKER NFMARK=0x0
		MATCH RULE (#1): -d 172.19.0.2/32 ! -i br-fb571312de21 -o br-fb571312de21 -p udp -m udp --dport 5000 -j ACCEPT
		=> ACCEPT
```

Signed-off-by: Albin Kerouanton <albinker@gmail.com>

When a port mapping is created with a HostIP specified, we insert a DNAT
rule in nat-DOCKER to replace the dest addr with the container IP. Then,
in filter chains, we allow access to the container port for any packet
not coming from the container's network itself (if hairpinning is
disabled), nor from another host bridge. (see below)

However we don't set any rule that prevent a rogue neighbor located in
another L2 segment / subnet from sending packets destined to that
HostIP.

For instance, if a port binding is created with HostIP == '127.0.0.1',
this port should not be accessible from anything but the lo interface.
That's currently not the case and this provides a false sense of
security.

Since nat-DOCKER mangles the dest addr, and the nat table rejects DROP
rules, this change adds rules into raw-PREROUTING to filter ingress
packets destined to mapped ports based on the input interface, the dest
addr and the dest port.

Interfaces are resolved by making a fib lookup of the HostIP (if it's
not unspecified). In most cases, this should be fine - even in HA
scenarios where multiple links might be aggregated, the HostIP would
match the address assigned to a bond / bridge interface. However, the
env var `DOCKER_DISABLE_FILTER_BY_INPUT_IFACE` can be set to skip this
input filtering rule.

```
$ iptables-tracer -skip-modprobe -filter 'udp port 5000'
INFO[0000] Waiting for trace events...
IN=eth-test OUT= SRC=192.168.123.3 DST=172.17.0.2 LEN=35 TOS=00 TTL=64 ID=63941 PROTO=UDP SPT=48601 DPT=5000 CSUM=e7df
	nat DOCKER NFMARK=0x0
		MATCH RULE (#3): -d 172.17.0.2/32 ! -i br-fb571312de21 -p udp -m udp --dport 5000 -j DNAT --to-destination 172.19.0.2:5000
		=> DNAT: --to-destination 172.19.0.2:5000
	filter DOCKER NFMARK=0x0
		MATCH RULE (#1): -d 172.19.0.2/32 ! -i br-fb571312de21 -o br-fb571312de21 -p udp -m udp --dport 5000 -j ACCEPT
		=> ACCEPT
```

Signed-off-by: Albin Kerouanton <albinker@gmail.com>

When a port mapping is created with a HostIP specified, we insert a DNAT
rule in nat-DOCKER to replace the dest addr with the container IP. Then,
in filter chains, we allow access to the container port for any packet
not coming from the container's network itself (if hairpinning is
disabled), nor from another host bridge. (see below)

However we don't set any rule that prevent a rogue neighbor located in
another L2 segment / subnet from sending packets destined to that
HostIP.

For instance, if a port binding is created with HostIP == '127.0.0.1',
this port should not be accessible from anything but the lo interface.
That's currently not the case and this provides a false sense of
security.

Since nat-DOCKER mangles the dest addr, and the nat table rejects DROP
rules, this change adds rules into raw-PREROUTING to filter ingress
packets destined to mapped ports based on the input interface, the dest
addr and the dest port.

Interfaces are resolved by making a fib lookup of the HostIP (if it's
not unspecified). In most cases, this should be fine - even in HA
scenarios where multiple links might be aggregated, the HostIP would
match the address assigned to a bond / bridge interface. However, the
env var `DOCKER_DISABLE_FILTER_BY_INPUT_IFACE` can be set to skip this
input filtering rule.

```
$ iptables-tracer -skip-modprobe -filter 'udp port 5000'
INFO[0000] Waiting for trace events...
IN=eth-test OUT= SRC=192.168.123.3 DST=172.17.0.2 LEN=35 TOS=00 TTL=64 ID=63941 PROTO=UDP SPT=48601 DPT=5000 CSUM=e7df
	nat DOCKER NFMARK=0x0
		MATCH RULE (#3): -d 172.17.0.2/32 ! -i br-fb571312de21 -p udp -m udp --dport 5000 -j DNAT --to-destination 172.19.0.2:5000
		=> DNAT: --to-destination 172.19.0.2:5000
	filter DOCKER NFMARK=0x0
		MATCH RULE (#1): -d 172.19.0.2/32 ! -i br-fb571312de21 -o br-fb571312de21 -p udp -m udp --dport 5000 -j ACCEPT
		=> ACCEPT
```

Signed-off-by: Albin Kerouanton <albinker@gmail.com>

When a port mapping is created with a HostIP specified, we insert a DNAT
rule in nat-DOCKER to replace the dest addr with the container IP. Then,
in filter chains, we allow access to the container port for any packet
not coming from the container's network itself (if hairpinning is
disabled), nor from another host bridge. (see below)

However we don't set any rule that prevent a rogue neighbor located in
another L2 segment / subnet from sending packets destined to that
HostIP.

For instance, if a port binding is created with HostIP == '127.0.0.1',
this port should not be accessible from anything but the lo interface.
That's currently not the case and this provides a false sense of
security.

Since nat-DOCKER mangles the dest addr, and the nat table rejects DROP
rules, this change adds rules into raw-PREROUTING to filter ingress
packets destined to mapped ports based on the input interface, the dest
addr and the dest port.

Interfaces are resolved by making a fib lookup of the HostIP (if it's
not unspecified). In most cases, this should be fine - even in HA
scenarios where multiple links might be aggregated, the HostIP would
match the address assigned to a bond / bridge interface. However, the
env var `DOCKER_DISABLE_FILTER_BY_INPUT_IFACE` can be set to skip this
input filtering rule.

```
$ iptables-tracer -skip-modprobe -filter 'udp port 5000'
INFO[0000] Waiting for trace events...
IN=eth-test OUT= SRC=192.168.123.3 DST=172.17.0.2 LEN=35 TOS=00 TTL=64 ID=63941 PROTO=UDP SPT=48601 DPT=5000 CSUM=e7df
	nat DOCKER NFMARK=0x0
		MATCH RULE (#3): -d 172.17.0.2/32 ! -i br-fb571312de21 -p udp -m udp --dport 5000 -j DNAT --to-destination 172.19.0.2:5000
		=> DNAT: --to-destination 172.19.0.2:5000
	filter DOCKER NFMARK=0x0
		MATCH RULE (#1): -d 172.19.0.2/32 ! -i br-fb571312de21 -o br-fb571312de21 -p udp -m udp --dport 5000 -j ACCEPT
		=> ACCEPT
```

Signed-off-by: Albin Kerouanton <albinker@gmail.com>

contains a fix for CVE-2024-45338 / https://go.dev/issue/70906,
but it doesn't affect our codebase:

    govulncheck -show=verbose ./...
    Scanning your code and 1260 packages across 211 dependent modules for known vulnerabilities...
    ...
    Vulnerability #1: GO-2024-3333
        Non-linear parsing of case-insensitive content in golang.org/x/net/html
      More info: https://pkg.go.dev/vuln/GO-2024-3333
      Module: golang.org/x/net
        Found in: golang.org/x/net@v0.32.0
        Fixed in: golang.org/x/net@v0.33.0

    Your code is affected by 0 vulnerabilities.
    This scan also found 0 vulnerabilities in packages you import and 1
    vulnerability in modules you require, but your code doesn't appear to call these
    vulnerabilities.

full diff: golang/net@v0.32.0...v0.33.0

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>