Skip to content

Fix lsbom segfault or not listing content #21, #33 and hardcoded path in Makefile #35#36

Open
cluck wants to merge 13 commits intohogliux:masterfrom
cluck:master
Open

Fix lsbom segfault or not listing content #21, #33 and hardcoded path in Makefile #35#36
cluck wants to merge 13 commits intohogliux:masterfrom
cluck:master

Conversation

@cluck
Copy link
Copy Markdown
Contributor

@cluck cluck commented Oct 26, 2024

I have tested lsbom against payload.pom, pre.pom, post.pom of Apple iOS/tvOS OTA updates and verified them working.

@hogliux
Copy link
Copy Markdown
Owner

hogliux commented Oct 28, 2024

First of all, thank you so much for committing some time to this years old project. I no longer maintain it so I'm always happy when people jump in and give it some love. Thank you!!

I'm a bit unsure about this PR. First of all, the hard coded path in the makefile is for reproducible builds. If you replace it with $(SRC) the builds will no longer be reproducible but will depend on where you build them. This is a problem for automatic build integration which build in random tmp folders but then check the hashes of built binary.

Also, I don't quite understand the whole issue with the "Paths" line. It used to be just name == "Paths" which seemed fine to me but people complained that the code didn't work with iOS OTAs (see this issue for example). This tool was never intended to be used with iOS OTAs so I never tested it with this.

What value does name have with iOS OTAs? Is there may be another null character inside the C++ string for iOS OTAs? Anyway the code as it currently stands (i.e. strstr == 0) is definitely wrong so it would be good to fix this. I'd just like to understand why name == "Paths" was wrong in the first place.

If rfind does fix it then I'm happy to accept this. But I'd actually prefer to just use find here. Sure rfind is more effecient but I'd prefer readability. After all this is not a performance sensitive tool.

@cluck cluck force-pushed the master branch 2 times, most recently from 682b24a to ea404d0 Compare March 7, 2026 18:49
@cluck
Copy link
Copy Markdown
Contributor Author

cluck commented Mar 7, 2026

Thanks for your comment and attention from time to time.

From your #36 (comment) I understand that your intention regarding reproducible builds was to normalize any source path to be masked and replaced in the resulting binary to appear as if it was built under /home/lbr/code/bomutils. The problem is that -ffile-prefix-map=/home/lbr/code/bomutils=. isn't doing that1, and the next similar thing which would do (if the current working directory is the source directory) is -ffile-prefix-map=.=/home/lbr/code/bomutils. And, indeed, my intention is to mask random source directories, but without dependency on the current working directory.

Regarding the other issue with name == "Paths" I now figured out what was going on and I'll comment under #33 (comment).

Footnotes

  1. -ffile-prefix-map=old=new
    When compiling files residing in directory old, record any references to them in the result of the compilation as if the files resided in directory new instead.

@cluck cluck force-pushed the master branch 2 times, most recently from ab8c6ab to 8c88098 Compare March 7, 2026 21:29
@cluck cluck force-pushed the master branch 8 times, most recently from 405fa77 to f7149c5 Compare March 18, 2026 23:38
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

Successfully merging this pull request may close these issues.

2 participants