just got bitten by the `colors` thing. is there a ...

# javascript

[Gabriel Duncan]

just got bitten by the colors thing. is there a way i can pin a version of a library that is included by a dependency indirectly through npm? i know in jvm lang you can force pin a transitive dependency but not sure that works for npm

[Gabriel Duncan]

https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

[Gabriel Duncan]

this is the colors thing i’m running into

[ephemient]

Kotlin/MPP and Kotlin/JS should already be creating a kotlin-js-store/yarn.lock since Kotlin 1.6.10

[Gabriel Duncan]

hi thanks. where is that supposed to show up? i just upgraded and don’t see that directory/file showing up after gradle import

[ephemient]

should be in the project root, after JS dependencies are resolved once

[Gabriel Duncan]

hmmm. not working. i have a monorepo multi-module setup. i wonder if that could be an issue?

[Gabriel Duncan]

i see a package-lock.json

[Gabriel Duncan]

i just upgraded kotlin to 1.6.10 and ran gradle import

[ephemient]

https://github.com/JetBrains/kotlin/commit/a03f34629653c058ad8ce7690449b4a664a1fb7d I suppose you could try running ./gradlew :kotlinStoreYarnLock, but it's supposed to be automatic unless you somehow disabled it

[ephemient]

it's basically https://blog.jetbrains.com/kotlin/2021/10/control-over-npm-dependencies-in-kotlin-js/ in built-in form

[Gabriel Duncan]

thanks. the only tasks i disabled are these:

startParameter.excludedTaskNames += setOf(
    ":customer-portal-app:compileTestDevelopmentExecutableKotlinJs",
    ":customer-portal-app:compileTestProductionExecutableKotlinJs"
)

[Gabriel Duncan]

they were throwing errors in our ci/cd env

[Oliver.O]

This is my analysis on persisting yarn.lock in Kotlin 1.6.10:

Kotlin 1.6.10 introduces a feature "Gradle, JS: Ability to persist / reuse yarn.lock" (KT-34014), which works like this:
Each invocation of the kotlinNpmInstall task effectively
• invokes the kotlinRestoreYarnLock task, copying kotlin-js-store/yarn.lock to build/js/yarn.lock, if the former exists.
• installs Npm packages,
• invokes the kotlinStoreYarnLock task, creating or updating kotlin-js-store/yarn.lock.
The intention is to track kotlin-js-store/yarn.lock in a VCS to enable stable builds and discover differences.
Effects on Introducing Malicious Code
The feature will
1. ❌ block implicit Npm package version upgrades as long as no new dependencies are introduced,
2. ❌ block the execution of install scripts by default,
3. ✅ install newly declared dependencies, including their transitive dependencies.
◦ 💀 This can install malicious code.
So while the feature can ensure stable builds, it will update the stored version of yarn.lock without asking. For a more robust implementation, which actually blocks running unchecked JS code, see this implementation. It is based on 1.5.31 and no longer current, but you might get the idea.

[ephemient]

1.6.10 also disables install scripts by default, so the problem of malicious code is… at least postponed until you run the code instead of just building it

[Oliver.O]

Not entirely: Webpack, the Karma test runner, and others operate during the build stage. And these do not run in a browser's sandbox, but in a full Node environment, with full (dev) user privileges. Last October, it was a Karma transitive dependency. That time, malicious code was residing in the install script only, but this is almost guaranteed to change at some point.

[ephemient]

running Karma is running the code, not just building it, as far as I'm concerned, but I can see the point in that it is executed by the "./gradlew build" task

[Oliver.O]

Yep, I should have clarified that it depends on what's considered part of the build process.

[Gabriel Duncan]

@Oliver.O thanks for sharing that