Clean way to find out when a binary crate was compiled

So I have a crate dependency tree that looks approximately like this:

bin
  | -> main_lib
  | -> attribute_macro
  | -> ...

I’d like to find out when the bin crate is compiled, and i’d like to find out in bin itself.
Is there currently a clean way to do this?

I must say that I do not understand your question… I will try to give answers to possible questions.

  • If you want to know when the compilation process is run : you can find relevant information about the building process in the cargo manual and in the crate part of the Book.
  • If you want to be notified of a change in your binary : the solution will be platform-dependant (on Linux, for example, as far as I know, the best solution is to use inotify).

No what I meant is that I want the compiled binary to contain a timestamp indicating when it was compiled.
Apologies for the confusion.

There has to be a way to do so by generating a tiny module containing a timestamp const during build.rs, but I don’t know whether there is a cleaner one.

Indeed, that’s the way I’ve currently implemented it. But since it requires mucking about with the file system (in build.rs to store the timestamp and then somewhere in the src/ directory to read it back out):

  1. This solution is indeed rather kludgy, and
  2. I haven’t yet found a way to get this functionality into a separate crate that would purely deal with the question “when was the consuming crate compiled?”. This would make it easy to access such functionality without needing a lot of code in the consuming crate.

Now I realize that I haven’t mentioned 2. before but that’s because I figured I’d ask about the functionality in general first. Turns out the kludgy way seems (at least for now) the only way to do it.

We have a similar requirement for the code we will deploy to our AWS Lambda functions, so used vergen to have our binaries output the git commit short sha, commit date, and binary build date via log messages. VERGEN_BUILD_TIMESTAMP should do the trick.

As a general comment, this kind of thing is unlikely to be there and on by default for arbitrary crates. It used to be fairly common (long ago, pre-Rust) for compilers and linkers to jam a bunch of metadata about compile state, including host info and timestamps, into their output.

This is now generally considered undesirable, for a couple of reasons:

  • build reproducibility: given the same source (and the same toolchain version), I should be able to prove easily that the binary comes from the source - ie that it doesn’t include some other potentially-malicious tampered code.
  • privacy: this kind of metadata can leak various information that might be undesirable to publish for various users, who may be unaware that the tool includes it in the output. Same for tools like MS word, etc etc.

That doesn’t mean it’s not useful, nor even that the facility (or at least the standards for how to add such metadata in binary formats and linker sections) doesn’t already exist in the tools - just that it’s likely to be opt-in rather than enabled by default.

If you’re doing any code-signing in your build pipeline, that’s a common place to include this information, in current practices.

4 Likes

Build reproducibility is quite low on my list of priorities. Nor is privacy an issue.
I simply need the resulting binary (or library) to contain the date it was compiled on so that I can manipulate it, no more, no less.
That also means that a separate code signing step would be too late in the build/deployment process, since at that stage the binary to be signed has already been built.