ulidx: Cannot find crypto in Cloudflare Worker

When deploying a Cloudflare worker I get an error.

Error: Something went wrong with the request to Cloudflare...
Uncaught Error: No such module "crypto".
  at line 0
 [API code: 10021]

Somewhere in detectPRNG() it’s not finding that crypto is on globalThis in the Worker, so it is falling through to require("crypto") which doesn’t work in Cloudflare Workers. https://github.com/perry-mitchell/ulidx/blob/578a98bd642e1f0598f9d69cd5a4faf0b0eeeae8/source/ulid.ts#L63-L65

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 17 (12 by maintainers)

Most upvoted comments

New feature @ #13 for official support.

perry-mitchell on Jan 1, 2023

@bluet I’d accept a PR for that if you’re interested in documenting 😃

perry-mitchell on Dec 31, 2022

Thanks @grempe, I appreciate it. I’ll keep an eye on this. I suppose then advising people to use the monotonic factory only on workers is probably enough to ensure somewhat normal operation.

@perry-mitchell maybe need to update the README.md ?

bluet on Dec 30, 2022

I was referring to @ryan-mars repo issues which is why I tagged him in that line. 😁

@grempe Fixed, please add your issues. https://github.com/ryan-mars/ulid-workers/issues

ryan-mars on Jan 5, 2022

@perry-mitchell

Doesn’t this mean that, when generating ULIDs during that time period, the date-time portion will remain static?

Yes that is correct, which is why only monotonic factories should be used for generating date encoding id’s on Cloudflare Workers. Still this is not great in a distributed system for obvious reasons.

ryan-mars on Jan 2, 2022

I don’t agree with Cloudflare’s implementation of their basic JS APIs and therefore won’t be supporting Cloudflare workers.

And also your comment in this now closed PR: https://github.com/perry-mitchell/ulidx/pull/6#issuecomment-1003527627

While the application executes, time is locked in place. This sounds… absolutely terrible. I don’t understand why they’d choose to do this. All the same, I don’t know how this library is meant to work when time can’t be relied upon. It’s a crucial part of the algorithm.

and

but due to the time being irrelevant, somewhat, I wouldn’t ever advise anyone to use ulidx on them. Better to generate the IDs off-site on a proper server rather than try to generate them in such a broken environment.

If your concern was with how Cloudflare Workers handle time (time freezes at the time of the request), I would suggest you need to understand why they made that choice and why it was important (and should perhaps be emulated and not derided). This was done to help prevent side-channel attacks and Spectre style attacks. This page has a lot of additional context on security choices as well. Worker time can certainly be relied upon, it just reflects the start of the current request, not time changes during a request.

https://developers.cloudflare.com/workers/learning/security-model#step-1-disallow-timers-and-multi-threading

As a result they state:

In adversarial testing and with help from leading Spectre experts, Cloudflare has not been able to develop a remote timing attack that works in production.

As a worker is an instance of a V8 isolate, the time is only frozen for the duration of a request, which is typically a small number of ms of server time. New requests get the current time for that request. So not sure how this meaningfully impacts the generation of a ULID in a worker.

Some additional info that might help:

https://developers.cloudflare.com/workers/learning/how-workers-works https://blog.cloudflare.com/cloud-computing-without-containers/

grempe on Jan 1, 2022