You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by ocket 8888 <oc...@gmail.com> on 2019/09/23 16:10:47 UTC
New dependency: UUID
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.
Re: New dependency: UUID
Posted by ocket 8888 <oc...@gmail.com>.
yeah, that doesn't seem too hard
On Mon, Sep 23, 2019 at 11:10 AM Robert Butts <ro...@apache.org> 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 <oc...@gmail.com> 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 <ro...@apache.org> 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 <da...@gmail.com>
> 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 <oc...@gmail.com>
> > 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.
> > > > >
> > > >
> > >
> >
>
Re: New dependency: UUID
Posted by Robert Butts <ro...@apache.org>.
>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 <oc...@gmail.com> 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 <ro...@apache.org> 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 <da...@gmail.com> 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 <oc...@gmail.com>
> 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.
> > > >
> > >
> >
>
Re: New dependency: UUID
Posted by ocket 8888 <oc...@gmail.com>.
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 <ro...@apache.org> 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 <da...@gmail.com> 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 <oc...@gmail.com> 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.
> > >
> >
>
Re: New dependency: UUID
Posted by Robert Butts <ro...@apache.org>.
-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 <da...@gmail.com> 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 <oc...@gmail.com> 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.
> >
>
Re: New dependency: UUID
Posted by Dan Kirkwood <da...@gmail.com>.
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 <oc...@gmail.com> 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.
>