Open-CMSIS-Pack Technical Meeting 2022-06-14
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 https://github.com/orgs/Open-CMSIS-Pack/projects/2/views/1
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
