Skip to content

Fix nix reproducible build#6

Merged
cfradewavecom merged 1 commit intowavecomtech:mainfrom
dvcorreia:nix/reproducible-builds
Jun 27, 2025
Merged

Fix nix reproducible build#6
cfradewavecom merged 1 commit intowavecomtech:mainfrom
dvcorreia:nix/reproducible-builds

Conversation

@dvcorreia
Copy link
Contributor

@dvcorreia dvcorreia commented Jun 19, 2025

Having the build date on the binary makes the omlox-cli binary not reproducible.

This removes the build date and adds the nix derivation and overlay for omlox-cli.

Other things to note:

  • copywrite is now available in the upstream nixpkgs, so is was removed
  • dependency on numtide/flake-utils was dropped

@dvcorreia dvcorreia force-pushed the nix/reproducible-builds branch 2 times, most recently from 05f05ba to 9b5b799 Compare June 19, 2025 23:48
@cfradewavecom
Copy link
Contributor

BUILD_DATE exists so anyone can identify wrongly or by mistake local changes where made, COMMIT_HASH is not enough. Is there another valid reason to justify this change?

@cfradewavecom cfradewavecom self-requested a review June 24, 2025 12:50
@dvcorreia
Copy link
Contributor Author

dvcorreia commented Jun 24, 2025

BUILD_DATE exists so anyone can identify wrongly or by mistake local changes where made, COMMIT_HASH is not enough. Is there another valid reason to justify this change?

You're right that having some form of date information is useful. However, BUILD_DATE doesn't actually tell us about code changes, only when it was compiled. If you'd like to keep some kind of date information, I'd suggest using the commit date instead, which provides the same benefit while maintaining reproducibility since it doesn't change between builds of the same commit.

nix build already introduces a dirty flag if the git state is dirty.

> nix build
warning: Git tree '/Users/dvcorreia/Desktop/projects/omlox-client-go' is dirty
> ./result/bin/omlox-cli version
omlox version 9b5b799-dirty (9b5b799bbdcf56c435738c3f357305d1763b812a-dirty)

If this help avoid confusion introduced by local changes, wouldn't be hard to extend this concept to the Makefile.

On the topic of reproducible builds, they have several benefits.
I would say that the most important in this case is verifying that the binaries you download match the original, untampered source code.

This verification extends beyond Nix. A good example is OCI images, where we can specify a content digest to make the image verifiable, avoiding some supply chain attack vectors. If the binary isn't reproducible, we can't ensure the image wasn't tampered with, since every build changes the digest.

It's not a critical issue, but it's a valuable property that improves security and developer experience. Being able to install things through Nix without these concerns provides a better experience for users trying omlox-cli.

@dvcorreia dvcorreia force-pushed the nix/reproducible-builds branch from 9b5b799 to 974a670 Compare June 25, 2025 08:02
Copy link
Contributor

@cfradewavecom cfradewavecom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@cfradewavecom cfradewavecom merged commit 9d8e2a7 into wavecomtech:main Jun 27, 2025
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants