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.
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
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.
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.