Bugzilla

Hi Dana, in this bug I am implementing a new [`crypto.randomUUID()` Web API]( https://wicg.github.io/uuid/) that Chrome has shipped. In comment 3, Martin recommended that UUID generation (`nsUUIDGenerator`) use NSS's CSRNG (via `nsRandomGenerator` like `crypto.getRandomValues()` does). `nsUUIDGenerator` currently uses the OS's UUID APIs on Windows and macOS, but falls back to the standard C library's weak `random()` on Linux.

Unfortunately, changing `nsUUIDGenerator` to use `nsRandomGenerator` is not straightforward because `nsUUIDGenerator` is called very early during Firefox startup, before NSS is initialized. Calling `nsRandomGenerator` during early startup _does_ return random data, but it causes NSS to quietly auto-initialize in "nocertdb" mode which causes hard to debug test failures.

Do you like any of these alternatives?

1. Change `nsUUIDGenerator` to use the OS's strong RNG (e.g. `/dev/urandom`, `arc4random()`, etc via [MFBT's RandomNum code](https://searchfox.org/mozilla-central/rev/00be3c92c269d789663791cf518161d0f47c9b96/mfbt/RandomNum.cpp#97)). This is similar to the patches in bug 1700675 (r+'d but never landed) to work around a different problem.
2. Change `nsUUIDGenerator` to use the OS's RNG during early startup and `nsRandomGenerator` after NSS has been initialized.
3. Change `nsUUIDGenerator` to use `nsRandomGenerator`, but change `nsRandomGenerator` to use the OS's RNG during early startup and NSS after it has been initialized.
4. None of the above: use some other option or don't implement `crypt.randomUUID()` at all.

I like #3 because it would make `nsRandomGenerator` available during early startup, but still prefer NSS when it's available. You might not like #3 if you intend `nsRandomGenerator` to strictly be a wrapper around NSS's CSRNG.

Hi Dana, in this bug I am implementing a new [`crypto.randomUUID()` Web API]( https://wicg.github.io/uuid/) that Chrome has shipped. In comment 3, Martin recommended that UUID generation (`nsUUIDGenerator`) use NSS's CSRNG (via `nsRandomGenerator` like `crypto.getRandomValues()` does). `nsUUIDGenerator` currently uses the OS's UUID APIs on Windows and macOS, but falls back to the standard C library's weak `random()` on Linux.

Unfortunately, changing `nsUUIDGenerator` to use `nsRandomGenerator` is not straightforward because `nsUUIDGenerator` is called very early during Firefox startup, before NSS is initialized. Calling `nsRandomGenerator` during early startup _does_ return random data, but it causes NSS to quietly auto-initialize in "nocertdb" mode which causes hard to debug test failures.

Do you like any of these alternatives?

1. Change `nsUUIDGenerator` to use the OS's strong RNG (e.g. `/dev/urandom`, `arc4random()`, etc via [MFBT's RandomNum code](https://searchfox.org/mozilla-central/rev/00be3c92c269d789663791cf518161d0f47c9b96/mfbt/RandomNum.cpp#97)). This is similar to the patches in bug 1700675 (r+'d but never landed) to work around a different problem.
2. Change `nsUUIDGenerator` to use the OS's RNG during early startup and `nsRandomGenerator` after NSS has been initialized.
3. Change `nsUUIDGenerator` to use `nsRandomGenerator`, but change `nsRandomGenerator` to use the OS's RNG during early startup and NSS after it has been initialized.
4. None of the above: use some other option or don't implement `crypt.randomUUID()` at all.

I like #3 because it would make `nsRandomGenerator` available during early startup, but still use NSS when it's available. You might not like #3 if you intend `nsRandomGenerator` to strictly be a wrapper around NSS's CSRNG.