Skip to content

chore(release): 0.11.0 #353

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
client-software-ci wants to merge 1 commit into from
Closed

chore(release): 0.11.0 #353

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,15 @@
## 0.11.0 (2026-08-18)

### ⚠ BREAKING CHANGES

@github-actions github-actions Bot Aug 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole entry diverges from what the generator produces, which is the likely root cause of the two attribution problems in the sibling threads.

Two mechanical differences from .semantic_release/CHANGELOG.md.j2 and from all ten prior releases in this file:

  1. Heading text. The template emits ### BREAKING CHANGES; this says ### ⚠ BREAKING CHANGES. Every other occurrence in the file (lines 153, 212, 247, 260, 276, 283, 298, 346, 356) is the plain form, so the next generated release will regenerate the plain heading and the file will carry both spellings.

  2. Missing commit links. Every template bullet ends with ([`{{ commit.short_hash }}`](...commit url)), and every prior entry has them. None of the four bullets here do — they carry PR numbers instead, and those are the numbers that turned out to be wrong.

That pattern points at hand-authoring rather than semantic-release. Since PR numbers do not appear in any of these commit subjects, they had to be supplied by hand, and the #349/#350 references landed on two open Dependabot PRs. Regenerating with the configured tooling would fix the headings, restore the commit links, and drop the manual PR numbers in one step. The dropped d3b978f bullet would come back too, since fix is in patch_tags.

Not a blocker on its own, but the release-notes text is what downstream consumers read to decide whether to pick up a version, so consistency here is load-bearing. .github/scripts/get_latest_changelog.py is unaffected either way — it only keys off the ## h2 boundaries.


* shorten the session working directory name for Windows MAX_PATH — session working dir is no longer prefixed with session ID; `embedded_files<random>` renamed to `ef<random>` (#348)

@github-actions github-actions Bot Aug 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The embedded_files<random> → ef<random> half of this breaking change does not exist in the code.

At this head SHA, src/openjd/sessions/_session.py:2193 still reads prefix="embedded_files" in _create_files_directory — not prefix="ef".

grep -rn prefix="ef" src/ returns nothing, and git log -S prefix="ef" has no commits. #348's message describes the rename in both its body and its BREAKING CHANGE: trailer, but the diff only changed _create_working_directory (prefix=self._session_id → prefix=""). The _create_files_directory prefix was never touched, so the trailer this bullet was derived from was already inaccurate when #348 merged.

The first clause of the bullet ("session working dir is no longer prefixed with session ID") is correct; only the rename clause is wrong.

Worth fixing before the release rather than after, because it inverts the cost of the error. A changelog that omits a breaking change lets consumers discover it at runtime; one that announces a rename that did not happen actively induces the break — a maintainer who updates a pattern from embedded_files[a-z0-9]{8} to ef[a-z0-9]{8} on the strength of these notes ends up with a matcher that fails against every real directory. Relatedly, the 12 characters of MAX_PATH headroom the notes credit to this rename were not actually recovered, which matters given the Windows MAX_PATH motivation for the whole change.

Two ways out: drop the rename clause from this bullet, or land the one-line prefix="ef" change in _create_files_directory so the notes become true. The latter keeps #348's stated MAX_PATH goal intact; it would also need the embedded_files reference in test/openjd/sessions_v0/test_session_let_bindings.py:712 updated.


### Bug Fixes

@github-actions github-actions Bot Aug 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Bug Fixes list drops one fix: commit — the one that names the vulnerability.

There are four fix: commits in 0.10.14..HEAD, but only three bullets:

d3b978f fix: use absolute paths for system commands to prevent PATH injection   <-- not listed
419b434 fix: resolve system commands from trusted dirs, not PATH
3744653 fix: address automated review findings on the trusted-path resolver
3574ced fix: do not cache failed command lookups

fix is in patch_tags, so the generator in .semantic_release/CHANGELOG.md.j2 would have emitted all four.

The omission matters beyond bookkeeping: d3b978f is the only commit subject containing the words "PATH injection". As written, this release's notes describe the fix purely as an implementation detail ("resolve system commands from trusted dirs"), so a downstream consumer scanning changelogs to decide whether to pick up a release cannot tell that 0.11.0 closes a privilege-escalation issue (HackerOne 3942741, CWE-426 per the commit trailers).

Suggest either restoring the dropped bullet or rewording the first one to say what the fix prevents, e.g.:

* resolve system commands from trusted dirs, not PATH — prevents PATH injection
  into privileged helpers (`sudo`, `setsid`, `kill`, `pgrep`) (#351)


* resolve system commands from trusted dirs, not PATH (#349)

@github-actions github-actions Bot Aug 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two of the three Bug Fixes entries point at the wrong PRs.

All three of these fixes landed in #351 (fix: resolve system commands from trusted dirs to prevent PATH injection, merged). Its commits are:

231c951 fix: use absolute paths for system commands to prevent PATH injection
d7b5b19 fix: resolve system commands from trusted dirs, not PATH
1839df4 test: pin the trusted-path resolver's security properties
68265a3 fix: address automated review findings on the trusted-path resolver
a144881 test: pin wrapper-before-symlink-farm ordering on NixOS
98e15fe docs: Reframe resolver comments around problem and solution
3fcbe09 fix: do not cache failed command lookups
fe9c014 test: Wrap a RANGE_EXPR parameter in string() before repr_sh
76faa23 test: Use posixpath.isabs for the POSIX trusted-directory entries

But #349 and #350 are unrelated PRs that are still open and were never part of this release:

So the changelog links readers of a security fix to a Dependabot PR. Suggest attributing all three lines to (#351), or dropping the PR refs on the two that have none of their own.

* do not cache failed command lookups (#350)
* address automated review findings on the trusted-path resolver (#351)

## 0.10.14 (2026-08-11)

### Features
Expand Down
Loading