build: ensure that LC_UUID is generated for Darwin binaries

[edigaryev]

Problem: on macOS 15 (Sequoia), when Packer or any of its countless plugins attempt to connect to a directly attached network (including local VMs), the connection will currently fail, because having a LC_UUID identifier is critical for the local network privacy mechanism:

Local network privacy uses your main executable UUID as part of its implementation. If your main executable has no UUID, or shares a UUID with other programs, local network privacy may behave weirdly.

To fix that, make sure your main executable has a UUID and that it’s unique. For more about this, see TN3178: Checking for and resolving build UUID problems.

Solution: bump Golang's minor revision and use the new -B gobuildid option, as suggested in golang/go#68678 (comment) to produce Packer binary with UUID.

Fixes #13196.

[lbajolet-hashicorp]

Hey @edigaryev,

Thanks for digging into this and implementing the change, looking at the upstream issue and the Apple docs this should indeed fix that problem.

We'll release this as part of 1.12.0, scheduled for January.
Come to think of it, this is probably something we should roll out to plugins as well. I'll look into this right now.

[edigaryev]

We'll release this as part of 1.12.0, scheduled for January.

Would there a way to get this earlier? Via a patch release or nightly?

Come to think of it, this is probably something we should roll out to plugins as well. I'll look into this right now.

This case is covered in the TN3179: Understanding local network privacy:

When a process performs a local network operation, macOS tries to track down the responsible code.

For example, if your app spawns a helper tool and the helper tool performs a local network operation, macOS considers the app to be the responsible code.

Packer is the responsible code here (which needs an UUID and will be shown as the source when displaying the dialog box asking for a permission), and plugins are "helper tools".

[lbajolet-hashicorp]

To respond, yes, Nightlies starting today will have this baked-in, so anyone will be able to use 1.12.0-dev until we release the final version indeed!

As for the plugins, thanks for the tidbit, glad to hear that Packer alone will be enough to fix this problem :)

Thanks for the PR and the extra information @edigaryev, much appreciated!

[lbajolet-hashicorp]

Note: regarding Nightlies, they're built every day at ~00:00 UTC, so tomorrow, provided the release worked as expected, this should be available.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.