Open-CMSIS-Pack Technical Meeting 2022-06-14

Owned by Joachim Krech, created
Last updated: Jul 04, 2022 by Bill Fletcher
5 min read

 Participants

Joachim Krech

Luís Tonicha

Daniel Brondani

Reinhard Keil

Shebu Varghese Kuriakose

Vincent Grenet

Evgueni Driouk

Maxime Dortel

David Jurajda

Jaeden Amero

Kyle Dando

Marc Goodner

Randy Linnell

Holt Sun

 

 

Slides

Digital Signature Presentation from Luis (Linaro)

Meeting Notes

JK: Let’s take a look at the change board: “Pack Specification Change Board“

Luis from Linaro will present a proposal for Digital Signatures for Packs

We will go through a list of issues: “Request for Review​”

Then we will wrap up and give some information about the up-coming meetings

 ED: Short announcement: the eclipse plug-in has been published today. CMSIS-Pack Eclipse Plug-ins 2.7.0

 

JK: First thing I want to take a look at the change board.

·         Change Board​ Open-CMSIS-Pack Specification Change Board • Open-CMSIS-Pack

 

JK: I created the PR #136 with changes to the pack.xsd schema as well as the documentation for addressing the components license gap.

Please go and review the proposed changes.

·         Component Licenses Gap - PR #136 Issue #24

 

JK: Then I have the issue #124, we want to have a final discussion here, whether or not board memory should be captured in rzone files, or we should extend the board specification.

RK: Today we don’t have several ST guys, they apologized they can’t join, should we just discuss it right now?

JK: If we can’t decide today, I would suggest we reschedule it for the next meeting, we should then wait for Fred and other people from ST.

·         Board specific memory in board support - Issue #124

 

JK: Then issue #131, this is another think I suggest to delay, the reason for that Fred raised whether or not we need a general extension to conditions. Since we haven’t concluded on that, I don’t think it’s ready to be reviewed by the decision committee.

·         Component dependency on board - Issue #131

 

JK: Then there is a new one Reinhard has created issue #134, I would like you to present it today.

RK: This proposal is to have in pdsc file a csolution element that allows to copy projects, pre-built images, or software layers to a csolution or cproject file.

This is the first incarnation, it allows us to work with known board layers and images, it has not yet the notion of interfaces.

·         Add <csolution> element to *.PDSC format - Issue #134

·         Including csolution examples in Packs - Issue #122

 

JK: Proposal: signed Packs for cpackget presented by Luis

LT: I worked on this proposal with Charles, this is the first formalization of the feature about digital signatures for cpackget.

In the current status cpackget installs and manage the lifecycle of packs, no security checks are performed other than warning about non-HTTPs public indexes.

Objectives: check integrity of packs, authenticity, dynamic configuration

Background concepts: public key encryption scheme, X.509 protocol

Proposed approach – companion tool for cpackget (cpacksec) for signing and verifying, not affecting cpackget’s scope.

Infrastructure – Main CA, Vendor Certificates, Pack Certificates

Add pdsc attribute “vendor-certificate-url”

Alternative: separate signature/digest file

Configuration file per pack root to tweak security features

Possible points of failure: Main CA, Certificate Hosts, Public Indexes

 

Questions:

DB: What’s your view on public indexes security? Should it be also signed or relying on HTTPS server would be enough?

LT:  That’s the base of the chain of trust, we could enforce HTTPS for public indexes, but it is also complicated because you always need to have some sort of basic trust somewhere in the infrastructure. There might be a more elegant solution, if anyone has any idea that would be great.

 

JK: When you talk about public index, do you make a difference between vendor.pidx files which list vendors public packs, or are you talking about a service that runs and collects all the things into index.pidx, or is that the same?

LT: I am more focused on the vendors because they would have the digest files in itself

 

RK: We could have multi-purpose of the signature file, cpackget could have a verify feature where the integrity of the pack is validated, what do you think?

LT: The integrity is part of the proposal, it’s a win-win in this case, security-wise we can guarantee the pack is exactly what is expected from the vendor and we can also check local installations.

 

Request for review:

JK: We have updated the issue #324, Reinhard has updated the documentation to capture that, if you have any comment please take the opportunity.

·         Issue #324 – RTE Configuration file PLM

 

JK: There was a discussion about how to handle Cclass with pre-defined list or not and so on. I think we should be clear we continue to have Cclass being extensible. For helping the discovery of components, we agreed to have a feature extension to categorize components using different ways.

·         Issue #135 – Restrict Cclass values to pre-defined list

 

JK: On issue #179 we still need to agree on things like debug, optimize, warning.

·         Issue #179 (#120) – Toolchain independent configuration

VG: I think we have to clean up the schema.

RK: Vincent, what are the steps you propose?

VG: We have discussed that with Tarek, we will revisit it and try to find and agreement.

RK: We should first come up with the terms we want to use, explain what is behind these terms and then start implementing it.

JK: It means create a new PR after that, would you agree?

VG: Yes we can move this way.

DB: That sounds good.

RK: An alternative solution is the cdefault file with compiler settings. For standard classic examples that might be good enough.

VG: Is the cdefault file workspace or csolution level?

RK: That’s not defined yet.

 

JK: On the topic regarding versioning #126, I feel it’s a significant feature change, I think we need to prepare a proposal to go through the decision committee.

·         Issue #126 – Relaxing schema for pack versions

DJ: We are discussing components versioning internally and there is no agreement yet, just tried to capture the concerns that we have.

There is difference between pack and component version. Would we use pack versions in conditions or dependencies?

JK: We don’t have it today at least, if this may become a requirement I can’t tell.

 

JK: We need to stop here.

No meeting next week (21.05.2022) due to Embedded World 2022 in Nuremberg​

CMSIS partner meeting in Nuremberg, Monday 20.05.2022 16:30 (CET)​, please register to confirm your attendance​.

We are currently proposing to pause weekly technical project meetings from 26.07.2022​ until 16.08.2022 (“Summer Vacation time”)

Please let me have your feedback if you are concerned about that.

 

Next Open-CMSIS-Pack meeting: 28th June 2022  @ 16:00 CET (15:00 UK)​

Meeting Recording