-
Notifications
You must be signed in to change notification settings - Fork 398
Description
I'm specifically referencing this section of code:
scala-js/javalib/src/main/scala/java/util/UUID.scala
Lines 139 to 147 in 058532a
private lazy val rng = new Random() // TODO Use java.security.SecureRandom | |
def randomUUID(): UUID = { | |
val i1 = rng.nextInt() | |
val i2 = (rng.nextInt() & ~0x0000f000) | 0x00004000 | |
val i3 = (rng.nextInt() & ~0xc0000000) | 0x80000000 | |
val i4 = rng.nextInt() | |
new UUID(i1, i2, i3, i4, null, null) | |
} |
The Java 8 docs for UUID.randomUUID()
state:
Static factory to retrieve a type 4 (pseudo randomly generated) UUID. The UUID is generated using a cryptographically strong pseudo random number generator.
Furthermore, https://github.com/tc39/proposal-uuid states that:
Developers who have not been exposed to RFC 4122 might naturally opt to invent their own approaches
to UUID generation, potentially usingMath.random()
(in TIFU by usingMath.random()
there's an in-depth discussion of why a Cryptographically-Secure-Pseudo-Random-Number-Generator
(CSPRNG) should be used when generating UUIDs).
It's unclear to me how a developer cross-compiling their library or application for Scala.js should become aware that in fact they cannot rely on UUID.randomUUID()
for cryptographically strong UUIDs.
This seems a lot like a CVE to me.
See also discussion in typelevel/cats-effect#2882 (comment).
PS would be good to set up a security policy at https://github.com/scala-js/scala-js/security.