Hi All, Please find the March 17th TSC minutes below. Dan's slides regarding Github from the meeting are also attached. Best regards, Don ========================================================

Attendees: Don Harbin, David Brown (Linaro), KangKang Shen (Futurewei), Antonio De Angelis (Arm), Dan Handley (Arm), Shebu Varghese Kuriakose (Arm), Andrej Butok (NXP), Anton Komlev (Arm), Kevin Oerton (NXMLabs), Dave Rodgman (Arm), Julius Werner (Google), Kevin Townsend (Linaro), Eric Finco (ST), Okash Khawaja (Google)

Actions:

-

Anton: Check feasibility of changing PSA Crypto header folder name. -

Anton: Gauge interest in various GitHub options for TF-M

Minutes:

MBed TLS Roadmap (Shebu): Presented his slides

-

Continuing to look for support from members in the review role since there’s a large load. Several members have stepped up - could still use some additional support. -

Kevin Townsend: Have we made any progress making PSA Crypto headers work across projects? -

Anton: No mismatch between MBed TLS v3.1.0 and TF-M -

Antonio: TF-M’s headers are good now. Public headers are aligned between TF-M and MBed TLS. Some headers are private to implementation, so there’s not much we can do there. -

Andrej: Can we change the folder name for one of the projects, so that we don’t get conflicts in projects that build both sets of headers? Could be either Mbed TLS or TF-M, but it’s important for them to be different. Tfm_psa for example. -

ACTION Anton: Check feasibility of changing PSA Crypto header folder name. -

Dave Rodgman: Getting good engagement/involvement. Agree review contributions are very helpful -

Andrej: What is the best place for companies to upstream their own PSA Crypto drivers? -

DaveR: Mbed TLS doesn’t plan to host h/w specific drivers. -

Andrej: Somewhere in TF-M or create own repo? -

Antonio: There are some PSA Crypto drivers in TF-M platform folder. Would this make sense? -

Andrej: What about products that don’t use TF-M? -

Andrej: Could provide in own SDK or a separate repo on github. We’ll probably go with the latter. We’re getting customers wanting to use the upstream. -

Anton: TF-M allows use of external projects. Github seems the right place. -

DanH: In future there may be value in TF.org providing full platform stacks where stuff like this could live. Part of the problem here is that TF-M and TF-A already have platform interfaces and host platform code, but Mbed TLS is a generic library with no platform interfaces. -

Shebu: We also need to get MBed TLS tested on real target h/w in Open CI -

See the MBed TLS roadmap for more. -

Don: reminder - new FAQ points to roadmaps page: https://www.trustedfirmware.org/faq/

Current GitHub Status: Dan Handley

-

Presented status slides -

Dan: Will be moving MBed TLS repos to a TF-owned org account vs Arm-owned in the next few weeks. -

Dan: TSC previously decided that all TF projects should have a GitHub presence, even if some projects (e.g. TF-A) retain Gerrit for review -

Andrej: Was this a TSC decision? -

Dan: Yes. Unfortunately progress got blocked on funding an investigation into a hybrid Gerrit/GitHub solution. But other solutions are possible. -

Dan: NXP/Linaro especially keen for TF-M to move to GitHub -

Andrej: Would like TF-M to fully move to GitHub (not just a read-only or hybrid solution) -

Andrej: Agree it will help contributions. We believe this will make TF-M more popular -

David Brown: Recently had difficulty creating a simple change for review. GitHub will remove blockers in pushing changes. -

Dan: GitHub access from China is more difficult, but solvable with VPN -

Antonio: Could have a repo mirror in TF.org infrastructure to remove the VPN dependency? -

David: Providing a read-only mirror is simple enough -

Dan: But what about providing a seamless GitHub experience. -

David: That’s a much harder problem to solve. -

Andrej: MBed TLS doesn’t have a problem, then it should be OK for TF-M as well -

Dan: It’s a problem for all GitHub projects -

Kangkang: Most big China companies have their own VPN. Mainly a problem for smaller companies. -

Dan: Even if we decide that fully migrating to GitHub is the way to go, this requires a lot of work from Arm to move internal systems to GitHub, which we can’t do for some months. Could we create a read-only mirror as a stepping stone and see if this improves engagement? -

Kevin: We won't be able to measure success from a read-only mirror, but it’s still a good stepping stone. -

Antonio: Can at least measure attempted pull requests, even if they can't be merged. -

Kevin: It would also be useful to link to GitHub from related projects. -

Dan: We should also check if fully moving to GitHub eventually is what TF-M contributors want -

ACTION Anton: Gauge interest in various GitHub options for TF-M -

DanH: Secondary issue is our dependency on deprecated Phabricator. GitHub provides a solution for migrating content out. -

Agreement: Pursue the read only mirror. Objections? -

None heard.