According to https://developer.apple.com/documentation/security/ksecattrkeytypeecsecprimerandom?language=objc, kSecAttrKeyTypeECSECPrimeRandom is 10.12+ and the header agrees:

/System/Library/Frameworks/Security.framework/Headers/SecItem.h:
extern const CFStringRef kSecAttrKeyTypeECSECPrimeRandom
    API_AVAILABLE(macos(10.12), ios(10.0));


The class that uses that constant has the appropriate availability annotations (https://cs.chromium.org/chromium/src/device/fido/mac/make_credential_operation.h?l=51&rcl=04d2f2b913bdba9bddfbfc8240ab430e9cbff6e9), so I'm not sure why this is happening. Maybe a component build issue?

Component build would be my first suspect as well. Does setting `is_component_build = false` make a difference?

Alternatively, does removing the COMPONENT_EXPORT annotation from MakeCredentialOperation make a difference? (You'll have to comment out {make_credential,get_assertion}_operation_unittest.mm  from //device/BUILD.gn for that to work.)

If the combination of component + API_AVAILABLE doesn't work, we could probably work around it by moving all of //device/fido/mac into its own source set, and having the component depend on that? That would avoid exporting the fido/mac symbols from the fido component.

Hrm, dyldinfo says the symbol is weakly linked.

$ /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind out/Debug/libfido.dylib | grep PrimeRandom
__DATA  __got            0x0041C0F8    pointer      0 Security         _kSecAttrKeyTypeECSECPrimeRandom (weak import)

This makes sense, given that the symbol is 10.12+ and we build with a min required macOS lower than that. My understanding of weak linking is that if that symbol is missing at load time it will simply be NULL, so I really don't understand why dlopen is complaining here? But my understanding is rudimentary at best.

Avi, to start could you confirm whether that symbol is weakly linked in your build, either with to command above, or with `nm -m out/Debug/libfido.dylib |grep PrimeRandom`?

I did a non-component build and it still fails to run:

/V/s/c/s/out (bubble)> debug/Chromium.app/Contents/MacOS/Chromium 
dlopen /Volumes/src/chrome-git/src/out/debug/Chromium.app/Contents/MacOS/../Versions/68.0.3428.0/Chromium Framework.framework/Chromium Framework: dlopen(/Volumes/src/chrome-git/src/out/debug/Chromium.app/Contents/MacOS/../Versions/68.0.3428.0/Chromium Framework.framework/Chromium Framework, 261): Symbol not found: _kSecAttrKeyTypeECSECPrimeRandom
  Referenced from: /Volumes/src/chrome-git/src/out/debug/./libfido.dylib
  Expected in: /System/Library/Frameworks/Security.framework/Versions/A/Security
 in /Volumes/src/chrome-git/src/out/debug/./libfido.dylib
fish: 'debug/Chromium.app/Contents/Mac…' terminated by signal SIGABRT (Abort)
/V/s/c/s/out (bubble) [134]> nm -m debug/libfido.dylib | grep PrimeRandom
                 (undefined) external _kSecAttrKeyTypeECSECPrimeRandom (from Security)
/V/s/c/s/out (bubble)> /Library/Developer/CommandLineTools/usr/bin/dyldinfo -bind debug/libfido.dylib | grep PrimeRandom
__DATA  __got            0x0041C0F8    pointer      0 Security         _kSecAttrKeyTypeECSECPrimeRandom

It's not weak importing properly.

I'm looking at my copy of the SDK (at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework/Versions/A/Headers/SecItem.h):

extern const CFStringRef kSecAttrKeyTypeECSECPrimeRandom
    __OSX_AVAILABLE_STARTING(__MAC_10_9, __IPHONE_4_0);

That is... wrong.

I'm running Xcode 8.2.1; I think that's the version of the 10.12 SDK that came with it.

I know we don't officially support building Chromium on 10.11 (https://chromium.googlesource.com/chromium/src/+/master/docs/mac_build_instructions.md) but perhaps that's something to note for those who try to.

The workaround is to fix the availability notation in the SDK.

Just to clarify, your suggested fix is to locally modify the SDK header file? Is that what Google is doing on their official Chrome builders?

That's what I did. I don't know what the official Chrome builders are doing.

You should use the 10.12 SDK. That's what all official builds do.

Which 10.12 SDK, though?

The version of the 10.12 SDK that comes with Xcode 8.2.1 is the broken one. I suppose Apple fixed it in subsequent issuings of the 10.12 SDK. Which Xcode do the official builders use?

% cat /Applications/Google\ Chrome\ Canary.app/Contents/Info.plist| grep -A1 '>DT'
[snip]
	<key>DTXcode</key>
	<string>0832</string>
--
	<key>DTXcodeBuild</key>
	<string>8E2002</string>

I'd bet that it was fixed by the time of Xcode 8.3, which is required for 10.12, which is officially the min required macOS for building (https://chromium.googlesource.com/chromium/src/+/lkgr/docs/mac_build_instructions.md). I'm a weirdo still on 10.11.

fwiw, on osx 10.11, I'm trying an obvious patch.

Deleted: mac_credentials_2454.patch 1.1 KB

mac_credentials_2454.patch 1.1 KB Download

I just compared the 10.12 SDK as found in Xcode 8.2.1 with the 10.12 SDK as found in Xcode 8.3. There are significant differences, especially in the Security.framework.

We officially require macOS 10.12 for building, which means the 10.12 SDK as found in the Xcode corresponding to 10.12, which is Xcode 8.3.

We won't take patches for this in Chromium. If you want to build with 10.11, you'll have to do what I did and fix your SDK. :(