yeah, that doesn't seem too hard On Mon, Sep 23, 2019 at 11:10 AM Robert Butts <[email protected]> wrote:
> >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. > > > > > > > > > > > > > > >
