-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Add privacy manifest #1604
Add privacy manifest #1604
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. Does this have to go in the absl/
directory, or can it go in the root directory of the project? I think I would prefer the root if it works, but I don't know if it does.
I put it into |
76ae632
to
79da4bd
Compare
Merged, thank you! |
@derekmauro Hi Derek, Thank you for the quick response! May I ask, will Abseil have a release in the near future? We have clients count on the privacy manifest change. BTW, we also need backport to Abseil version 20220623.0, to support grpc 1.49, do you know who I need to talk to? |
We just had a release last week and we normally release approximately every 6 months, so the timing on this inquiry isn't great. A backport is probably the simplest option. When do you need this by? |
I have created the PRs to backport to the lts branches that gRPC is depending on, can you help merge them and publish new versions? Thanks. |
This comment was marked as spam.
This comment was marked as spam.
Can you please clarify the time frame that you need this by? If possible I'd like to wait a bit to see if there are any additional issues that require a patch in the most recent release so I can batch them into a single patch release. |
May I ask how much time you are thinking about? We have a client(Firebase) is waiting eagerly and would want this asap, but if you're able to get the verifications in no more than a week, we can probably wait a bit... |
I merged your pull requests and can create new releases next week. By the way, I noticed you didn't backport to 20230125.3. I guess you don't need that? I should probably backport to that as well anyway. |
Thank you so much for your quick response! It helps a lot! |
I've created new releases with the backport. |
Thank you! It's great! |
s.resource_bundles = { | ||
s.module_name => 'PrivacyInfo.xcprivacy', | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @HannahShiSFB, because the resource bundle is at the root of the podspec, it will not get pulled down when clients like Firebase depend on subspecs of the pod (example).
See the approach taken in grpc/grpc#35542 and google/GoogleUtilities#144.
The subspecs in this spec look to be generated (example spec that has been published).
I can think of a few options to fix this:
- Add a new subspec with the privacy manifest and make it a dependency of all other subspecs.
- Wrap the existing bundle declaration in a subspec that clients like Firebase would manually point to in our podpspecs
- Throw the resource bundle in the
base
subspec'sconfig
subspec (abseil/base/config
) because that nested config subspec looks to be a core dependency of many other subspecs.
Then, releasing a patch fix will be needed with any necessary backporting, and should also include changes from the unrelated #1639.
Imported from GitHub PR #1643 Addressing comments at #1604 Add a xcprivacy subspec and have all other subspecs depend on it (option 1) Didn't going with option 3 because there are several levels of subspecs in abseil podspec, it's difficult to track whether all of them directly or indirectly depends on abseil/base/config or ensure they will continue to depend on it. Example of generated podsped: https://gist.github.com/HannahShiSFB/15d8fb6aa637f2781b7be4218d080f11 Merge 4405cdf into 4539c54 Merging this change closes #1643 COPYBARA_INTEGRATE_REVIEW=#1643 from HannahShiSFB:privacy-manifests 4405cdf PiperOrigin-RevId: 616914674 Change-Id: If56d5a4f1a7cc6f9fac7a2d8e95b55d140e645fc
Imported from GitHub PR abseil#1604 Looks like abseil is not using any of the APIs listed in https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api?language=objc, so adding an empty manifest file. fixes abseil#1602 Merge 79da4bd into f7d2b13 Merging this change closes abseil#1604 COPYBARA_INTEGRATE_REVIEW=abseil#1604 from HannahShiSFB:privacy-manifests 79da4bd PiperOrigin-RevId: 600525731 Change-Id: I3fbc6dcc6e47032665a9fa72c000ae245a25dd52
Imported from GitHub PR abseil#1643 Addressing comments at abseil#1604 Add a xcprivacy subspec and have all other subspecs depend on it (option 1) Didn't going with option 3 because there are several levels of subspecs in abseil podspec, it's difficult to track whether all of them directly or indirectly depends on abseil/base/config or ensure they will continue to depend on it. Example of generated podsped: https://gist.github.com/HannahShiSFB/15d8fb6aa637f2781b7be4218d080f11 Merge 4405cdf into 4539c54 Merging this change closes abseil#1643 COPYBARA_INTEGRATE_REVIEW=abseil#1643 from HannahShiSFB:privacy-manifests 4405cdf PiperOrigin-RevId: 616914674 Change-Id: If56d5a4f1a7cc6f9fac7a2d8e95b55d140e645fc
* Prevent overflow in absl::CEscape() Strings larger than 1 GiB on a platform with a 32-bit size_t could potentially overflow size_t in `CEscapedLength()`, resulting in an undersized allocation. The resulting write in `CEscapeAndAppendInternal()` would then write beyond the bounds of the output buffer. A second overflow, where the calculated escaped length is added to the size of the string being appended to, is also fixed. In both cases the program will now abort prior to the overflow. Credit goes to Ronald Crane (Zippenhop LLC) for reporting this issue. PiperOrigin-RevId: 607019573 Change-Id: I97bf246cde96102a793d2db49446cccae08abf59 * Workaround for NVIDIA C++ compiler being unable to parse variadic expansions in range of range-based for loop Fixes: abseil#1629 PiperOrigin-RevId: 611131201 Change-Id: I787731e00207b544ee16055e6e0d323a5094a433 * Fix OSX support with CocoaPods and Xcode 15 PiperOrigin-RevId: 615090942 Change-Id: I7cc20a0129dcfbbddedd9e6d816bb6234bff14b3 * PR abseil#1643: add xcprivacy to all subspecs Imported from GitHub PR abseil#1643 Addressing comments at abseil#1604 Add a xcprivacy subspec and have all other subspecs depend on it (option 1) Didn't going with option 3 because there are several levels of subspecs in abseil podspec, it's difficult to track whether all of them directly or indirectly depends on abseil/base/config or ensure they will continue to depend on it. Example of generated podsped: https://gist.github.com/HannahShiSFB/15d8fb6aa637f2781b7be4218d080f11 Merge 4405cdf into 4539c54 Merging this change closes abseil#1643 COPYBARA_INTEGRATE_REVIEW=abseil#1643 from HannahShiSFB:privacy-manifests 4405cdf PiperOrigin-RevId: 616914674 Change-Id: If56d5a4f1a7cc6f9fac7a2d8e95b55d140e645fc
* Prevent overflow in absl::CEscape() Strings larger than 1 GiB on a platform with a 32-bit size_t could potentially overflow size_t in `CEscapedLength()`, resulting in an undersized allocation. The resulting write in `CEscapeAndAppendInternal()` would then write beyond the bounds of the output buffer. A second overflow, where the calculated escaped length is added to the size of the string being appended to, is also fixed. In both cases the program will now abort prior to the overflow. Credit goes to Ronald Crane (Zippenhop LLC) for reporting this issue. PiperOrigin-RevId: 607019573 Change-Id: I97bf246cde96102a793d2db49446cccae08abf59 * Workaround for NVIDIA C++ compiler being unable to parse variadic expansions in range of range-based for loop Fixes: #1629 PiperOrigin-RevId: 611131201 Change-Id: I787731e00207b544ee16055e6e0d323a5094a433 * Fix OSX support with CocoaPods and Xcode 15 PiperOrigin-RevId: 615090942 Change-Id: I7cc20a0129dcfbbddedd9e6d816bb6234bff14b3 * PR #1643: add xcprivacy to all subspecs Imported from GitHub PR #1643 Addressing comments at #1604 Add a xcprivacy subspec and have all other subspecs depend on it (option 1) Didn't going with option 3 because there are several levels of subspecs in abseil podspec, it's difficult to track whether all of them directly or indirectly depends on abseil/base/config or ensure they will continue to depend on it. Example of generated podsped: https://gist.github.com/HannahShiSFB/15d8fb6aa637f2781b7be4218d080f11 Merge 4405cdf into 4539c54 Merging this change closes #1643 COPYBARA_INTEGRATE_REVIEW=#1643 from HannahShiSFB:privacy-manifests 4405cdf PiperOrigin-RevId: 616914674 Change-Id: If56d5a4f1a7cc6f9fac7a2d8e95b55d140e645fc
Looks like abseil is not using any of the APIs listed in https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api?language=objc, so adding an empty manifest file.
fixes #1602