Freeze BKG 2.0.4 and eBL (plus modules) 3.0.3

[HenrikHL]

No description provided.

[qodo-code-review]

Review Summary by Qodo

Freeze BKG 2.0.4 and eBL 3.0.3 with module versions

✨ Enhancement

Walkthroughs

Description

• Freeze BKG version 2.0.4 in forbidden changes list
• Freeze eBL version 3.0.3 and all related modules
• Prevent accidental modifications to released versions

Diagram

flowchart LR
  A["BKG v2.0.4"] --> B["Forbidden Changes List"]
  C["eBL v3.0.3"] --> B
  D["eBL Endorsement v3.0.3"] --> B
  E["eBL Issuance v3.0.3"] --> B
  F["eBL Surrender v3.0.3"] --> B
  B --> G["Version Protection"]

Loading

File Changes

1. .github/forbidden_changes.txt ⚙️ Configuration changes +5/-0

Add version 3.0.3 and 2.0.4 to forbidden changes

• Added bkg/v2/BKG_v2.0.4.yaml to frozen versions list
• Added ebl/v3/EBL_v3.0.3.yaml to frozen versions list
• Added ebl/v3/endorsement/EBL_END_v3.0.3.yaml to frozen versions list
• Added ebl/v3/issuance/EBL_ISS_v3.0.3.yaml to frozen versions list
• Added ebl/v3/surrender/EBL_SUR_v3.0.3.yaml to frozen versions list

.github/forbidden_changes.txt

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2)   📘 Rule violations (0)   📎 Requirement gaps (0)   🎨 UX Issues (0)

🐞\ ⛨ Security (1) ⚙ Maintainability (1)

1. PR file list truncation 🐞 ⛨

Description

The forbidden-change workflow only fetches the first 100 changed files (per_page: 100) and does
not paginate, so forbidden edits can slip through in PRs that change more than 100 files (including
the newly frozen specs). This undermines the freeze enforcement guarantee.

Code

.github/forbidden_changes.txt[26]

+ebl/v3/EBL_v3.0.3.yaml

Evidence

The workflow uses pulls.listFiles with per_page: 100 and then only inspects response.data,
with no pagination loop/paginate helper; therefore only the first page of changed files is checked
against forbidden paths.

.github/workflows/check_forbidden_changes.yml[39-48]
.github/workflows/check_forbidden_changes.yml[62-70]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The forbidden-change check only evaluates the first page (max 100) of PR files, allowing forbidden edits to bypass detection in large PRs.

### Issue Context
This PR expands the set of frozen specs (e.g., `ebl/v3/EBL_v3.0.3.yaml`). The enforcement mechanism must reliably evaluate *all* changed files.

### Fix Focus Areas
- .github/workflows/check_forbidden_changes.yml[39-48]
- .github/workflows/check_forbidden_changes.yml[62-70]

### Implementation notes
Use Octokit pagination (e.g., `github.paginate(github.rest.pulls.listFiles, { owner, repo, pull_number, per_page: 100 })`) or a manual loop over `page` until fewer than `per_page` results are returned, then build `changedFiles` from the full aggregated list.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unescaped regex forbidden paths 🐞 ⚙

Description

The workflow compiles each forbidden_changes.txt entry via new RegExp(forbiddenPath) without
escaping or anchoring, so newly added literal file paths containing . are treated as regex
wildcards and can match unintended paths. This can cause unexpected CI failures and makes the
forbidden list semantics ambiguous.

Code

.github/forbidden_changes.txt[9]

+bkg/v2/BKG_v2.0.4.yaml

Evidence

The forbidden list contains literal file names like bkg/v2/BKG_v2.0.4.yaml, but the workflow
treats each line as a raw regex pattern. In regex, . matches any character, and without ^...$
anchoring, patterns can match substrings of other paths as the repo evolves.

.github/forbidden_changes.txt[5-11]
.github/forbidden_changes.txt[23-35]
.github/workflows/check_forbidden_changes.yml[62-67]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`forbidden_changes.txt` entries are treated as raw regular expressions. Newly added entries like `BKG_v2.0.4.yaml` include regex metacharacters (`.`) and are not anchored, which can over-match and produce surprising enforcement behavior.

### Issue Context
The workflow is intended to block changes to specific versioned spec files/directories. That intent is best served by treating entries as literal paths (or explicit globs), not arbitrary regex.

### Fix Focus Areas
- .github/workflows/check_forbidden_changes.yml[22-23]
- .github/workflows/check_forbidden_changes.yml[62-67]

### Implementation notes
Options:
1) Treat each line as a literal path: `const escaped = forbiddenPath.trim().replace(/[.*+?^${}()|[\]\\]/g, '\\$&'); const regex = new RegExp('^' + escaped + '$');`
2) If glob support is desired (`*`), use a glob matcher (e.g., minimatch) instead of `RegExp`, or translate globs to regex safely (`*` -> `.*`) and still anchor with `^...$`.
Also trim each line before compiling to avoid issues with accidental whitespace/CRLF.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Pr file list truncation 🐞 Bug ⛨ Security

The forbidden-change workflow only fetches the first 100 changed files (per_page: 100) and does
not paginate, so forbidden edits can slip through in PRs that change more than 100 files (including
the newly frozen specs). This undermines the freeze enforcement guarantee.

Agent Prompt

### Issue description
The forbidden-change check only evaluates the first page (max 100) of PR files, allowing forbidden edits to bypass detection in large PRs.

### Issue Context
This PR expands the set of frozen specs (e.g., `ebl/v3/EBL_v3.0.3.yaml`). The enforcement mechanism must reliably evaluate *all* changed files.

### Fix Focus Areas
- .github/workflows/check_forbidden_changes.yml[39-48]
- .github/workflows/check_forbidden_changes.yml[62-70]

### Implementation notes
Use Octokit pagination (e.g., `github.paginate(github.rest.pulls.listFiles, { owner, repo, pull_number, per_page: 100 })`) or a manual loop over `page` until fewer than `per_page` results are returned, then build `changedFiles` from the full aggregated list.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools