>Which doesn't _require_ the use of a MAC address, though it does specify how one can be used.
Right, that's the difference in a V1 and V4 UUID: https://tools.ietf.org/html/rfc4122#section-4.1.6 "For UUID version 1, the node field consists of an IEEE 802 MAC address." >Specifically, you need to set timestamp, version and variant information. Sort of. The RFC is a little deceptive. For a V4 UUID: https://tools.ietf.org/html/rfc4122#section-4.4 """ Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively. Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the 4-bit version number from Section 4.1.3. Set all the other bits to randomly (or pseudo-randomly) chosen values. """ So the "time" field isn't actually a time, for V4 UUIDs. >That's not true, a fully randomly generated byte sequence like that doesn't conform to https://tools.ietf.org/html/rfc4122 But yes, you're correct, a fully random 16 bytes isn't technically conformant. In my experience, it's common to do it anyway and call it a "V4 GUID," because as you say, "who cares?" Personally, I don't think it's useful. But if you do, it's still just two more lines: uuid[6] = (uuid[6] & 0x0f) | 0x40 uuid[8] = (uuid[8] & 0x3f) | 0x80 But again, I don't mean to nitpick. I'm -0, not -1, if you feel it's more logic than it's worth writing. If you do avoid the library, can I suggest putting the func in lib/go-util? On Mon, Sep 23, 2019 at 10:37 AM ocket 8888 <[email protected]> wrote: > That's not true, a fully randomly generated byte sequence like that doesn't > conform to https://tools.ietf.org/html/rfc4122 . Which doesn't _require_ > the use of a MAC address, though it does specify how one can be used. > Specifically, you need to set timestamp, version and variant information. > A fair question, though, would be "who cares?" Is conformance with that RFC > important? I suppose I never really thought about it. We don't use any of > that information, so why bother doing it? Idk, do you think that could be > useful? Or just unnecessary? > > On Mon, Sep 23, 2019 at 10:24 AM Robert Butts <[email protected]> wrote: > > > -0 > > > > Not a big deal, the library seems small and stable enough, and the > license > > is fine. But is it really necessary? Generating a V4 GUID is as simple > as: > > > > uuid := make([]byte, 16) > > _, err := rand.Read(uuid) > > > > Do we need V1 GUIDs? IMO we should never be generating V1 GUIDs, unless > > they're absolutely necessary for something like backwards compatibility. > > They include the user's MAC and can be a security concern. > > > > If not, is it really worth pulling in a library for 2 lines? > > > > > > On Mon, Sep 23, 2019 at 10:17 AM Dan Kirkwood <[email protected]> wrote: > > > > > Yes -- BSD-3 is a category A license: > > > > > > https://apache.org/legal/resolved.html#category-a > > > > > > On Mon, Sep 23, 2019 at 10:11 AM ocket 8888 <[email protected]> > wrote: > > > > > > > For rewriting the /user/reset_password endpoint (PR #3932) I was > > > importing > > > > the github.com/google/uuid library for generating UUIDs used as > > > temporary > > > > login tokens. That's backward-compatible with Perl (for all that > > > matters). > > > > The repo is licensed under BSD-3 which I think is Apache-compatible, > > but > > > I > > > > think bringing that to the attention of the mailing list is standard > > > > procedure. > > > > > > > > > >
