Date: 03 September, 2018

TSC members

• Attendees
  • Masashi Kudo (Cybertrust)
  • Nobuhiro Iwamatsu (Cybertrust) (Representative)
  • Hidehiro Kawai (Hitachi) (Representative) (Voting)
  • HIroshi Mine (Hitachi)
  • Masato Minda (Plat’Home) (Representative)
  • SZ Lin (MOXA) (Representative)
  • Chris Paterson (Renesas)
  • Takehisa Katayama (Renesas) (Representative) (Voting)
  • Daniel Sangorrin (Toshiba)
  • Dinesh Kumar (Toshiba India)
  • Yoshi Kobayashi (Toshiba) (Representative) (Voting) - Chair

• Work towards finalising selection?
• Minimal, optimal or others?
• Discussion: Which package list will be submitted to Debian LTS?
• Daniel S. has interesting ideas about how to prioritise the list of packages we have collected.
  • These ideas, based on prioritising the list through security related criteria will be explained in the cip-dev mailing list.
  • Ben H. will evaluate these criteria and its impact before attending to DebConf.
  • Based on Ben H. feedback, CIP will decide to contact the Freexian leads before the DebConf or not.
  • AI(Daniel.S): Send to public mail list to get feedback. (DONE)
  • (On going. See above)
• Criteria for prioritizing security fixes:

1. Member package lists
   • List of packages (see “SHARED Package List - Pivot Table” tab)
2. CVEs with high “base score”, high “impact score”, high “exploitability score”, and low “attack complexity”
3. Network software (CVEs with “Access Vector (AV): Network”)
4. Security software
5. Language runtimes/compilers
   • OpenJDK may not be possible

• Comments
  • LTS: We should send package list with source packages
  • AI(Daniel S.): Ask to Raphael for the package list format.
  • Initial reference implementation with meta-debian however, we need to decide if we are going to use other build system (e.g. ISAR) for reference implementation and include more packages in the base layer.
• <SZ> There is a discussion thread in Debian to discuss the “armel/armhf arch qualification for buster (Debian 10)”
  • https://lists.debian.org/debian-arm/2018/08/threads.html#00009

• Reproducible builds
  • Action items
    • CIP
      • Speak to board members
        • Level of funding
        • Structure of contract
          • Specify the goals
      • (DONE) Submit package list which need to be reproducible
      • Ask to LF, how to make contract with RB (in Progress, 8/20)
    • September or October is the best timing
      • After freeze, it is difficult to make reproducible
      • RB need to have contract 3 month before the freeze
    • https://docs.google.com/document/d/1xhN5Wi5zyuocq4OtbSghfyHfrf0mGBrQ_t7JG_A6jwI/edit#
    • Need to approve in CIP Board
      • (9/3) YOSHI wrote a proposal in formal format and send it to CIP board members

• Discussed at DebConf to decide the structure of CIP kernel team
• CIP kernel team will focus both 4.4 and next CIP (4.20 or 5.0)
  • <SZ> When is the freeze date for backporting new features in kernel 4.4
  • Originally we say approx 5 years.
    • We have to make commitment how many years CIP allow to backport features
• CIP kernel team will structured with
  • 1 mentor (Ben H.)
  • 2 maintainers for CIP kernel (Iwamatsu-san and bootlin), 1 maintainer for CIP-RT (Daniel. W)
  • Other members from each company such as MOXA and Toshiba (Daniel S.)
  • AI(Kernel team members): Define milestone for next CIP kernel
    • Wait until which version Debian will choose.
• Kernel configuration
  • Initial blacklist has already prepared by Ben
  • RT will be clarified by Daniel W.
  • Config vs. Board
    • To be discussed
• AI(SZ): Ask to have weekly kernel team meeting at 5pm(JST) (Need to check time for other timezones)
  • Done. Please join the meeting.

US-West US-East UK DE TW JP

01:00   04:00   09:00   10:00   16:00   17:00
* Intel L1 Terminal Fault
  * [[https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html|https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html]]
  * Some fixes in 4.4.148
    * https://lkml.org/lkml/2018/8/16/229

• Originally it was thought that v4.20 (or v5.0) would be the next LTS. It now looks like v4.19 will be the next LTS Kernel - https://www.kernel.org/category/releases.html
• Does anyone have confirmation of the above from Greg?
• LTS v4.9 will now be supported for 6 years, perhaps v4.19 will be too.
• Does anyone know what Kernel Debian will be using? Or when they will make a decision?

• When will CIP make a final decision on the Kernel version?
• When does CIP plan to make the first cip-next release?

• What Kernel configs will we support?
• What hardware/reference platforms will CIP support?
  • All/subset of the current v4.4-CIP reference platforms?
  • Renesas RZ/G2M

(copied from above)

• 1 mentor (Ben H.)
• 2 maintainers for CIP kernel (Iwamatsu-san and bootlin), 1 maintainer for CIP-RT (Daniel. W)
• Other members from each company such as MOXA and Toshiba (Daniel S.)

• Transition to new CIP kernel maintainer
  • Where will the CIP repo be stored? Gitlab.com?
    • Before End of August
  • Maintainership permission and merge rules for the CIP kernel team
• ELCE 2018 kernel maintainers meeting?
  • (AI:Yoshi) CIP will have a kernel maintainers meeting at ELCE 2018
    • (9/3) Jeff is working to book a room for the meeting.
• L1tf mitigation patches expected for the coming CIP kernel release.

• [ACTION]We need a maintainer of the kernelci service.
  • Currently there are no CIP administrators for either server. Ideally member companies should do this. One admin? Or multiple admins?
• Distributed testing
  • KernelCI: https://kernelci.ciplatform.org/
  • Lava Master: https://lava.ciplatform.org/
  • Both of the above installations have default content. We need to personalise the servers for CIP.
  • B@D needs to be updated to submit results to KernelCI server.
  • Remote LAVA Labs need to be integrated into the Lava master.
• For B@D updates please follow the journal.

• Completed: Run Docker with CIP Core plus additional packages from Deby (meta-debian)
  • Next: Try to run EdgeX demo on the filesystem
  • Issue: CIP-core need to have public IP address
• OOM killer kills services because of low-memory machine

• Started to use new roll management (Thanks, Agustin)
  • TSC representatives from each company will be owners, as well as the tool admin, at group level.
  • We will have no group maintainers by default since we will not have repos at this level but we will enclose them in subgroups. So at this group level we will provide Developer or Reporter roles only to CIP participants.
  • We assign the maintainer role to those who should have it, because they are responsible of a specific area, at subgroup level.
  • Specific people can hold the maintainer role at repo (project) level based on the subgroup maintainer decision.
• FYI: Rules for new repository creation or new project launch