Skip to content

[BUILD]: Upgrade package ws from 8.20.1 to 8.21.1 - #894

Closed
MacOS wants to merge 2 commits into
SKaiNET-developers:developfrom
MacOS:build/wasm/upgrade-ws-package
Closed

MacOS wants to merge 2 commits into
SKaiNET-developers:developfrom
MacOS:build/wasm/upgrade-ws-package

Conversation

@MacOS

@MacOS MacOS commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

This PR upgrade the ws package from 8.20.1 to 8.21.1 in the yarn.lock file in directory wasm to improve security.

This PR increases the security of the project by bumping package ws to 8.21.1, as the currently used version 8.20.1 has a security vulnerability (see GHSA-96hv-2xvq-fx4p). The OpenSSF Score should improve after this PR has been merged.

@MacOS
MacOS requested review from Copilot and michalharakal July 28, 2026 11:04
@MacOS MacOS self-assigned this Jul 28, 2026
@MacOS MacOS added enhancement New feature or request dependencies Pull requests that update a dependency file infrastructure Build, publishing, tooling labels Jul 28, 2026

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copilot wasn't able to review any files in this pull request.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@MacOS
MacOS marked this pull request as draft July 28, 2026 12:49
michalharakal added a commit that referenced this pull request Jul 29, 2026
…ugins

First slice of #804. Two convention plugins land in build-logic/convention,
and three representative modules migrate to prove the shapes.

sk.ainet.multiplatform absorbs the Kotlin Multiplatform boilerplate that
every library module copies today: the target list, the android { } body,
explicitApi(), kotlin-test in commonTest, and the Karma hardening that was
duplicated as 23 byte-identical karma.config.d files. The single shared copy
now lives at gradle/karma.config.d/ and is wired in via
KotlinKarma.useConfigDirectory.

Which platforms a module builds comes from the skainet.targets Gradle
property rather than the skainet { } DSL. Targets must exist before the
module's own kotlin { } block runs -- the source-set convention accessors
create source sets on access, and KGP then refuses to attach a compilation
to one that already exists ("The compilation 'main' cannot be created after
the source set 'jvmMain'"). A DSL block is evaluated too late for that;
Gradle properties are readable while the plugin is applied. Everything
non-structural stays in skainet { }.

sk.ainet.npm-pins closes the Gradle/JS half of #847 and supersedes #894.
PR #894 tried to bump ws 8.20.1 -> 8.21.1 (GHSA-96hv-2xvq-fx4p) by editing
kotlin-js-store/wasm/yarn.lock, a generated file; kotlinWasmUpgradeYarnLock
put it straight back, leaving a zero-line diff. Declaring npm("ws", ...) in
a source set would not have worked either, since ws is transitive. The pin
is now one npm-ws line in libs.versions.toml, turned into a Yarn resolutions
entry in both the JS and Wasm root package.json files; verifyNpmPins reads
the committed lockfiles back and fails on drift.

Verified: ./gradlew :module:tasks --all is byte-identical before and after
for all three pilots; apiCheck passes with no new dumps; publishToMavenLocal
plus validate-published-poms.sh reports all 1131 POMs unchanged; both
lockfiles regenerate onto ws 8.21.1; verifyNpmPins passes and fails as
expected when a lockfile is tampered with; jsTest/wasmJsTest still receive
the Karma timeouts; ./gradlew build is green and reuses the config cache.

Progresses #804
Closes #847
Supersedes #894
@michalharakal

michalharakal commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

@MacOS, thank you for raising this — GHSA-96hv-2xvq-fx4p is now resolved on develop, so this PR has nothing left to merge.

Why this branch ended up empty

The two commits here cancel each other out (git diff develop...894 is empty): the first bumped ws to 8.21.1 by hand, and the second — after kotlinWasmUpgradeYarnLock — put it back to 8.20.1. That is the expected outcome: kotlin-js-store/**/yarn.lock is regenerated from the resolved dependency graph, so a manual edit to the lockfile can never survive a regeneration. ws is pulled in transitively, so it has to be constrained at the source.

How it was fixed

#900 added a sk.ainet.npm-pins convention plugin that forces npm versions onto both lockfiles via Yarn resolutions, which is the mechanism that actually constrains the graph:

  • gradle/libs.versions.tomlnpm-ws = "8.21.1" # GHSA-96hv-2xvq-fx4p
  • build.gradle.ktsskainet { npmPins { pin("ws", libs.versions.npm.ws) } }
  • kotlin-js-store/yarn.lock and kotlin-js-store/wasm/yarn.lockws resolves to version "8.21.1"
  • verifyNpmPins is wired into check and runs in CI (.github/workflows/build.yml), so the pin fails the build if a future lockfile regeneration drifts off it

To bump ws again in future, change the single version in gradle/libs.versions.toml and regenerate the lockfiles — no hand-editing needed.

Leaving this open for you to close.

@michalharakal

Copy link
Copy Markdown
Contributor

Closed as implemented with #900

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file enhancement New feature or request infrastructure Build, publishing, tooling

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants