New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not include date in binaries #6581

Merged
merged 1 commit into from Nov 18, 2017

Conversation

Projects
None yet
5 participants
@bmwiedemann
Contributor

bmwiedemann commented Oct 24, 2017

and do not claim copyright for 2018
in order to make nim package builds reproducible.

See https://reproducible-builds.org/ for why this is good.

An alternative approach would be to implement using
SOURCE_DATE_EPOCH
for CompileDate and CompileTime

Do not include date in binaries
and do not claim copyright for 2018
in order to make nim package builds reproducible.

See https://reproducible-builds.org/ for why this is good.
@Araq

This comment has been minimized.

Show comment
Hide comment
@Araq

Araq Oct 24, 2017

Member

Having to update the year every year manually is worse than the current solution.

Member

Araq commented Oct 24, 2017

Having to update the year every year manually is worse than the current solution.

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 24, 2017

Contributor

Is there a way to have the const copyrightYear = "2017" in one place and change all users to use it from there?
Then the script that builds a release tarball could also update that file.

Contributor

bmwiedemann commented Oct 24, 2017

Is there a way to have the const copyrightYear = "2017" in one place and change all users to use it from there?
Then the script that builds a release tarball could also update that file.

@Araq

This comment has been minimized.

Show comment
Hide comment
@Araq

Araq Oct 24, 2017

Member

What's the point anyway, diff the binary files with a tool slightly smarter than memcmp.

Member

Araq commented Oct 24, 2017

What's the point anyway, diff the binary files with a tool slightly smarter than memcmp.

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 25, 2017

Contributor

In openSUSE we already have a smart tool called build-compare that comes with a dozen filters for various formats but detecting date/time strings in the middle of binaries is not that trivial... and then you can never be sure that you dont ignore important changes by mistake.
That is why the goal of the reproducible-builds project is to be able to build bit-identical binary packages (and ISO images) where you can publish one sha256sum and other people build the package/ISO from sources and get the same sha256sum.
Maybe nim could do similar to gcc that accepted a patch to use $SOURCE_DATE_EPOCH for its __DATE__ and __TIME__ macros... it is just that I'm not that good at this language (yet) or I would have written it myself.

However, claiming copyright for future years is something I find questionable independent of that.

Contributor

bmwiedemann commented Oct 25, 2017

In openSUSE we already have a smart tool called build-compare that comes with a dozen filters for various formats but detecting date/time strings in the middle of binaries is not that trivial... and then you can never be sure that you dont ignore important changes by mistake.
That is why the goal of the reproducible-builds project is to be able to build bit-identical binary packages (and ISO images) where you can publish one sha256sum and other people build the package/ISO from sources and get the same sha256sum.
Maybe nim could do similar to gcc that accepted a patch to use $SOURCE_DATE_EPOCH for its __DATE__ and __TIME__ macros... it is just that I'm not that good at this language (yet) or I would have written it myself.

However, claiming copyright for future years is something I find questionable independent of that.

@Araq

This comment has been minimized.

Show comment
Hide comment
@Araq

Araq Oct 25, 2017

Member

An alternative approach would be to implement using SOURCE_DATE_EPOCH for CompileDate and CompileTime

Ok, that is beginning to sound good. But if that env var is not set, it should continue to use the current time.

However, claiming copyright for future years is something I find questionable independent of that.

I don't understand this, it uses the current year.

Member

Araq commented Oct 25, 2017

An alternative approach would be to implement using SOURCE_DATE_EPOCH for CompileDate and CompileTime

Ok, that is beginning to sound good. But if that env var is not set, it should continue to use the current time.

However, claiming copyright for future years is something I find questionable independent of that.

I don't understand this, it uses the current year.

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 26, 2017

Contributor

However, claiming copyright for future years is something I find questionable independent of that.

I don't understand this, it uses the current year.

Yes, so when I build today's nim in 2018 it will say "Copyright 2018" even though no author can have worked on this version in 2018.

Contributor

bmwiedemann commented Oct 26, 2017

However, claiming copyright for future years is something I find questionable independent of that.

I don't understand this, it uses the current year.

Yes, so when I build today's nim in 2018 it will say "Copyright 2018" even though no author can have worked on this version in 2018.

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann
Contributor

bmwiedemann commented Oct 26, 2017

See also http://rb.zq1.de/compare.factory-20170807/nim-compare.out for how package diff looks.

@Araq

This comment has been minimized.

Show comment
Hide comment
@Araq

Araq Oct 26, 2017

Member

Yes, so when I build today's nim in 2018 it will say "Copyright 2018" even though no author can have worked on this version in 2018.

Since I work every day on Nim, this is a theoretical issue. Once development slows down I can reconsider this.

Member

Araq commented Oct 26, 2017

Yes, so when I build today's nim in 2018 it will say "Copyright 2018" even though no author can have worked on this version in 2018.

Since I work every day on Nim, this is a theoretical issue. Once development slows down I can reconsider this.

@bmwiedemann

This comment has been minimized.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 26, 2017

Contributor

No, you are working every day on the master version, but when I talk about today's version, I mean
https://github.com/nim-lang/Nim/tree/b2a2522d2dcef2f85b7e1615fc0720d3475427de (or any release tarball) - things that do not change anymore - and they will still get a Copyright 2018 when built in 10 weeks.

Contributor

bmwiedemann commented Oct 26, 2017

No, you are working every day on the master version, but when I talk about today's version, I mean
https://github.com/nim-lang/Nim/tree/b2a2522d2dcef2f85b7e1615fc0720d3475427de (or any release tarball) - things that do not change anymore - and they will still get a Copyright 2018 when built in 10 weeks.

@Calinou

This comment has been minimized.

Show comment
Hide comment
@Calinou

Calinou Oct 26, 2017

Member

Is dating copyrights even useful today? Version information (version number or Git hash) can easily be looked up online, after all.

Member

Calinou commented Oct 26, 2017

Is dating copyrights even useful today? Version information (version number or Git hash) can easily be looked up online, after all.

@dom96

This comment has been minimized.

Show comment
Hide comment
@dom96

dom96 Oct 26, 2017

Member

In fact, the date shouldn't be updated according to this: https://stackoverflow.com/a/2391555/492186.

We should be using "Copyright 2004" everywhere!

Member

dom96 commented Oct 26, 2017

In fact, the date shouldn't be updated according to this: https://stackoverflow.com/a/2391555/492186.

We should be using "Copyright 2004" everywhere!

@FedericoCeratto

This comment has been minimized.

Show comment
Hide comment
@FedericoCeratto

FedericoCeratto Oct 29, 2017

Member

It is not beneficial to move the year forward if only one date is present. The initial date should stay the same and ideally match the true year of authorship. It's possible to use a range e.g. "2004 - 2017", although it is not a requirement.

Member

FedericoCeratto commented Oct 29, 2017

It is not beneficial to move the year forward if only one date is present. The initial date should stay the same and ideally match the true year of authorship. It's possible to use a range e.g. "2004 - 2017", although it is not a requirement.

@Araq Araq merged commit 49320ad into nim-lang:devel Nov 18, 2017

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment