mirror of
https://gitlab.com/buildroot.org/buildroot.git
synced 2026-09-09 07:51:59 -09:00
9fbd3d8574
Commit768f9f80f6(support/download: generate even more reproducible tarballs) causes non-reproducibility in tarballs we previousy generated, especially the archives for two cargo-vendored packages, ripgrep and sentry-cli. The cause is that those two pakcages eventually vendor a file that has the u+x bit set, but is otehrwise go-x. With768f9f80f6, the files are now go+x, so the hash for those generated archives has changed. Besides, that commit was wrong: it did not account for the 'r' bit for go part, leaving some non-reproducibility still unaccounted for. So, to generate really reproducible archives, we would need to fix that read bit as well, and that has the potential to affect all the archives we generated so far. If we wanted to do so, we'd need a way to version all generated archives, like we do for git and svn, but now for all the different CVSes, as well as for all the vendoring post-processes. For768f9f80f6, all that was of conern was the working copies of CVSes (i.e. git, svn, cvs...) that we cache in the Buildroot download dir, not the temporary files during post-processing. Indeed, in that latter case, the user has virtually no way to mangle with the mode of the intermediate extract before repack. And we do have a big fat warning that users should not attempt to meddle with the git tree that Buildroot caches. As768f9f80f6however demonstrates, is that it took quite a long time between the introduction of the git caching, and the time someone eventually discovered they could meddle in there. This shows that the issue it not actually critical in most setups. Also, the tar manual [0] hints at a better solution to handle reproducibility, which even avoids touching the files on disk which is even nicer: ‘--mode='go+u,go-w'’ Omit irrelevant information about file permissions. If we were to actually handle the mode bit for reproducibility, we'd need to: - introduce archive versioning for all download backends and prost-processing - use the tar officially suggested method So, revert that change, as it was incomplete, was not really fixing much issues, and causes actual issues. This reverts commit768f9f80f6. [0] https://www.gnu.org/software/tar/manual/tar.html#Reproducibility Thanks to Vincent and Arnout for pointing at the tar manual. Reported-by: Antoine Coutant <antoine.coutant@smile.fr> Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Vincent Fazio <vfazio@xes-inc.com> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. The documentation can be found in docs/manual. You can generate a text document with 'make manual-text' and read output/docs/manual/manual.text. Online documentation can be found at http://buildroot.org/docs.html To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the target architecture and the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) find the kernel, bootloader, root filesystem, etc. in output/images You do not need to be root to build or run buildroot. Have fun! Buildroot comes with a basic configuration for a number of boards. Run 'make list-defconfigs' to view the list of provided configurations. Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org You can also find us on #buildroot on OFTC IRC. If you would like to contribute patches, please read https://buildroot.org/manual.html#submitting-patches