Skip to content

docs: state the npm-publish environment bound as it now exists - #240

Merged
luisleo526 merged 1 commit into
mainfrom
core/tnx-npmdocs
Oct 21, 2026
Merged

luisleo526 merged 1 commit into
mainfrom
core/tnx-npmdocs

Conversation

@luisleo526

Copy link
Copy Markdown
Contributor

Follow-up to #238. The CONTRIBUTING.md and npm/README.md sentences said the server-side bound on npm publishing was "outside this change". It now exists: both npm jobs run in the npm-publish environment, which has a main-only deployment-branch policy, and the npm trusted publisher requires that environment. Text only, 2 files.

🤖 Generated with Claude Code

…ain-only `npm-publish` environment

PR #238 merged with two doc sentences that still said the server-side bound is configured
by an admin "outside this change". The change did add it (both npm jobs declare
`environment: npm-publish`, merged as 197c831) and the environment exists with a
`main`-only deployment-branch policy. CONTRIBUTING.md and npm/README.md now say that.

Rewritten sentence, in both files, by six consecutive words of the old text: "a
server-side bound requires an admin to configure a GitHub environment ... to require it,
outside this change".

New text: the bound is the GitHub environment `npm-publish`; `publish` and `claim-npm` run
in it; its main-only deployment-branch policy makes GitHub refuse a run from any other ref;
the npm trusted publisher is set by the owner to require the environment (owner decision
NPM-TP), a setting on npmjs.com that cannot be read from this repository, so a publish from
a workflow that does not declare the environment fails at npm. The claim about npm is
attributed to the owner's setting, not asserted as verified here.

Text only: 2 files, no workflow, test or code change. Not run: no local checks on this
machine; the PR's CI runs as usual.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
@luisleo526
luisleo526 merged commit d1a018f into main Oct 21, 2026
5 checks passed
luisleo526 added a commit that referenced this pull request Oct 25, 2026
* CHANGELOG: sections for 1.6.2 and 1.6.3 (release-notes backfill, CR-315)

The CHANGELOG had no 1.6.2 or 1.6.3 section: 1.7.0 sat directly above 1.6.1, although the
release note policy at the top of the file asks for a section per released version. This
adds both, from the tags (`git log` and `git diff` between v1.6.1, v1.6.2, v1.6.3) and the
GitHub release notes and the published advisory GHSA-5www-2x9c-mgr6:

- 1.6.3 (2026-10-23): the security fix merged from a private fork (commit 0418898,
  "Codegen can emit C++ calls and type names taken from the input script", high, CWE-94,
  affected pineforge-codegen 0.6.4 up to 1.6.3 and @pineforge/codegen-pyodide 0.7.0 up to
  1.6.3), stated as the advisory states it and without a reproduction recipe; and #237,
  #238, #239, #240 (CI, npm publishing environment, documentation).
- 1.6.2 (2026-10-21): the pf-cpp-allowlist checker (#210), the LIBC_RESERVED_NAMES
  reserved-name change in the emitter, the licensor entity written as PINEFORGE LLC (#234),
  and the CI changes #212, #214, #215, #216, #217, #221, #223, #225, #233, #236.

Additions only (0 lines removed): no sentence is replaced. No file other than CHANGELOG.md
changes.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

* CHANGELOG: 1.6.3 compatibility text states that the security fix refuses scripts (REV P2) (CR-315)

REV-CX's read of the CR-315 backfill (reports/verdict-cr315.md) found that the 1.6.3
Compatibility bullet understated the fix. Checked against `git diff v1.6.2 v1.6.3` of
pineforge_codegen/ before writing it:

- visit_call.py / visit_expr.py: an unknown call or a member read on a builtin-backed
  receiver no longer reaches the emitted C++ as text; it ends with
  "<name>(...) is not implemented in PineForge runtime.";
- parser.py: a string, number or operator in a type position or inside <...> raises a
  located ParseError;
- support_checker.py: array.new / array.from with an undeclared element type is refused
  with the same "not implemented" message;
- types.py: the default of an enum-typed element is na<double>() (a name that is not a
  declared user type falls back to its slot's default); visit_expr.py: format, currency
  and order values are typed std::string.

So a script that compiled under 1.6.2 can fail under 1.6.3, which the bullet now says.
Also (REV P3): the pf-cpp-allowlist entry carries the advisory's own caveat (a denylist
with known false positives, not proof that a unit is safe), and the Security entry states
that release images before 1.6.3 contain an affected codegen and the 1.6.3 image the fixed
one.

Replaces text added by the previous commit of this change (d009aee), not on main.
CHANGELOG.md only.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

---------

Co-authored-by: Claude Sonnet 5.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant