Remove timestamp field from manifests

[matthewrsj]

Fixes #79

The timestamp field is not used and is a barrier to reproducible builds.
Remove the timestamp field from the manifests.

Signed-off-by: Matthew Johnson matthew.johnson@intel.com

[phmccarty]

Hmm, perhaps we could enable support for SOURCE_DATE_EPOCH instead? If that variable is set, we could assign the value to be the timestamps for every manifest.

[matthewrsj]

but what is the point? we never use that field.

[phmccarty]

The point is that a sysadmin can dig up manifests from an older build and see when those manifests were created -- timestamps embedded within a manifest are more trustworthy than their filesystem timestamps. It's for reference only, not something swupd-client would use.

[matthewrsj]

ok, that seems reasonable.

[phmccarty]

There was some offline discussion yesterday about the pros/cons of reproducible builds for swupd-server, and now I'm not convinced supporting SOURCE_DATE_EPOCH for manifests would be that valuable after all. At the same time, the timestamp field can be seen as valuable.

Often, if a DevOps team needs to go back to recreate a build, the purpose is to correct errors in the build, not to ensure that a bit-for-bit identical build can be produced. To validate that errors in fact were corrected in the later build, they could verify that the new manifests (and fullfile tars, etc) fixed the appropriate problems, that the manifests have newer timestamps, and are otherwise identical. With respect to reproducible builds, the team could check for identical content except for the timestamp fields; the timestamp field can provide better assurance that a new build was produced, and was reproducible, instead of bits from the original build being pulled in accidentally.

[matthewrsj]

Ok, so builds may not be 100% reproducible due to the changed timestamps, but since the goal is not bit-by-bit reproducibility, but rather correct errors in the builds, the timestamps can actually serve as an indicator that everything else was created the same way (if the timestamp changed, but nothing else did).

I can close this unless you want to have more discussion about it.

[phmccarty]

Ok, so builds may not be 100% reproducible due to the changed timestamps, but since the goal is not bit-by-bit reproducibility, but rather correct errors in the builds, the timestamps can actually serve as an indicator that everything else was created the same way (if the timestamp changed, but nothing else did).

Yes, I agree with the above.

I can close this unless you want to have more discussion about it.

Feel free to close :-)