search

blacktop / ipsw

iOS/macOS Research Swiss Army Knife
https://blacktop.github.io/ipsw
MIT License
1.76k stars 134 forks source link

Remove AppBuildTime #420

Closed ryandesign closed 5 months ago

ryandesign commented 5 months ago

What happened?

Please remove everything to do with storing the build time in your program, e.g.:

https://github.com/blacktop/ipsw/blob/b673c02c6439b9cfa9126d5886681f525e2e2f86/cmd/ipsw/cmd/version.go#L41

It makes the build non-reproducible.

How can we reproduce this?

Observe that build time is recorded in the program.

ipsw version

N/A

Search

Code of Conduct

Additional context

No response

blacktop commented 5 months ago

Can you explain why this is an issue?

blacktop commented 5 months ago

Is there a tool or standard way people are testing this? above and beyond what I'm doing with https://github.com/anchore/syft and sboms?

blacktop commented 5 months ago

Does this have to do with creating an official MacPort for ipsw ?

blacktop commented 5 months ago

Swapping out AppBuildTime for AppBuildCommit. I believe this meets the 'spirit' of this issue

CC @TheRealKeto

TheRealKeto commented 5 months ago

@blacktop I'd like to make clear that I speak for myself, and I am not representing the views of the MacPorts organization, or any other organization.

Given concerns about reproducible builds for this project in MacPorts, I believe the current solution to the issue at hand is too small. Though, according to the Church of Reproducible Builds, Git checksums are appropriate, the situation remains the same.

To address these concerns, I decided to move forward by patching out AppBuildTime all together, despite a member of the MacPorts team advising me to use a constant value for the field (with something like "unknown"); this approach is not satisfactory. Users should have a clear understanding of version information of programs. By having "unknowns" (like the build time of a program) appear without meaningful information, a field like AppBuildTime is useful to no one. The same can be said about a commit hash, despite them embraced by the Church of Reproducible Builds. While the version of a port, a constant, changes with every release, such constant is mandatory; a commit hash does not fit that description, so it falls under the same scenario.

The final solution is to make information (whether thats the build time or a commit hash) be determined by mechanisms only available for those building from a clone of the project repository; this should exclude tarballs (particularly those automatically made by Github) as they don't contain the components necessary to determine this information, which often have predetermined versioning systems (whether that's reading from a VERSION file at compile time by the build system, or an approach similar to libimobiledevice projects with .tarball-version, or (more simplistically), providing the version at build time).

All this is too pushy, but this should only be considered as advice. I am content with the current approach that has allowed this project to be officially distributed by MacPorts, as it correctly meets the requirements described above, and such solution prevented me from dictating the way in which you manage the development of your own software.

ryandesign commented 5 months ago

Can you explain why this is an issue?

The web site I linked to explains. Specifically, https://reproducible-builds.org/docs/timestamps/

Does this have to do with creating an official MacPort for ipsw ?

Only to the extent that I learned of the existence of ipsw via the pull request that added it to MacPorts, and in that PR a patch was developed to patch out AppBuildTime, and package management systems like MacPorts don't like carrying around patches forever, so I wanted to report the issue to you.