Use v4 instead of v1 uuids#10871
Conversation
no issue v1 UUID are based on current time and the hardware MAC address of the machine where they are being generated. As such they have much more complex semantics than v4 UUIDs which are simply randomly generated. Unless there's a specific requirement for the special semantics of v1 UUIDs it is simpler and less error prone to simply go for v4 UUIDs whenever just a unique identifier is needed.
no issue v1 UUID are based on current time and the hardware MAC address of the machine where they are being generated. As such they have much more complex semantics than v4 UUIDs which are simply randomly generated. Unless there's a specific requirement for the special semantics of v1 UUIDs it is simpler and less error prone to simply go for v4 UUIDs whenever just a unique identifier is needed.
no issue v1 UUID are based on current time and the hardware MAC address of the machine where they are being generated. As such they have much more complex semantics than v4 UUIDs which are simply randomly generated. Unless there's a specific requirement for the special semantics of v1 UUIDs it is simpler and less error prone to simply go for v4 UUIDs whenever just a unique identifier is needed.
|
Hey @ctavan thanks for the contribution 💃 !! These changes look great to me, and especially for the However - I'd like to confirm with @ErisDS or @cobbspur before this goes in |
|
This change seems fine/sensible to me but the change to the request middleware needs to be considered / remembered with regard to the upcoming logging project :) |
|
Thanks for the quick feedback!
@allouis don't worry, also with v1 UUIDs you have pretty strong guarantees that they are unique. At least the UUID RFC contains the necessary safeguards. In the particular case of the That said, the semantics for generating v1 UUIDs are still much more complex and bad implementations or wrong usage of correct implementations can lead to various sorts of trouble. So if the specific features of v1 UUIDs are not needed, I think it is always the better choice to just go for v4 UUIDs where all you really rely on is a good random number generator (and with the So if it's really only about a unique identifier, then v4 is definitely the way to go!
@ErisDS can you elaborate a bit what the effects of the change in the request middleware will be with respect to the future work you are planning? Also @allouis, @ErisDS, @cobbspur is anyone of you aware of why v1 UUIDs were chosen in the initial implementation in the three cases? I'm really interested in understanding the reasons why developers choose v1 UUIDs over v4 when they use the |
|
@ErisDS can you elaborate a bit what the effects of the change in the request middleware will be with respect to the future work you are planning? Nothing serious, we plan to move the middleware to ignition. RE: remembering why the choice was made, your best bet would be git blame / issue search. It was ~6 years ago. |
|
OK, thanks @ErisDS!
@allouis @ErisDS anything I can improve on this PR to get this merged? |
|
@ctavan nope! just slipped - this is great! thank you 💃 |
* master: (24 commits) Version bump to 2.25.7 Updated Ghost-Admin to 2.25.7 Update default 404 page Update dependency markdown-it to v9 💡 Bumped minimum node v8.x version to v8.10.0 Update dependency knex to v0.19.0 Update dependency brute-knex to v4 Update dependency intl-messageformat to v5 Update dependency probe-image-size to v4.1.1 🐛 Allowed administrators to change other users' passwords (#10891) 🐛 Fixed error message when get helper doesn't have API access (#10892) Update dependency intl-messageformat to v4.4.0 Fixed typo in readme (#10885) Replaced v1 for v4 uuids (#10871) Update dependency probe-image-size to v4.0.1 Update dependency mock-knex to v0.4.6 Update dependency markdown-it-footnote to v3.0.2 Update dependency lodash to v4.17.14 Update dependency gscan to v2.6.3 Update dependency ajv to v6.10.2 ...
3 participants
I'm a co-author of the uuid npm module which is being used in some places within the code base of Ghost.
I'm currently trying to understand real-world use cases of time-based UUIDs ("v1 UUIDs").
I found three occurrences where v1 UUIDs were being used instead of v4 UUIDs and I was wondering if any of these cases really require the semantically much more complex v1 UUIDs or whether we could live equally well with purely random v4 UUIDs?
At least the test suite still passes after my changes, so apparently this doesn't seem to introduce any known regressions.
I'd be really curious to understand the motivation for choosing v1 over v4 UUIDs in the first place, so any feedback on this would be highly appreciated!