Sorry, pasting the email seemed to have destroyed the formatting, I
believe it was sent as HTML and then got stripped. Here's a version with
a paste without formatting:
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.
On 2024-03-18 13:02, Norman Breau 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
