Add support for custom Hardware (MAC) Addresses #41
Labels
enhancement
New feature or request
Milestone
Comments
theckman
added a commit
that referenced
this issue
Jul 28, 2018
This change exposes the reference UUID generator in the package, so that consumers can create a new instance and make use of it. This is being done so that consumers can provide their own Hardware Address generation function, in case they want to randomize the MAC address as to not expose it. This works by now exposing the `rfc4122Generator` type as `Gen`, and adding constructor functions that scaffold the generator appropriately. The tests were also enhanced to confirm that the `HWAddrFunc` we provide is indeed being invoked. Fixes #41 Signed-off-by: Tim Heckman <t@heckman.io>
theckman
added a commit
that referenced
this issue
Jul 29, 2018
This change exposes the reference UUID generator in the package, so that consumers can create a new instance and make use of it. This is being done so that consumers can provide their own Hardware Address generation function, in case they want to randomize the MAC address as to not expose it. This works by now exposing the `rfc4122Generator` type as `Gen`, and adding constructor functions that scaffold the generator appropriately. The tests were also enhanced to confirm that the `HWAddrFunc` we provide is indeed being invoked. Fixes #41 Signed-off-by: Tim Heckman <t@heckman.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some consumers of this package may want to generate
V1UUIDs without exposing their physical device's hardware address to consumers of that UUID. We should look at exposing this functionality in some capacity for consumers.See the issue on the original repo for more details (satori/go.uuid#64).
/cc @alessandrozucca
It seems like exposing the generator itself, and allowing people to provide their own HWAddr function should support most of what's needed here.
The text was updated successfully, but these errors were encountered: