Date: 20 August, 2018

TSC members

• Attendees
  • Agustin Benito Bethencourt (Codethink) (Representative)
  • Masashi Kudo (Cybertrust)
  • Nobuhiro Iwamatsu (Cybertrust) (Representative)
  • Masato Minda (Plat’Home) (Representative)
  • HIroshi Mine (Hitachi)
  • Hidehiro Kawai (Hitachi) (Representative) (Voting)
  • SZ Lin (MOXA) (Representative)
  • Dinesh Kumar (Toshiba India)
  • Yoshi Kobayashi (Toshiba) (Representative) (Voting) - Chair

• Kernel development for next CIP kernel
  • (On going) MOXA: Send the board support package to upstream
    • SZ: Moxa will send kernel patch to mainline kernel before 8/E
• Spectre/Meltdown
  • Arm vulnerability list: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
  • AI: tidy up this information
    • Discussion with partners internally
    • May be in the next meeting
  • Kudo-san
    • CTJ created S/M patches internally
    • When CTJ finish the test, CTJ will post the patches to GregKH.
    • Estimated schedule: not fixed yet.
• CIP Core package list
  • AI(Daniel.S): Send to public mail list to get feedback from Ben. (DONE)
    • [cip-dev] [CIP Core] Criteria for prioritizing security fixes in Debian LTS
    • https://lists.cip-project.org/pipermail/cip-dev/2018-July/001398.htm
    • Already submitted to Reproducible builds
• AI(Yoshi): Ask to LF to join TSC meeting.
• AI(Wolfgang): Contact to Daniel W. to become next CIP-RT maintainer

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

• 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

• https://2018.coscup.org/en/programs/civil-infrastructure-platform/
  • Attendees: 30 ~ 40
    • An attendee is asking us about communication roadmap (5G, LPWAN, etc..)
    • NB-IoT(One of 5G technology)
• Attendees: COSCUP 1000+

• 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
    • Need to approve in CIP Board

• 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)
• 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
• 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

• Transition to new CIP kernel maintainer
  • Where will the CIP repo be stored? Gitlab.com?
  • 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
• L1tf mitigation patches expected for the coming CIP kernel release.

• Containerization of B@D in progress (no significant news).
• Dropped support to Windows in B@D

• Trying to run Docker on CIP Core.
  • (Yoshi) Toshiba has an experience to install it but not sure for me how to do it. ;(
• 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

• Proposal from 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.
• AI(Yoshi): Ask for approval for the new repository rolls policy.
• FYI: Rules for new repository creation or new project launch