WorryFree Computers   »   [go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SwiftPM Firestore: SSL symbol collision #6869

Closed
paulb777 opened this issue Oct 29, 2020 · 11 comments
Closed

SwiftPM Firestore: SSL symbol collision #6869

paulb777 opened this issue Oct 29, 2020 · 11 comments

Comments

@paulb777
Copy link
Member

The Swift Package Manager implementation of the Firestore BoringSSL dependency does not do symbol renaming like its CocoaPods implementation. This may cause potential symbol collision issues for apps that link another SSL implementation.

Please thumbs-up this issue to help us prioritize if it impacts your app.

@paulb777
Copy link
Member Author

For grpc-swift, see #7508 and apple/swift-nio-ssl#269

@paulb777
Copy link
Member Author

Some additional detail notes from a conversation with @wilhuff:

Specifically there is still a potential symbol collision with OpenSSL.

Unlike the CocoaPods version of BoringSSL, the SPM version does not do symbol renaming.

For SPM, we'd likely need to do a source transformation to rename, since SPM does not support preprocessing like podspecs do.

Alternatively, we could switch the SPM version to depend on swift-nio-ssl instead but that would be inconsistent with the CocoaPods distribution.

Even more ideal would be for gRPC and gRPC-Swift to agree upon the same BoringSSL implementation and then Firebase use the same for both CocoaPods and SPM

@paulb777
Copy link
Member Author

Xcode 13.3 introduces build tool plugins, which might make it more feasible for the BoringSSL Package.swift to do a renaming similar to do what is done with CocoaPods. See https://developer.apple.com/documentation/xcode-release-notes/xcode-13_3-release-notes.

cc: @wu-hui @dennycd

@mrgrauel
Copy link

We have duplicated symbols because of another project which uses another version of BoringSSL. It's needed to scope your version for your use cases.

@jzaczek
Copy link
jzaczek commented Dec 14, 2022

Hello @paulb777

Is there any chance to assign a higher priority to this issue? We're currently in the process of migrating our codebase from cocoa pods to spm and are experiencing this issue, just as described in this swift forums thread - the symbol collision is between openssl included by another dependency and boringssl from firebase.

@paulb777
Copy link
Member Author

Thanks for the upvotes. I've had conversations with the gRPC team about this and hopeful to get it on the roadmap for the first quarter of 2023

@sampajano
Copy link

We're starting to look into this issue. But would it be possible for us to get example project with the above mentioned collision? So that we could use it to verify that our fix works. Thanks!

@paulb777 FYI :)

@HannahShiSFB
Copy link

Xcode 13.3 introduces build tool plugins

We are still using Xcode 11.3 unfortunately. The upgrade to Monterey (with Xcode 13.4) is in-progress I however have no idea when it'll happen.

@immi-sipgate
Copy link

@sampajano @paulb777 do you have a fix?
Maybe you could provide a (unstable) branch which we could use together with swift package manager. Then we could give you some feedback :)

@paulb777
Copy link
Member Author

This was fixed in Firebase 10.8.0 when we fixed to a binary distribution built from the CocoaPods distribution with symbol renaming.

@immi-sipgate
Copy link

Works but now the dsym upload to crashlytics doesnt work anymore.
We have no crashlogs @paulb777

@firebase firebase locked and limited conversation to collaborators Jun 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants