CO presents his proposal for pack signing (see slides).
Private key should be hidden in Vendor’s internals
Public key needs to be made public
Next to the pack’s as
Uploaded to a keyserver
Public key per pack, e.g., <publickey> tag in PDSC
Standalone public key local to the filesystem
FR proposes to use X.509 certificates instead of plain GPG keys. This would have a couple of features over shared keys, such as certificate chains with per-developer certificate.
JK adds that this is exactly the kind of discussion we want to start.
JA adds that we need to take special care about old versions of packs in case of “revocation” of a key or certificate.
CO shows how GPG could be used to sign packs
GPG creates .sign file for each .pack file
The .sign file can be served next to the .pack file (same base URL)
FR raises concerns about modifications to pack content after installation. This could happen a pack signature is only checked once during installation.
CMSIS Project Manager
RK presents documentation for today’s RTE folder usage. The background is PR #65 proposing to rename/relocate the RTE folder.
SH raises questions about the content and whether the content may or should not be modified by the user.
RK clarifies that the directory structure should not be changed by the user i.e., files should not be renamed. But the file contents in that folder are meant to be modified by the user.
RK explains the requirement to have a standard RTE folder layout because of tool interoperability i.e., when one moves a project from one tool to another (e.g., IDE vs. CI).
JK asks for background for the request to rename the folder.
SH states he would name it “one time generated” to make its purpose clear.
LM adds that by itself the name “RTE” is not known to STs ecosystem. For compatibility with existing tools, it would be preferable to be able to customize the name and location of this folder per project.
RK summarized that this would require us to record the actual name in the project.
Another level of flexibility for the content of RTE folder is discussed in issue #30.
RK presents a proposal for CMSIS Project Manager Access Sequence.
DB presents about his progress in managing layers.
RK highlights that in multi-project solutions one might require a combination of different “build-types” (i.e., release or debug) for enclosed projects. One might want to have release build for bootloader and secure firmware combined with debug build of non-secure firmware.
Structure of AWS Software Stack
RK presents the application demo “AWS Software Stack”. This working example shows how layers can be permutated into a variety of concrete projects.
Wrap up / Next Meetings
No meetings 21st, 28th Dec or 4th Jan
Next meeting will be 11th Jan 2022
JK closes the meeting and wishes happy Christmas to everybody.
NOTE: Open-CMSIS-Pack repository was renamed to Open-CMSIS-Pack-Spec