linking against a dylib which is not safe for use in application extensions
samdeane opened this issue · comments
Xcode is spitting out this error for the three libs we're linking against.
Need to look into why, and what can be done about it.
ld: warning: linking against a dylib which is not safe for use in application extensions: /usr/local/lib/libjson-c.dylib
ld: warning: linking against a dylib which is not safe for use in application extensions: /usr/local/lib/libhidapi.dylib
ld: warning: linking against a dylib which is not safe for use in application extensions: /usr/local/lib/libu2f-host.dylib
It seems that static libraries (*.a files) should be used instead (they can be installed from homebrew as I recall)
It's not safe because the dylib can be replaced in the system or the bundle, as opposed to static libs (which are linked as part of the application code). It represents a potential major security risk in some applications if the dylib is maliciously replaced either by the user or an external party.
In any case, I think this is sorted, though... can this issue be closed? It would be helpful to describe the actual Homebrew packages to install, but they're easy enough to intuit.
Hey, thanks @superdave, but I know the difference between a dylib and a static lib ;)
The weird thing is that the project is linking against the .a files
So the question is, why am I still getting this warning?
I wonder if the .a files we're linking against are actually stubs for the dylibs. In which case, I need to figure out where the non-stub ones get built to.
My conjecture is that because the linker only actually gets given the name of the library without the lib prefix or .a suffix, it's actually picking up the .dylib version of the file instead, which brew builds and installs in /usr/local/lib/ along with the static library versions.
Here's the relevant log with the relevant bit highlighted:
Ld /blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Products/Debug/Safari\ FIDO\ U2F\ Extension.appex/Contents/MacOS/Safari\ FIDO\ U2F\ Extension normal x86_64
cd /Volumes/caconym/Users/sam/Work/github/safari-fido-u2f/safari-fido-u2f
export MACOSX_DEPLOYMENT_TARGET=10.12
/Applications/Xcode9b6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode9b6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -L/blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Products/Debug -L/usr/local/lib -L/usr/local/Cellar/json-c/0.12/lib -F/blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Products/Debug -filelist /blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Intermediates.noindex/Safari\ FIDO\ U2F.build/Debug/Safari\ FIDO\ U2F\ Extension.build/Objects-normal/x86_64/Safari\ FIDO\ U2F\ Extension.LinkFileList -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -rpath -Xlinker @executable_path/../../../../Frameworks -mmacosx-version-min=10.12 -Xlinker -object_path_lto -Xlinker /blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Intermediates.noindex/Safari\ FIDO\ U2F.build/Debug/Safari\ FIDO\ U2F\ Extension.build/Objects-normal/x86_64/Safari\ FIDO\ U2F\ Extension_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -fapplication-extension -fobjc-link-runtime -L/Applications/Xcode9b6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -Xlinker -add_ast_path -Xlinker /blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Intermediates.noindex/Safari\ FIDO\ U2F.build/Debug/Safari\ FIDO\ U2F\ Extension.build/Objects-normal/x86_64/Safari_FIDO_U2F_Extension.swiftmodule -e _NSExtensionMain -framework Cocoa -lu2f-host -lhidapi -ljson-c -Xlinker -dependency_info -Xlinker /blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Intermediates.noindex/Safari\ FIDO\ U2F.build/Debug/Safari\ FIDO\ U2F\ Extension.build/Objects-normal/x86_64/Safari\ FIDO\ U2F\ Extension_dependency_info.dat -o /blah/DerivedData/Safari_FIDO_U2F-efaadklheuazulebwgkfgcdciwkp/Build/Products/Debug/Safari\ FIDO\ U2F\ Extension.appex/Contents/MacOS/Safari\ FIDO\ U2F\ Extension
Other than that, I can see no other explanation at the moment.
I've just tried an experiment which seems to prove that I'm right (1c4b5ae).
I added a build phase which copied just the .a versions from /usr/local/lib/ to the build products directory, then changed the linker search path to only look there.
Lo and behold, it links against the static libraries.
The one problem with this is that since I'm building on 10.12, I now get a warning saying that the libs were built for 10.12 but I'm building for 10.11.
The fix for this would be to bump the minimum target up - but there's always the chance of it being not as new as the OS that we're building on.
I'm starting to think that it might be better to just bundle the damn static libraries into this repository, to remove all need for brew. I'm a bit loath to do that though - I'd always prefer to be able to build dependencies...
This will be fixed by #12, which is fixed in my fork https://github.com/xlc/Safari-FIDO-U2F/commits/build
@samdeane Sorry, wasn't trying to insult your intelligence. One never knows who doesn't know about DLL injection attacks, though. :-)
As far as statically building dependencies, well... they can be complex to include in the tree for licensing reasons, but I'll leave that up to you. Keeping them as externals obviously also runs the risk of future updates breaking compatibility, though I suppose that's true of most libraries.
Sorry, wasn't trying to insult your intelligence. One never knows who doesn't know about DLL injection attacks, though. :-)
😆
👍
I've actually bitten the bullet and embedded pre-built libraries into this repo for now - built on 10.11.
This forces Xcode to do the right thing and not try to link against the dynamic versions.
Strictly speaking having the pre-complied binaries in this project may not 100% conform with the u2f-host license, which appears to be GPLv3. However, I found a conversation with them where they went on record as saying they were happy to change the license; it seems that they just haven't got round to it.
Pragmatically it's cleaner and means that we don't have to require anyone to install Homebrew to build this project, so I'm going to go with it unless they object.