Thanks for getting back to me. Let me circulate with the team.
> On Mar 18, 2024, at 9:02 AM, Norman Breau <nor...@breautek.com> wrote:
>
> 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.
>
