Base Libs FT - Meeting Minutes Safe JSON library #2 - [2025-06-11]

[mishu-dev]

Safe JSON library

Participants

Felix Moelders
@mishu-dev
@alexandruiulian10
@4og
Paul Sherwood
@masc2023
Ankur Satle
Andreas Kaluza
Holger Braun

Meeting Minutes

• Process for qualifying baselibs libraries

  • software development most workload
  • trustable software framework – basis for analyzing specific things
    • TSF integrated into the process score repo
    • Integrate library where TSF can be executed – generate the evidence and analyze
    • What is the required from the library for score
    • It will generate information if the software is trustable
    • Target of the TSF is to set an guideline
    • Was set as a base for a practical project that can be certified
  • Nlohmann delivers the functionality that we need
  • By stripping code we will diverge from the origin
  • Analyze what is the interference that is not needed creates (minimize forking)
    • And lockdown if interferes with our functional path
    • Or document if it doesn’t interfere
  • A lot of MISRA rules are not applicable to score
  • Nlohmann is delivered to high quality without full MISRA compliancy
  • Templates for the arguments

• We need to strip anything that is not needed

• If we need misra compliancy we will need to change the library

• We should fork – create draft with the arguments

• We can start with mapping of the arguments and analyze the gap

• https://eclipse-score.github.io/process_description/pr-27/trustable/index.html

• High level requirement for external software in regard of expectations

• We need to provide answers and arguments in form of texts for all the questions from trustable software
  - Ex tools: Docs score
  - Ex of question: does nlohmann behave as required: provide coverage results , positive , negative tests
  - Generate arguments and link to the tenets why they aare or not fulfilled
  - Ex: https://gitlab.com/richardmaw-codethink/safety-monitor/-/tree/main/trustable?ref_type=heads

• What happens when we can not find an reasonable argument -> code changes

• If fixes are needed we need to raise first in the upstream?
  - Data analysis on the functional issues

• Arguments can be that we follow the score process for example
  - Can be traced as sphinx needs to the requirements or to standard ISO

• Similar experience with tiny json

• Lines of code can be evidence: example: https://eclipse-score.github.io/process_description/pr-27/folder_templates/modules/module_name/component_name/docs/component_classification.html

• Let’s consider that write is not needed (it is needed for persistency):
  - Ex: we can set a new interface that exports only read functionality
  - Also argument that write does not affect read
  - This meeting will be moved in the regular baselibs recurrent meetings

• write is needed for persistency

• we also need to officialize the write functionality

• How to do the changes?