Improvements to disk image creation #190
Conversation
The present setup uses Finder to set up the window parameters for the install image. This is undesirable for multiple reasons, and need not be repeated on every build when the window parameters haven't changed. With this change, the .DS_Store file (containing the window settings) is captured and used for subsequent builds. The intent is that a "vetted" copy can be checked into the repository, with no further need to use Finder in the build until some change is made to the parameters (at which point the saved version can be deleted to cause it to be recomputed). This commit does not include the .DS_Store copy (xDS_Store), which belongs in a separate commit.
An added bonus is that it gets rid of the error on the chmod -R.
This was generated under OSX 10.9.5 in a "maximally sanitized" fashion, by running the build over an SSH connection in the presence of a near-virgin Finder instance after a fresh boot.
I've tried finding more information about this but so far I have not found anything reliable. Do you remember where you read about the issue? Skimming through the file did not reveal anything that looked out of place. |
|
Here's an article containing some information about the file, based on reverse engineering: https://wiki.mozilla.org/DS_Store_File_Format There's also some information the the doc for a Python tool that was created for direct .DS_Store manipulation: http://ds-store.readthedocs.org/en/latest/ If you look at the file with a hex editor, a couple of things that stand out (even when using a near-virgin Finder) are the name of the boot volume on the build system, and the name of the temporary image file, neither of which should be visible within the diskimage volume itself. Neither of these is particularly sensitive, but it doesn't speak well for the trustworthiness of the process. There's also some other less comprehensible stuff that may or may not be leaking information. The nonreproducibility is easily observed by just creating the image twice without changing anything, and comparing the results. Switching to the Python tool might be a better long-term strategy, but it's more work and may introduce another build dependency (unless "six" were bundled with the build system). |
|
Thanks! |
The current build system sets up the default window parameters by running Finder via AppleScript. Aside from the annoying (and initially puzzling) flashes during the build, this has a number of disadvantages:
It means that the otherwise purely command-line-oriented build procedure may not work over an SSH connection. I say may not work because AppleScript is perfectly willing to go outside the process tree to find an instance of Finder running under the current user ID, which seems like rather inappropriate default behavior, but that's another story.
It appears to incorporate uninitialized memory into the resulting .DS_Store file, leaking some information about the build machine in the process. This also makes the contents of the file nonreproducible.
Since that mechanism is designed primarily for use with interactive users, it doesn't have a well-defined way to be certain that the state is correct on disk (as evidenced by the delays that have been added to that code in the master branch).
Since all the settings are contained in the .DS_Store file, and since the window parameters are rarely changed, a way to mostly avoid the need to run Finder in the build is to capture a copy of a .DS_Store file with the proper setup, and then simply copy it into the disk image in normal builds. This also means that issue # 2 can be ameliorated by using a "near virgin" Finder to create the file.
This approach doesn't eliminate the uncertainty as to when the .DS_Store file can be trusted to be up to date. Currently, it adds a 5-second delay to the end of the Finder commands, and then waits until after the syncs to grab the copy. A slightly safer approach might be to remount the final image and grab it from there, but that would be more complicated. Fortunately, once a copy has been determined to be OK, all subsequent builds using it will be OK as well, which is a good deal more deterministic than the present approach.
This pull request includes three commits (which I've tested here):
Adding code to implement the above. Note that most of the diff is just an indentation change. It includes setting up the binary attribute for the xDS_Store file, but not the file itself.
Adding code to remove the superfluous .Trashes directory.
Adding an xDS_Store file based on the current settings (and created in a "sanitized" environment).