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

Participants

Joachim Krech

Luís Tonicha

Bill Fletcher

Jaeden Amero

Silvio Lucio Oliva

Mario Pierro

Daniel Brondani

Sourabh

Reinhard Keil

David Jurajda

Vincent Grenet

Samuel Hultgren

Eric Finco

Frédéric Ruellé

Evgueni Driouk

Reed Hinkel

Kyle Dando

Holt Sun

Slides

cpackget 0.8.0 new feature presentation (Luis / Linaro) about signing packs

Meeting Notes

Change Board

#144 Part Description - issue added

#120 - issue removed (closed)

Need to schedule next Decision Committee (action Bill, Joachim)

#450 Local support in cproject.yml for build-type and target-type - asking for review

#112 Visibility/Hidden Proposal

FR: auto vs visibility. May be a choice that needs user selection but the component could be ‘glue’ that is not normally shown to the user. Also in Holt’s example, what if there are 3 choices for usb.common?

RK: Think there is a problem with the auto attribute.

FR: “Visible” is only a possibility - based on context. Don’t hide it if there’s a user choice required. Don’t want to force them to be hidden. The attribute is an indication to the tool. Agree that it can still be automatically selected.

DJ: It’s only for the GUI, it shouldn’t affect dependency resolution.

RK: Looks like we need both auto and view attributes.

FR: Understand the need - see it as a different topic. Auto is not related to PDSC.

RK: Some components are never referenced because they are only user choices.

SH: Reference property would say this is a user choice.

JK: Decision is let’s stick with separation of concerns. Have this as for the GUI and a separate issue for user selected.

FR: csolution and not PDSC behaviour.

RK: NXP has some components that are not (ever) exposed to the user.

ED: What if a hidden component has a conflict?

JK: Some operations will always show components regardless of this attribute. Never can’t mean never.

FR: csolution is managing the project not the UI. Also the filesystem filtering is different to GUI.

JK: Haven’t really concluded. Think we should create a new issue for dependency resolution.

#434 Pack Lockfile - people should take a look

EF: Do you think we could move it to the CCB?

RK: Have not specified the reference yet. Should review for completeness.

SH: Think it looks good. A bit unclear when we refer CMSIS pack root. Maybe call it pack location.

#76 Revised requirements from ST

#328 Would like to get some review feedback. Confirmed Daniel will look at it this week.

#351 Defect in the documentation. Should conclude if it’s ‘,' or ';’ or both.

#115 Open the Door to More HW Descriptions

RK: Can you explain the requirement?

EF: Pointing at #144 and #147.

FR: Think we can close it (Action FR).

Feedback to “Pack Generation”

KD: Need to choose a platform (with TrustZone). Don’t have CDI or other common APIs.

RK: Will try to make the example work with and without TrustZone.

cpackget v0.8.0 Demo

FR: (via chat) To me the problem is never the signature, but how to trust the keys you use... PGP requires you to decide if you trust it or not when you receive a key from someone. We are back to what we discussed with Charles

You should never do a verification with private key. The problem is : how can I trust that this key is correct ? Why would I trust it ?

Open-CMSIS-Pack