chore: fill or remove RSR template placeholders

[hyperpolymath]

openssf-compliance.yml fails when any of the thirteen files it checks still contains a {{PLACEHOLDER}} token. This clears them, with no invention.

• Deleted the TEMPLATE INSTRUCTIONS (delete this block before publishing) comment — the template says to delete it, and it is where every legend line lived, so a large share of the reported tokens were the file documenting its own placeholders.
• Filled what the repository itself supplies: owner and repo from the git remote, project name, year, forge, main branch, contact email.
• Removed PGP and website lines. https://github.com/<user>.gpg returns HTTP 200 for every account; with no key uploaded the body is a stub reading "This user hasn't uploaded any GPG keys". No key is published for either account, and commit signing here is SSH — unrelated. The template sanctions this: "Optional: Remove sections that don't apply (e.g. PGP if you don't use it)."\n\nA security policy telling a researcher to encrypt to a key that does not exist is worse than one that does not mention encryption.\n\nWhere applicable, this also fixes a misrouted advisory URL. A previous just init copied already-filled templates out of squisher-corpus, so 51 repositories directed vulnerability reports to hyperpolymath/squisher-corpus — a repository unrelated to the code being reported, meaning the affected maintainer never saw them. Repointed from this repository's own git remote.

[gitar-bot]

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

CI failed: 1 build failure in the Elixir plugin due to a syntax error from unescaped characters in a regular expression literal.

Overview

A compilation error occurred during mix compile --warnings-as-errors due to a syntax error in an Elixir source file introduced by the PR changes.

Failures

Elixir Compilation Syntax Error (confidence: high)

• Type: build
• Affected jobs: 90326371678
• Related to change: yes
• Root cause: In lib/http_capability_gateway/plugins/xml_rpc_shield.ex on line 8, a regular expression literal (~r/<methodName>([^<]+)</methodName>/u) contains characters that cause a syntax error (invalid syntax found before '>').
• Suggested fix: Fix the regex syntax in lib/http_capability_gateway/plugins/xml_rpc_shield.ex, for example by using alternative delimiters like ~r|<methodName>([^<]+)</methodName>|u.

Summary

• Change-related failures: 1 build compilation error in the Elixir codebase.
• Infrastructure/flaky failures: None.
• Recommended action: Update the regular expression literal in lib/http_capability_gateway/plugins/xml_rpc_shield.ex with proper delimiters or escaping.

Code Review ✅ Approved 7 resolved / 7 findings

Fills RSR template placeholders and removes duplicate governance files across the repository. Blocked by critical compilation errors in WebhookHardener due to missing Bitwise imports, along with several important SSRF and IP parsing bugs.

✅ 7 resolved

✅ Bug: WebhookHardener uses Bitwise operators without importing Bitwise

📄 lib/http_capability_gateway/plugins/webhook_hardener.ex:4-8 📄 lib/http_capability_gateway/plugins/webhook_hardener.ex:65-74
in_cidr?/2 and to_int/1 use &&&, ||| and <<< (lines 69,73,74), but these operators live in the Bitwise module and are not auto-imported. Without import Bitwise (or use Bitwise) the module fails to compile, which breaks mix compile for the whole app once these files are part of lib/. Add import Bitwise at the top of the module.

✅ Bug: try_parse_ip misuses || so IPv6 literals never parse

📄 lib/http_capability_gateway/plugins/webhook_hardener.ex:54-59
:inet.parse_ipv4_address/1 returns {:error, :einval} for an IPv6 literal, and || treats that error tuple as truthy, so :inet.parse_ipv4_address(host) || :inet.parse_ipv6_address(host) short-circuits on the error and never attempts IPv6 parsing. As a result IPv6 targets like [::1]/::1 fail try_parse_ip, fall to the (IPv4-only) gethostbyname path, and are not blocked — an SSRF bypass. Match on the ipv4 result explicitly and fall back to ipv6.

✅ Security: Hostname targets bypass SSRF CIDR block (wrong hostent arity)

📄 lib/http_capability_gateway/plugins/webhook_hardener.ex:44-52
resolve_and_check/2 matches {:ok, {_, _, _, _, ip}} against the result of :inet.gethostbyname/1, but the returned hostent record is a 6-element tuple {:hostent, name, aliases, addrtype, length, addr_list}. The 5-element pattern never matches, so any target given as a hostname (not a literal IP) falls through to _ -> false and is never blocked — defeating the SSRF protection for e.g. http://internal.host/. Even if the arity were fixed, the address field is a list (h_addr_list), not a single ip. Destructure the hostent and check each address in the list.

✅ Bug: in_cidr? calls nonexistent :inet.parse_cidr_address and misuses mask

📄 lib/http_capability_gateway/plugins/webhook_hardener.ex:65-71
There is no :inet.parse_cidr_address/1 in OTP (the inet module exposes parse_ipv4_address/parse_ipv6_address/parse_address only). The <- in the with will raise UndefinedFunctionError, which the else _ -> false clause does NOT catch (it only catches non-matching values), so ip_blocked? crashes on every literal-IP target. Additionally the code ANDs an integer ip with mask, but a CIDR mask from any such parser is an address tuple, not an integer bit-mask. Use a real CIDR parser (e.g. compute the prefix mask from the /n suffix) and apply an integer mask.

✅ Bug: IPv6 to_int uses 8-bit shifts for 16-bit groups

📄 lib/http_capability_gateway/plugins/webhook_hardener.ex:74
to_int/1 for the 8-element IPv6 tuple shifts by 120/112/104/... (8-bit steps), but each IPv6 group is a 16-bit value (0-65535). Adjacent groups overlap, producing an incorrect integer and wrong CIDR comparisons for IPv6. Shift by 16-bit steps (112,96,80,...) instead.

...and 2 more resolved from earlier reviews

Tip

Comment Gitar fix CI to trigger a fix.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}