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.
Hi all
We have 2 topics so far for the TSC meeting tomorrow. Please let me know if you have any more.
* Mbed TLS roadmap
* Continuation of the "Using GitHub" discussion (especially for TF-M). This got bounced back from the board to the TSC.
Regards
Dan.
