machine-uid

machine-uid is a small Rust crate for reading a unique, OS-native machine identifier without requiring root or administrator privileges. It exposes a single machine_uid::get() function that reads the appropriate platform source — systemd’s machine-id on Linux, /etc/hostid or kenv on BSD, gethostuuid(3) on macOS, the MachineGuid registry key on Windows, and gethostid(3C) on illumos.

Because it normalizes these disparate platform mechanisms behind one API, it’s commonly used for license binding, device fingerprinting, telemetry deduplication, and any scenario needing a stable per-machine identifier across supported operating systems.

What You Get

• A single machine_uid::get() -> Result<String> function usable across Linux, BSD, macOS, Windows, and illumos
• Linux/systemd support via /var/lib/dbus/machine-id or /etc/machine-id
• BSD support via /etc/hostid or kenv -q smbios.system.uuid
• macOS support via the native gethostuuid(3) syscall (no shelling out to ioreg)
• Windows support via the registry MachineGuid key, and illumos support via gethostid(3C)

Common Use Cases

• Binding a software license or activation key to a specific machine
• Generating a stable per-device identifier for telemetry or analytics deduplication
• Device fingerprinting for fraud detection or session anomaly checks
• Distinguishing machines in fleet-management or configuration-management tooling

Under The Hood

Architecture - The entire crate lives in a single src/lib.rs, organized as a get() entry point that dispatches via #[cfg(...)] conditional compilation to one of several platform-specific implementations bundled in the same file: reading /etc/machine-id on Linux, shelling out to or reading files for BSD, calling gethostuuid(3) directly on macOS (a recent change replacing a prior ioreg subprocess call), querying the Windows registry via windows-registry/windows-sys, and calling gethostid(3C) on illumos via libc. Platform selection happens entirely at compile time, so the compiled binary only contains the code path for its target OS.

Tech Stack - Pure Rust with target-conditional dependencies: windows-sys and windows-registry only pulled in for Windows builds, and libc only for macOS/illumos builds — Linux and BSD builds have zero external dependencies. The crate has moved away from a bundled C dependency and bindgen in recent releases in favor of native windows-registry bindings, reducing build complexity.

Code Quality - Test coverage lives in tests/tests.rs plus a tests/platform/ directory, exercising the platform-specific code paths. The crate has an active changelog documenting incremental fixes (cross-compilation issues, x86-on-x64 handling, dependency upgrades) tracked over 9 releases since 2018, indicating a maintainer who responds to real-world platform edge cases as they surface via GitHub Actions CI.

API Design - The public API is a single function, get(), returning a Result<String> — there is no configuration surface, builder, or platform-selection argument required from the caller. Getting started is a one-line call with no setup, and the crate’s doc comments and README both walk through the exact platform source used on each OS for transparency.