Embedded Info.plist doesn't seem to be recognised

[qwandor]

Hello,
I'm not very familiar with Mac OS, so it's entirely possible I'm misunderstanding or doing something wrong, but it appears that the Info.plist embedded by this crate isn't being recognised by the OS.

Context:
I'm working on a Rust Bluetooth library. Since Big Sur, accessing CoreBluetooth APIs apparently requires that the Info.plist contain a string NSBluetoothAlwaysUsageDescription saying why the program wants to use it. When I embed an appropriate Info.plist with this crate and then run my binary from the command-line (either via cargo run or directly), it crashes with Abort trap: 6. If I run it inside lldb, I get an error message:

(lldb) run
Process 76410 launched: '/Users/qwandor/src/btleplug/target/debug/examples/lights' (x86_64)
2021-02-11 17:44:15.350059+0000 lights[76410:891761] [access] This app has crashed because it attempted to access privacy-sensitive data without a usage description.  The app's Info.plist must contain an NSBluetoothAlwaysUsageDescription key with a string value explaining to the user how the app uses this data.
Process 76410 stopped
* thread #12, queue = 'com.apple.root.default-qos', stop reason = signal SIGABRT
    frame #0: 0x00007fff2059a792 libsystem_kernel.dylib`__abort_with_payload + 10
libsystem_kernel.dylib`__abort_with_payload:
->  0x7fff2059a792 <+10>: jae    0x7fff2059a79c            ; <+20>
    0x7fff2059a794 <+12>: movq   %rax, %rdi
    0x7fff2059a797 <+15>: jmp    0x7fff205796a1            ; cerror_nocancel
    0x7fff2059a79c <+20>: retq
Target 0: (lights) stopped.

If I instead copy the Info.plist to target/debug/examples/ alongside the binary, then running it directly still fails, but running in lldb then it prompts for the permission and runs correctly.

I'm on MacOS 11.2, x86_64, Rust 1.49.0, embed_plist 1.2.0. You can see my code trying to use it in deviceplug/btleplug#116.

So I guess there are two questions:

• Why does embedding the Info.plist not work, while putting it in the same directory does? (Is this a bug in the embed_plist crate?)
• Why does it only work when I run my binary under lldb? (Am I doing something wrong?)

[steven-joruk]

How does your plist look using otool?

otool -s __TEXT __info_plist lights | xxd -r

[qwandor]

There seems to be some kind of corruption at the start of it:

~/src/btleplug/target/debug/examples$ otool -s __TEXT __info_plist lights | xxd -r
#Ih<?xml ve.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>CFBundleIdentifier</key>
    <string>org.example.btleplug</string>
    <key>CFBundleName</key>
    <string>btleplug example</string>
    <key>NSBluetoothAlwaysUsageDescription</key>
    <string>Bluetooth example</string>
    <key>NSBluetoothPeripheralUsageDescription</key>
    <string>Bluetooth example</string>
  </dict>
</plist>

[qwandor]

Ah, no, that's just xxd trying to convert some header lines that are not actually the hex dump. It looks fine apart from that, I think.

[nvzqz]

I noticed that the section was missing on newer compilers, so that bug would affect this issue. 1d6f2b9 fixes this. Will publish 1.2.1 soon with this fix.

This issue also seems to affect dtolnay/linkme#41.