Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: We just had an actual UUID v4 collision...

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 369 posts

Re: Ask HN: We just had an actual UUID v4 collision...

#271

Post by halfcat »

CodeWriter23 wrote: post #156
throwaway_19sz wrote: post #50

Funny story no one will believe, but it’s true. A good friend of mine joined a startup as CTO 10 years ago, high growth phase, maybe 200 devs… In his first week he discovered the company had a microservice for generating new UUIDs. One endpoint with its own dedicated team of 3 engineers …including a database guy (the plot thickens). Other teams were instructed to call this service every time they needed a new ‘safe’…

I get the microservice to ensure this. But 3 people dedicated to it? I guarantee you they spent their days trudging dungeons, playing CoD and ping pong.

You need at least 3 for this. People go on vacation, turnover, can’t risk losing that critical institutional knowledge.

Re: Ask HN: We just had an actual UUID v4 collision...

#272

Post by halfcat »

Schiendelman wrote: post #187
morkalork wrote: post #129

Earlier quoted context omitted.

I too have witnessed a "add two numbers" service! Turns out you can be too extreme with rules for isolating out business logic..

Same! It had validation on each number before adding them. Poor design, but that's how it worked.

[dead]

Re: Ask HN: We just had an actual UUID v4 collision...

#273

Post by squirrellous »

erikerikson wrote: post #194
jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

Super simple to detect and try again.

In this specific case. In the case of trace IDs (an example of which is [1]) where the equivalent of UUIDs are explicitly used to avoid coordination, it’s hard to imagine how you’d reliably detect and retry.

[1] https://news.ycombinator.com/item?id=48033853

Re: Ask HN: We just had an actual UUID v4 collision...

#274

Post by wpm »

BSVogler wrote: post #181
euroderf wrote: post #177

Earlier quoted context omitted.

Ant farm ? Hamster wheels ? Anything critter-driven should provide some entropy.

I once read that noise of camera in total darkness is apparently a good source.

Would a CRT TV tuned to channel 3 and no RF input be a good source?

Re: Ask HN: We just had an actual UUID v4 collision...

#277

Post by erikerikson »

squirrellous wrote: post #273
erikerikson wrote: post #194

Earlier quoted context omitted.

Super simple to detect and try again.

In this specific case. In the case of trace IDs (an example of which is [1]) where the equivalent of UUIDs are explicitly used to avoid coordination, it’s hard to imagine how you’d reliably detect and retry. [1] https://news.ycombinator.com/item?id=48033853

A lot of databases have a uniqueness constraint that is basically a register level compare and replace. Others have a if_not_exists which is nearly the same. If you're not targeting a serious throughput use case, it's enough. If you are then there are lots of solutions/alternatives that completely avoid coordination. On the other hand, maybe tracing protocols are robust to out of order delivery. If that won't do them sequence numbers tied to monotonic sequence IDs should be plenty. If not then I'd need very serious conversations to be convinced you're not wasting everyone's time

Re: Ask HN: We just had an actual UUID v4 collision...

#278

Post by adonovan »

jandrewrogers wrote: post #95

This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…

For a while we’ve been fixing telemetry-reported crash bugs in the project I maintain, and now hardware bugs are showing up with some frequency. I was amazed how common they are. Sometimes data values (e.g. SP register) are corrupted, but other times even infallible operations (e.g loads of rodata constants) crash, indicating that the instruction itself was corrupted. So, yeah, I believe you’ll eventually see UUID collisions, but not because the underlying cryptanalysis was wrong.

Re: Ask HN: We just had an actual UUID v4 collision...

#279

Post by chefpump »

throwaway_19sz wrote: post #50

Funny story no one will believe, but it’s true. A good friend of mine joined a startup as CTO 10 years ago, high growth phase, maybe 200 devs… In his first week he discovered the company had a microservice for generating new UUIDs. One endpoint with its own dedicated team of 3 engineers …including a database guy (the plot thickens). Other teams were instructed to call this service every time they needed a new ‘safe’…

Any chance this company managed cap tables?

Re: Ask HN: We just had an actual UUID v4 collision...

#280

Post by dalmo3 »

mega_dean wrote: post #255
_kst_ wrote: post #186

This reminds me of a passage from the book "Pro Git". https://git-scm.com/book/en/v2 > "Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (6.5 million Git objects) and pushing it into one enormous Git repository, it would take…

Reminds me of this page with an example for understanding how many permutations there are for a shuffled deck of cards: https://czep.net/weblog/52cards.html > So, just how large is it? Let's try to wrap our puny human brains around the magnitude of this number with a fun little theoretical exercise. Start a timer that will count down the number of seconds from 52! to 0. We're going to see how much fun we can have bef…

Damn, I got the paper stack wet with all that ocean water. Guess I'm starting again from scratch...
Post reply on HN