Update warning about calling unsigned code from macOS through FFI

[timsneath]

As I understand it, the limitation referenced here is no longer accurate:

site-www/src/_guides/libraries/c-interop.md

Lines 78 to 82 in 757943b

	{{site.alert.info}}
	**On macOS,** the Dart VM (`dart`) can load only **signed libraries.**
	For details and workarounds,
	see [SDK issue #38314.][38314]
	{{site.alert.end}}

It looks like dart-lang/sdk#38314 is fixed. Is that correct, @dcharkes? If so, let's remove this caveat from this page. (If not, let's update it to point to an open issue...)

[parlough]

It looks like we can remove this, but if I'm understanding correctly, if we remove this we need to introduce another note:

It seems that even with the changes, (unsigned and signed?) shared libraries need to be in the same directory or subdirectory as the signed Dart executable or use an unsigned executable.

Perhaps @dcharkes can shine some light on what is import to highlight for developers around this and what the best direction to suggest to them is.

[dcharkes]

I did some local testing, there's three modes for dylibs with codesign:

1. Signed with an identity

$ security find-identity -v -p codesigning
  1) <identity> "<name>"
...
$ codesign -s <identity> -v <dylib path>
...
$ codesign -dv <dylib path>
Executable=<dylib path>
Identifier=<dylib name>
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=16889 flags=0x0(none) hashes=522+2 location=embedded
Signature size=4785
Signed Time=23 May 2022 at 07:50:02
Info.plist=not bound
TeamIdentifier=<identity>
Sealed Resources=none
Internal requirements count=1 size=192

Running with the downloaded (by the Dart team signed) SDK works with any file path.

dacoharkes-macbookpro2:sdk dacoharkes$ codesign -dv /Users/dacoharkes/Downloads/dart-sdk/bin/dart
Executable=/Users/dacoharkes/Downloads/dart-sdk/bin/dart
Identifier=dart
Format=Mach-O thin (arm64)
CodeDirectory v=20500 size=297104 flags=0x10000(runtime) hashes=9274+7 location=embedded
Signature size=8991
Timestamp=18 May 2022 at 15:45:37
Info.plist=not bound
TeamIdentifier=EQHXZ8M8AV
Runtime Version=11.3.0
Sealed Resources=none
Internal requirements count=1 size=164

2. Signed ad hoc

Using - as identity

$ codesign -s - -v <dylib path>
...
$ codesign -dv <dylib path>
Executable=<dylib path>
Identifier=<dylib name + hash>
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=16919 flags=0x2(adhoc) hashes=522+2 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=0 size=12

Running with the downloaded (by the Dart team signed) SDK works with any file path.

3. Completely unsigned

$ codesign --remove-signature -v <dylib path>
...
$ codesign -dv <dylib path>
<dylib path>: code object is not signed at all

I cannot open this dylib (with an absolute path) with the signed SDK not valid for use in process: Trying to load an unsigned library.

Trying to open with a relative path will lead to relative path not allowed in hardened program error. But this is pointless because it will not open with an absolute path anyway.

A completely unsigned dylib cannot be opened with an ad hoc signed dart executable either.

A dart with --remove-signature will not run whatsoever: Killed: 9.

In conclusion

The Dart SDK (or any executable for that matter) can only open signed or ad hoc signed dylibs. Paths don't matter. Opening unsigned dylibs (or running unsigned code) is completely disallowed on MacOS.

All dylibs should be signed or ad hoc signed on MacOS.

[parlough]

Thanks so much for the investigation and clarifications @dcharkes!

It sounds like having a note is still useful but perhaps we should link to (Apple) documentation on signing libraries rather than linking to an issue with some mixed/confusing messages.

[dcharkes]

We should probably find the relevant documentation from Apple itself, though I was unable to find it.

By now, everyone has to sign / ad hoc sign on MacOS, so the limitation is nothing Dart specific as far as I understand. So we can also opt to have no message.