Athens uses github.com/gobuffalo/uuid for the generation of UUID's.
The generated uuid's are used for example, when saving a module in storage[1]
github.com/gobuffalo/uuid which is a fork of https://github.com/satori/go.uuid is vulnerable to a bug where it can generate Non-Random UUID's with collissions.
I'm guessing we wouldn't want to, for example try to store different modules using the same uuid[2]
There's already a tracking issue in github.com/gobuffalo/uuid[3] and a parent one in github.com/satori/go.uuid [4]
The buggy code in github.com/gobuffalo/uuid seems to be[5]
The fix would be[6]
I have opened this issue as a tracking issue of the upstream bug in https://github.com/gobuffalo/uuid
ref:
sent PR to buffalo; https://github.com/gobuffalo/uuid/pull/2
@komuw thanks! Is there anything you think we should do right now in our repo?
Also, depending on how this discussion goes, we might be removing the RDBMS drivers, which would remove a lot of our UUID usage, fyi.
@arschles hi.
I do not know if there's something we can do right now, short of moving to another uuid package that doesn't have this bug.
I think we can track https://github.com/gobuffalo/uuid/pull/2 for the next few days and see how it goes; I think @markbates is the lead dev on that project and he's also(I think) the lead organiser of GopherconUK which was this week so he may not have had time to look at the PR. I'll give him a few days, then I'll ping him on the PR
I'll also track https://github.com/gomods/athens/issues/383 since from that we may not need uuid's. Although I think gobuffalo itself also uses /github.com/gobuffalo/uuid so it would be ideal if the package got patched.
Most helpful comment
sent PR to buffalo; https://github.com/gobuffalo/uuid/pull/2