Hi Michael, This is Norman, you've reached out to me back in October as
a contact for Cordova development on LinkedIn. I've cc'ed this to
Cordova's development mailing list so that you're answer will be
broadcasted among Cordova contributors. We have a few questions we'd
like to ask to confirm our understanding of what is required. First I
want to take some time to describe the general workflow of Cordova
Projects. Some definitions: - "End User" - The developer using the
Cordova framework and tools. - "Developer" - The Cordova contributors
that develops Cordova framework & tooling. - "App" - Refers to the App's
XCode project Most end users uses the Cordova CLI which creates and
manages a Xcode workspace and projects for the user. This workspace
contains 2 projects, CordovaLib which builds a static library target and
the iOS app project, which consumes the CordovaLib static library.
Apache does not distribute the cordova framework as a static library,
rather the sources are distributed and the user will build it as part of
their app project. Users can also install cordova plugins, which is
usually distributed as raw source code, that is added to the app's
project. In other words, the plugin's codebase becomes part of the app's
source code, rather than it being it's own project/module with it's own
build target & bundle. Q1: In this workflow, it's our understanding that
there is no bundle for static libraries to package the privacy manifest.
Does this mean the privacy manifest must be declared as part of the App
Xcode project? Q2: It's our understanding that static libraries also
cannot be code-signed, so does that mean there is no supply chain
verification for static libraries? Q3: For Cordova plugins, because they
don't have their own build target and instead they become part of the
app's source code, it feels safe to assume that any privacy manifest
entries that it should have needs to find its way inside the App's
privacy manifest file. Is this a correct understanding? Q4: On Cordova
plugins again, since they are often distributed as raw source, there is
also no framework/xcframework to be signed, defeating dependency supply
chain verification. Presumably there isn't anything that Cordova needs
to do as code signing will be required by the end user when packaging
their application. Is this the correct understanding? Q5: This is kind
of a follow-up question that kind of depends on the answers to the above
code-signing questions, but it seems like how Cordova operates currently
defeats the supply chain digital signatures, or at least cannot take
advantage of potential security checks it provides, as they appear to
depend on dependencies being distributed and consumed as xcframeworks.
Is it foreseeable to see restrictions against static libraries or some
other "push" for app developers to use frameworks over static libraries?
Thanks for your time Michael, looking forward to see your feedback.
- [DISCUSS] Cordova - XCPrivacyManifest & Code Signi... Norman Breau
- Re: [DISCUSS] Cordova - XCPrivacyManifest & C... Norman Breau
- Re: [DISCUSS] Cordova - XCPrivacyManifest & C... Michael (WWDR) Wong