Bump version to 1.0.18-dev

[jkreileder]

Update the version number to 1.0.18-dev.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (90ebdb0) to head (080f6a1).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #844   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          151       151           
  Branches        11        11           
=========================================
  Hits           151       151           

Flag	Coverage Δ
python-3.10	100.00% <100.00%> (ø)
python-3.11	100.00% <100.00%> (ø)
python-3.12	100.00% <100.00%> (ø)
python-3.13	100.00% <100.00%> (ø)
python-3.9	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

🔍 Vulnerabilities of jkreileder/cf-ips-to-hcloud-fw:pr-844

📦 Image Reference jkreileder/cf-ips-to-hcloud-fw:pr-844

digest	sha256:cdb29ebf4bd9ffafd0b192770d2eeae49f9afd83822353492ad6c57a0f33f3d0
vulnerabilities
platform	linux/amd64
size	26 MB
packages	60

📦 Base Image python:1b526bbd121103d964aa0fd7edce60b8cd99c79b0eddd8e3113cb3fea6386904

also known as	3-alpine 3-alpine3.22 3.13-alpine 3.13-alpine3.22 3.13.5-alpine 3.13.5-alpine3.22 alpine alpine3.22
digest	sha256:1e58d36e5c24f88877f10b5fed6d0597a2ece96b3bb2236252c79b8e902e405b
vulnerabilities

h11 0.14.0 (pypi) pkg:pypi/[email protected] OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <0.16.0 Fixed version 0.16.0 CVSS Score 9.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N Description A leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') Affected range <0.16.0 Fixed version 0.16.0 CVSS Score 9.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N EPSS Score 0.044% EPSS Percentile 13th percentile Description Impact A leniency in h11's parsing of line terminators in chunked-coding message bodies can lead to request smuggling vulnerabilities under certain conditions. Details HTTP/1.1 Chunked-Encoding bodies are formatted as a sequence of "chunks", each of which consists of: chunk length \r\n length bytes of content \r\n In versions of h11 up to 0.14.0, h11 instead parsed them as: chunk length \r\n length bytes of content any two bytes i.e. it did not validate that the trailing \r\n bytes were correct, and if you put 2 bytes of garbage there it would be accepted, instead of correctly rejecting the body as malformed. By itself this is harmless. However, suppose you have a proxy or reverse-proxy that tries to analyze HTTP requests, and your proxy has a different bug in parsing Chunked-Encoding, acting as if the format is: chunk length \r\n length bytes of content more bytes of content, as many as it takes until you find a \r\n For example, pound had this bug -- it can happen if an implementer uses a generic "read until end of line" helper to consumes the trailing \r\n. In this case, h11 and your proxy may both accept the same stream of bytes, but interpret them differently. For example, consider the following HTTP request(s) (assume all line breaks are \r\n): GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked 5 AAAAAXX2 45 0 GET /two HTTP/1.1 Host: localhost Transfer-Encoding: chunked 0 Here h11 will interpret it as two requests, one with body AAAAA45 and one with an empty body, while our hypothetical buggy proxy will interpret it as a single request, with body AAAAXX20\r\n\r\nGET /two .... And any time two HTTP processors both accept the same string of bytes but interpret them differently, you have the conditions for a "request smuggling" attack. For example, if /two is a dangerous endpoint and the job of the reverse proxy is to stop requests from getting there, then an attacker could use a bytestream like the above to circumvent this protection. Even worse, if our buggy reverse proxy receives two requests from different users: GET /one HTTP/1.1 Host: localhost Transfer-Encoding: chunked 5 AAAAAXX999 0 GET /two HTTP/1.1 Host: localhost Cookie: SESSION_KEY=abcdef... ...it will consider the first request to be complete and valid, and send both on to the h11-based web server over the same socket. The server will then see the two concatenated requests, and interpret them as one request to /one whose body includes /two's session key, potentially allowing one user to steal another's credentials. Patches Fixed in h11 0.15.0. Workarounds Since exploitation requires the combination of buggy h11 with a buggy (reverse) proxy, fixing either component is sufficient to mitigate this issue. Credits Reported by Jeppe Bonde Weikop on 2025-01-09.

urllib3 2.3.0 (pypi) pkg:pypi/[email protected] URL Redirection to Untrusted Site ('Open Redirect') Affected range <2.5.0 Fixed version 2.5.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N EPSS Score 0.009% EPSS Percentile 1st percentile Description urllib3 supports being used in a Pyodide runtime utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means you can use Python libraries to make HTTP requests from your browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects. However, the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behavior. Affected usages Any code which relies on urllib3 to control the number of redirects for an HTTP request in a Pyodide runtime. Impact Redirects are often used to exploit SSRF vulnerabilities. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects may remain vulnerable if a Pyodide runtime redirect mechanism is unsuitable. Remediation If you use urllib3 in Node.js, upgrade to a patched version of urllib3. Unfortunately, browsers provide no suitable way which urllib3 can use: XMLHttpRequest provides no control over redirects, the Fetch API returns opaqueredirect responses lacking data when redirects are controlled manually. Expect default browser behavior for redirects. URL Redirection to Untrusted Site ('Open Redirect') Affected range <2.5.0 Fixed version 2.5.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N EPSS Score 0.010% EPSS Percentile 1st percentile Description urllib3 handles redirects and retries using the same mechanism, which is controlled by the Retry object. The most common way to disable redirects is at the request level, as follows: resp = urllib3.request("GET", "https://httpbin.org/redirect/1", redirect=False) print(resp.status) # 302 However, it is also possible to disable redirects, for all requests, by instantiating a PoolManager and specifying retries in a way that disable redirects: import urllib3 http = urllib3.PoolManager(retries=0) # should raise MaxRetryError on redirect http = urllib3.PoolManager(retries=urllib3.Retry(redirect=0)) # equivalent to the above http = urllib3.PoolManager(retries=False) # should return the first response resp = http.request("GET", "https://httpbin.org/redirect/1") However, the retries parameter is currently ignored, which means all the above examples don't disable redirects. Affected usages Passing retries on PoolManager instantiation to disable redirects or restrict their number. By default, requests and botocore users are not affected. Impact Redirects are often used to exploit SSRF vulnerabilities. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. Remediation You can remediate this vulnerability with the following steps: Upgrade to a patched version of urllib3. If your organization would benefit from the continued support of urllib3 1.x, please contact [email protected] to discuss sponsorship or contribution opportunities. Disable redirects at the request() level instead of the PoolManager() level.

requests 2.32.3 (pypi) pkg:pypi/[email protected] Insufficiently Protected Credentials Affected range <2.32.4 Fixed version 2.32.4 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N EPSS Score 0.062% EPSS Percentile 20th percentile Description Impact Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Workarounds For older versions of Requests, use of the .netrc file can be disabled with trust_env=False on your Requests Session (docs). References psf/requests#6965 https://seclists.org/fulldisclosure/2025/Jun/2

[github-actions]

Recommended fixes for image jkreileder/cf-ips-to-hcloud-fw:pr-844

Base image is python:3-alpine

Name	3.13.5-alpine3.22
Digest	sha256:1e58d36e5c24f88877f10b5fed6d0597a2ece96b3bb2236252c79b8e902e405b
Vulnerabilities
Pushed	1 week ago
Size	17 MB
Packages	39
Flavor	alpine
OS	3.22
Runtime	3.13.5

The base image is also available under the supported tag(s): 3-alpine3.22, 3.13-alpine, 3.13-alpine3.22, 3.13.5-alpine, 3.13.5-alpine3.22, alpine, alpine3.22

Refresh base image

Rebuild the image using a newer base image version. Updating this may result in breaking changes.

✅ This image version is up to date.

Change base image

✅ There are no tag recommendations at this time.

[github-actions]

Overview

Image reference	jkreileder/cf-ips-to-hcloud-fw:1	quay.io/jkreileder/cf-ips-to-hcloud-fw:pr-844
- digest	a013f898285a	cdb29ebf4bd9
- tag	1	pr-844
- provenance	90ebdb0	c5ea4c6
- vulnerabilities
- platform	linux/amd64	linux/amd64
- size	23 MB	26 MB (+3.6 MB)
- packages	60	60
Base Image	python:3-alpine also known as: • 3-alpine3.22 • 3.13-alpine • 3.13-alpine3.22 • 3.13.5-alpine • 3.13.5-alpine3.22 • alpine • alpine3.22	python:3-alpine also known as: • 3-alpine3.22 • 3.13-alpine • 3.13-alpine3.22 • 3.13.5-alpine • 3.13.5-alpine3.22 • alpine • alpine3.22
- vulnerabilities

Labels (3 changes)

• ± 3 changed
• 5 unchanged

-org.opencontainers.image.created=2025-06-20T11:12:42.735Z
+org.opencontainers.image.created=2025-06-20T11:24:48.412Z
 org.opencontainers.image.description=Update Hetzner Cloud firewall rules with current Cloudflare IP ranges
 org.opencontainers.image.licenses=MIT
-org.opencontainers.image.revision=90ebdb0cde09868906e19bfb8b149a1abd09824b
+org.opencontainers.image.revision=c5ea4c65ce896c20c438e3fae8ffdaf7aa853f71
 org.opencontainers.image.source=https://github.com/jkreileder/cf-ips-to-hcloud-fw
 org.opencontainers.image.title=cf-ips-to-hcloud-fw
 org.opencontainers.image.url=https://github.com/jkreileder/cf-ips-to-hcloud-fw
-org.opencontainers.image.version=1.0.17
+org.opencontainers.image.version=pr-844

Policies (0 improved, 1 worsened, 2 missing data)

Policy Name	jkreileder/cf-ips-to-hcloud-fw:1	quay.io/jkreileder/cf-ips-to-hcloud-fw:pr-844	Change	Standing
Default non-root user	✅	✅		No Change
No AGPL v3 licenses	✅	✅		No Change
No fixable critical or high vulnerabilities	⚠️ 2	⚠️ 2		No Change
No high-profile vulnerabilities	✅	✅		No Change
No outdated base images	✅	❓ No data
No unapproved base images	✅	❓ No data
Supply chain attestations	✅	⚠️ 2	+2	Worsened

Packages and Vulnerabilities (1 package changes and 0 vulnerability changes)

• ♾️ 1 packages changed
• 59 packages unchanged

Changes for packages of type pypi (1 changes)

	Package	Version jkreileder/cf-ips-to-hcloud-fw:1	Version quay.io/jkreileder/cf-ips-to-hcloud-fw:pr-844
♾️	cf-ips-to-hcloud-fw	1.0.17	1.0.18.dev0

[github-actions]

Test Results

  5 files  ±0    5 suites  ±0   6s ⏱️ -1s
 36 tests ±0   36 ✅ ±0  0 💤 ±0  0 ❌ ±0 
180 runs  ±0  180 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 080f6a1. ± Comparison against base commit 90ebdb0.