Announcing Scala.js 1.10.0
Apr 4, 2022.
We are pleased to announce the release of Scala.js 1.10.0!
This release addresses a security vulnerability in
All versions of Scala.js prior to 1.10.0 are affected, including all 0.6.x versions.
We strongly recommend that all users upgrade to Scala.js 1.10.0 as soon as possible.
Read the security advisory for more details.
The issue was registered as CVE-2022-28355.
This release also brings a new mode of module splitting, which creates the smallest possible modules for a given list of packages, and the fewest possible modules for the rest.
Finally, it contains some minor optimizations, notably contributed by @japgolly.
Read on for more details.
If you are new to Scala.js, head over to the tutorial.
Bug reports can be filed on GitHub.
If upgrading from Scala.js 0.6.x, make sure to read the release notes of Scala.js 1.0.0 first, as they contain a host of important information, including breaking changes.
This is a minor release:
- It is backward binary compatible with all earlier versions in the 1.x series: libraries compiled with 1.0.x through 1.9.x can be used with 1.10.0 without change.
- Despite being a minor release, 1.10.0 is forward binary compatible with 1.8.x and 1.9.x. It is not forward binary compatible with 1.7.x. Libraries compiled with 1.10.0 can be used with 1.8.x and 1.9.x but not with 1.7.x or earlier.
- It is not entirely backward source compatible: it is not guaranteed that a codebase will compile as is when upgrading from 1.9.x (in particular in the presence of
As a reminder, libraries compiled with 0.6.x cannot be used with Scala.js 1.x; they must be republished with 1.x first.
Fixes with compatibility concerns
java.util.UUID.randomUUID() now depends on
java.security.SecureRandom, which is provided by external libraries
Until Scala.js 1.9.x,
java.util.UUID.randomUUID() was implemented using
java.util.Random, which is not cryptographically secure.
This is therefore a security issue concerning
To address that, Scala.js 1.10.x uses
java.security.SecureRandom in the implementation of the latter instead.
java.util.Random remains unchanged, since it correctly implements its (deterministic) specification.
While it can be implemented on top of browser APIs or Node.js APIs, we have no decent fallback for other cases.
Not fully implementing it correctly for all platforms would go against our policy for the standard library, i.e., that linking code must be correct.
Therefore, Scala.js core does not provide any implementation of
This means that code that was previously calling
java.util.UUID.randomUUID() will now fail to link.
To preserve binary compatibility, we introduce two variants of a library that provides
scalajs-java-securerandomprovides a correct, cryptographically secure implementation of
java.security.SecureRandom, but relies on the Node.js
cryptomodule or the Web Crypto API
crypto.getRandomValuesto be available (e.g., in browsers).
scalajs-fake-insecure-java-securerandomis a fake, insecure implementation that works in any ECMAScript environment. The only reason this exists is to unblock migration from Scala.js 1.9.x and earlier, in situations that require
randomUUID()and can accept that they will be insecure.
Due to the changes in the core library, you may encounter linking errors when upgrading to Scala.js 1.10.0, such as:
You may fix these linking errors by adding the following dependency to your
As mentioned above, this will only work in environments that either provide the Web Crypto API, or Node.js’
If you need random UUID generation in other environments, we encourage you to implement it yourselves.
Find out if your environment provides a source of cryptographically secure pseudo-random numbers.
If it does, you may want to use it to shim
crypto.getRandomValues, and/or send a pull request to
Otherwise, replace calls to
randomUUID() with another implementation, in a way that corresponds to your requirements in terms of security and collision likelihood.
If you have no other choice, depend on
As its name implies, this is an insecure implementation, and you should get rid of this dependency as soon as possible.
New module split style:
Prior to 1.10.0, Scala.js had two opposite module split styles:
FewestModules(the default), which generates as few modules as possible, and
SmallestModules, which generates as many small modules as possible (up to one per class).
As detailed in #4327, those two extremes both suffered from issues for iterative development.
Scala.js 1.10.0 introduces a third style,
That style creates as many small modules as possibles for the classes in the listed packages (and their subpackages).
For all other classes, it generates as few modules as possible.
It is a combination of the previously existing styles.
The typical usage pattern is to list the application’s packages as argument.
This way, often-changing classes receive independent, small modules, while the stable classes coming from libraries are bundled together as much as possible.
For example, if your application code lives in
com.example.myapp, you could configure your module split style as:
- Closures that do not need to capture anything produce simple lambdas, instead of redundant IIFEs (Immediately Invoked Function Expressions); contributed by @japgolly
js.dynamicImportblocks that do nothing but access a native JS class, object or member from a JS module avoid creating an intermediate Scala.js-generated module; instead they directly refer to the target JS module in the generated dynamic
Among others, the following bugs have been fixed in 1.10.0:
- #4657 Scala.js should not provide a cryptographically insecure
You can find the full list on GitHub.