From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: Simon Josefsson <simon@josefsson.org>
Subject: Re: RFC: git-commit based mtime-reproducible tarballs
Date: Sun, 15 Jan 2023 14:21:01 +0100 [thread overview]
Message-ID: <5459006.YCjZZlMYnJ@nimes> (raw)
In-Reply-To: <87lem4cb9v.fsf@josefsson.org>
Hi Simon,
> > This attempts to make
> > reproducible tarballs by sorting the files and passing the
> > "--mtime=<date>" option to tar. ...
> Having the same mtime on all files in a tarball
First question: What is the point of doing that?
Reproducibility is about verifying that an artifact A was generated
from a source S.
When I, as a GNU maintainer or uploader, create a tarball and upload it
to ftp.gnu.org, that tarball is the source S. Because that's what I sign
with my GPG key. The commits in the git repo aren't the source, and even
the git checkout on my disk aren't the source — because I am free to
unpack and repack the tarball as I like, before I upload it to ftp.gnu.org.
When someone runs a complex build on possibly untrusted servers in the
cloud, then it makes sense to view the tarball as an artifact A and the
git repository as the source S. (If the git repository is hosted elsewhere.
If the git repository is being hosted on the same untrusted servers,
it is not sufficient.)
As a consequence, please make such modifications dependent on an option
or environment variable (maybe SOURCE_DATE_EPOCH [1]?); don't activate
them for everyone.
> 1) Having the same mtime on all files in a tarball may cause problems
Definitely. HP-UX 'make' attempts to rebuilds a file Y that depends on
a file X, if Y and X have the same timestamp (mtime). It is long known
that you have to have actually different timestamps for some files.
Bruno
[1] https://reproducible-builds.org/docs/source-date-epoch/
next prev parent reply other threads:[~2023-01-15 13:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87h6wtgmhy.fsf__22556.7857896507$1673713908$gmane$org@redhat.com>
2023-01-15 11:01 ` RFC: git-commit based mtime-reproducible tarballs Simon Josefsson via Gnulib discussion list
2023-01-15 13:21 ` Bruno Haible [this message]
2023-01-15 16:03 ` Paul Eggert
2023-01-15 22:25 ` Bruno Haible
2023-01-16 8:40 ` Simon Josefsson via Gnulib discussion list
2023-01-16 8:51 ` Jim Meyering
2023-01-16 9:45 ` Vivien Kraus
2023-01-16 11:48 ` Bruno Haible
2023-01-16 23:00 ` Simon Josefsson via Gnulib discussion list
2023-01-16 8:28 ` Simon Josefsson via Gnulib discussion list
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5459006.YCjZZlMYnJ@nimes \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=simon@josefsson.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).