Page MenuHomePhabricator

Refactor AESCryptoModule and CommExpoPackage so that AES stack is available in NSE
ClosedPublic

Authored by marcin on Jul 4 2023, 7:56 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 28, 7:18 AM
Unknown Object (File)
Tue, Nov 26, 10:17 AM
Unknown Object (File)
Wed, Nov 20, 5:42 PM
Unknown Object (File)
Fri, Nov 8, 10:11 AM
Unknown Object (File)
Fri, Nov 8, 9:35 AM
Unknown Object (File)
Fri, Nov 8, 9:21 AM
Unknown Object (File)
Fri, Nov 8, 9:05 AM
Unknown Object (File)
Sun, Nov 3, 12:07 PM
Subscribers

Details

Summary

This differential implements Objective C compatibility class for AESCryptoModule that internally calls the same functionality as AESCryptoModule expo module. It also introduces necessary refactors and build config files changes so that we can
use Compatibility class from any pure Objective C place like NSE.

Test Plan
  1. Change NSE code according to: https://gist.github.com/marcinwasowicz/442f91ecb3e9781ab4e6e997692e3a46 (literally copy paste).
  2. Send notification to the app running on physical device.
  3. Examine NSE logs in console app.

Diff Detail

Repository
rCOMM Comm
Branch
marcin/eng-4247
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

native/expo-modules/comm-expo-package/ios/CommExpoPackage.podspec
22–35
native/expo-modules/comm-expo-package/ios/CommExpoPackageObjCCompat.h
1–3

This is inspired by: https://github.com/expo/expo/blob/895fafd4aa32e64fa5b77e9e88d6d4f8c3638f9c/packages/expo-modules-core/ios/Swift.h#L10-L16
Expo solves the same problem here. Basically the XCode generated Swift compatibility header is available only in the particular project that implements this header. In other words it is not available in projects that use it as a library. Therefore we create public header that includes private header of the library.
#if __has_include("CommExpoPackage-Swift.h") is used here since Swift compatibility header is created during compilation. Therefore using a bare include would fail the compilation since the header does not exist yet. But once we compile the library and use it in other project the header is present and we can include it.

marcin added 1 blocking reviewer(s): bartek.
marcin requested review of this revision.Jul 4 2023, 8:14 AM
bartek requested changes to this revision.Jul 4 2023, 12:18 PM

Logic / podfile changes look good, just some comments about organizing the code. Feel free to re-request if you feel it doesn't make sense

native/expo-modules/comm-expo-package/ios/AESCryptoModule.swift
8

I'd add a comment here to make it clear why we have two separate module definitions

12–14

I'd delete the private func generateKey() definitions that only call try! generateKeyCommon() and do it directly from here. (suggestion only for the first function, repeat for others)

This will make the code cleaner and you won't have to redefine them twice.
Another change I'd do here is to delete the Common suffix from these private func generateKeyCommon() -> simply generateKey().

To conclude:

  • Have these "commons" functions declared in global (without name suffix)
  • Call them directly from inside modules definitions
18
78

Nit: I like the convention of having pointers suffixed with Ptr

native/expo-modules/comm-expo-package/ios/CommExpoPackageObjCCompat.h
1–3

That's a smart trick!
Maybe it's worth adding a part of your comment in-code for future ourselves to understand why it is done this way ;)

This revision now requires changes to proceed.Jul 4 2023, 12:18 PM

One more thing:
I'd add to the test plan that you tried sending/receiving encrypted media and it still works.
You would need to create a community with a special ID or edit the shouldEncryptMedia() in input-state-container.react.js to always return true.

Alternatively, call these from JS and console.log the results, the same way as you did in the attached NSE snippet (they're in native/utils/aes-crypto-module.js)

  1. Remove Common methods. Use closures in JS exported functions.
  2. Add Ptr suffix to pointer types.
  3. Add comments separating RN/Native code
  4. Add comment to compatibility header explaining used solution.
native/expo-modules/comm-expo-package/ios/AESCryptoModule.swift
45 ↗(On Diff #28403)

I changed method signatures to Compat to mitigate a bug in Swift compiler: https://github.com/apple/swift/issues/56300

This revision is now accepted and ready to land.Jul 6 2023, 8:00 AM

ADd methods that calculate length of data after encryption/decryption

This revision is now accepted and ready to land.Nov 16 2023, 1:11 AM

I made a mistake and landed version of this differential with invalid Podfile.lock - @bartek reported to me that the content of this file (CommExpoPackage check sum in particular) changes upon pod install.I am reopening this differential to update Podfile.lock and re-land it in a correct form.