Skip to content
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

Reproducible builds #24

Open
martinetd opened this issue Feb 15, 2023 · 1 comment
Open

Reproducible builds #24

martinetd opened this issue Feb 15, 2023 · 1 comment

Comments

@martinetd
Copy link

Hello,

in order to generate delta updates I've been looking at making the archive generated by alpine-make-rootfs reproducible today.

In my experience there are two places that weren't reproducible:

  • apk creates /lib/apk/db/scripts.tar when installing packages.
    apk respects SOURCE_DATE_EPOCH so setting that appropriately works and is enough. (more on the variable later)
  • the tar generated by the script has quite a few variable informations. It's well explained in https://reproducible-builds.org/docs/archives/ ; basically we "just" need to add --sort=name --mtime=@$SOURCE_DATE_EPOCH --clamp-mtime --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime to the tar creation line.

Now the big question is what would SOURCE_DATE_EPOCH should be.
The simplest approach is to say, if it's set from outside of alpine-make-rootfs we should just use it (that is true even if we add some detection later), so we probably should add the tar creation option conditionally on that.

As for setting it automatically, I think we could fetch the APKINDEX of the repos we're installing from and taking the latest timestamp in there... It's a bit annoying because we need to set it before running apk, and apk is the one getting the APKINDEX, so it's a bit of a chicken and egg problem... I need to check if we can just regenerate scripts.db later maybe...

What do you think?

@martinetd
Copy link
Author

By the way for the same reason I was playing with setting a --cache-dir in APK_OPTS (with a suitable cache-max-age; yes, I know, it's bad to install older software as security issues etc, it's mostly for CI and hopefully won't be used with really old caches)

At that point I ran into the issue that the main install command in the script has --update-cache . . . Is there any reason for that option? The default 4h cache is probably fine for everyone.
If you don't see a problem with that I'll send a PR to remove that option, and that at least solves the timestamp problem for me: I can just use the cache creation date.

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

No branches or pull requests

1 participant