Architecture Community Meeting Minutes 2026

[qor-lb]

All official meetings in 2026 will be documented in this thread. So if you subscribe here, you'll get summaries of the meetings you missed.

[qor-lb]

The following meetings can be found in the "old" discussion from 2025:

• Weekly 2026-01-05
• Weekly 2026-01-12

[qor-lb]

Weekly 2026-01-19

Participants

• @qor-lb
• @arsibo
• @RolandJentschETAS
• Tracy
• Isabella Stilkerich
• @odra
• Shorouk Ramzy
• @timkl7
• wenxian.ma
• @AThums
• Matthias Schulze
• @vevmaki
• Alexander Mohr
• @dasoho
• @mbejijou-dev
• Kris Zhu
• Abhishek Goyal
• @tbreckle
• baheer.fz
• @HartmannNico
• @thilo-schmitt
• @4og

Agenda

1. Announcement: new meeting minutes thread for 2026
2. Welcome ECARX & [Contribution Proposal] Time (ecarx) #2426
3. Timeslot for Time contribution pitch - [Contribution Request] Time #1765

Meeting Minutes

to 3.

• targeting first week of feb - @qor-lb to create poll

Misc

• @timkl7 will leave S-CORE - thank you very much for your contribution!

[qor-lb]

Poll for 3. can be found here: https://github.com/orgs/eclipse-score/discussions/2458

[qor-lb]

Weekly 2025-01-26

Participants

Agenda

1. Reminder: Poll for the time slot for [Contribution Request] Time #1765 - https://github.com/orgs/eclipse-score/discussions/2458
2. Status Rust: what is the current status of the Rust evaluation (@AThums )

Meeting Minutes

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on Feb 2nd.

[qor-lb]

Weekly 2025-02-02

Participants

• @qor-lb
• @AThums
• @arsibo
• @vbogdanb
• @odra
• @ramceb
• @RolandJentschETAS
• @BlueXMarv3l
• @vevmaki
• Vadim Selinger
• Praveen gudi
• Ahmed Elaska
• @basheerFZ
• Gao Chenhao
• Kris Zhu
• Mina Hamdi
• Peng Zhu
• @tbreckle
• VPeddina
• Wenxian Ma

Agenda

1. Time slot for [Contribution Request] Time #1765 - Friday 6th Feb 9 - 12 CET (see poll)
   2. agenda & meeting link: https://github.com/orgs/eclipse-score/discussions/2526
2. @arsibo - Unify S-CORE source folder module_template#40
3. @vbogdanb - snap shots in persistency required?

Meeting Minutes

to 2.

• please review the PR - after closure update the module template & roll out across modules

to 3.

• @vbogdanb to create decision record and link the PR here
• together with DR, the requirements need to be updated

[qor-lb]

Weekly 2026-02-09

Participants

Agenda

1. Minutes/outcome 2026-02-06 Time Contribution Pitch

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on Feb 16th

Meeting Minutes

[aschemmel-tech]

Weekly 2026-02-16

Participants

• @aschemmel-tech
• @basheerFZ
• Johannes Lex
• @ramceb
• @odra
• @RolandJentschETAS
• Shorouk Ramzy
• @timkl7
• @qor-lb
• satoshi kaneko
• Vadim Selinger
• @vevmaki
• @arsibo
• @Abhishek2581
• @FScholPer
• Vamsi Krishna Pattabhi
• @vinodreddy-g
• Isabella Stilkerich

Agenda

1. Minutes/outcome 2026-02-06 Time Contribution Pitch
2. OS integration, @aschemmel-tech presents: OS module requirements and AoU #2515

Meeting Minutes

to 2.

• approach and proposal pesented by @aschemmel-tech
• related to OS tier levels + AutoSD as a community OS  #2266 breakout

MISC

• Q: should we enable a separate on-boarding of the toolchain independent from the OS (context OS tier levels + AutoSD as a community OS  #2266)
  • We should use pragmatism here: if we have a dedicated use-case that requires this, lets discuss on this baseline. Until then we keep them closely coupled with the OS

[qor-lb]

Weekly 2026-02-23

Participants

Agenda

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on March 2nd.

Meeting Minutes

[basheerFZ]

@Frank Scholter Peres @Lars Bauhofer LGElectronics will be making the Vehicle Service Orchestrator (VSO) PITCH on todays architecture community meeting as requested in lifecycle meeting last week

[qor-lb]

Weekly 2026-03-02

Participants

Agenda

1. @basheerFZ - Feature Request for Vehicle Service Orchestrator #2597 & vso: create initial draft feature request [#2597] #2601
2. Announcement: Conclusion Rust for Safety Critical Components within S-CORE: Friday 2026-03-06, 9:30 - 10:30 CET

Meeting Minutes

to 1.

• Chulhee Lee presented project proposal for Timpani
• Review of vso Feature Request until next weekly

[basheerFZ]

PFA the pitch material for VSO @qor-lb
Eclipse SDV Community Day 2026_LGE-Timpani_0224_v1.0.pdf

[basheerFZ]

PFA the pitch material for VS
Uploading Eclipse SDV Community Day 2026_LGE-Timpani_0224_v1.0.pdf…
O @qor-lb

[qor-lb]

Weekly 2026-03-09

Participants

Agenda

1. Announcement: DR-001-Arch: Rust Readiness for Safety-Critical Components
2. @basheerFZ - Feature Request for Vehicle Service Orchestrator #2597 & vso: create initial draft feature request [#2597] #2601
3. Next F2F meeting

Meeting Minutes

to 2.

• @basheerFZ presented the feature request wrt. overlap of functionality to the lifecycle & orchestration functionality
• The VSO is proposed to operate on a higher level than lifecycle & orchestration, therefore a feature modification was not considered
• In general the relation between VSO and other stack functionalities is not yet clear and needs further refinement in the feature request
  • (demo to make the context more clear is very appreciated)

to 3.

• related to [Contribution Requests] Identify maintainer for the 1.0 (2nd round - 28th (& 27th) April 2026) #1891
• @qor-lb to create poll to finalize timeframe for F2F (target CW16 - 18)
• @qor-lb to reach out to X-CORE to announce contribution request
• Evaluate end of march available contribution pitches to decide if it makes sense to meet f2f

[qor-lb]

Weekly 2026-03-23

Participants

Agenda

1. [Contribution Requests] Identify maintainer for the 1.0 (2nd round - 28th (& 27th) April 2026) #1891
   • LinkedIn Announcement via X-CORE
   • Polly to finalize timeframe - vote before 30th March (limitation due to free plan)
   • 7th of April to evaluate if it makes sense to meet f2f or online
2. @odra : OS images
3. Current open feature requests

Meeting Minutes

to 1.

• @anmittag to verify if ETAS location is available for all f2f option

to 3.

• Feature Modification for Cross-VM One-Way Sharing & Streaming #1715 to be included in the contribution requests (@qor-lb)
• @qor-lb to triage Feature Requests / Modification & FEPs (view)

[clemens-k]

Weekly 2026-03-30

Participants

Agenda

1. [Contribution Requests] Identify maintainer for the 1.0 (2nd round - 28th (& 27th) April 2026) #1891
   • finalized timeframe -> 27th & 28th April
   • 28th confirmed for ETAS Location (27th optionally possible if the agenda contents permit)
   • 7th of April to evaluate if it makes sense to meet f2f or online
2. Next weekly (6th April) will be skipped: public holiday in germany
3. @clemens-k Heap avoidance strategy of S-CORE. It looks like the strategy is:
   • avoid heap operations after initialization of processes (enter Run() or after reported kRunning)
   • exception strategy: avoid on s-core interfaces (use score::Result, but handle them for c++ lib apis)
4. @antonkri - diag & someip proposal from LG

Meeting Minutes

to 3.

• error handling strategy defined within the coding guidelines - heap strategy not yet defined
• @clemens-k to create a proposal for the heap strategy in the coding guidelines
• @LittleHuba offered support - some definitions already available within baselibs/BMW infrastructure

to 4.

• no participants available to discuss the topic - deferred to next weekly

misc

• @LittleHuba versioning strategy for external dependencies
  • decision record required -> focus on versioning of external dependencies not so much on allowance of external dependency variance within the modules of s-core (might require separate dr)

[arsibo]

Weekly 2026-04-13

Participants

Agenda

1. [Contribution Requests] Identify maintainer for the 1.0 (2nd round - 28th (& 27th) April 2026) #1891
   • Poll for security breakout
   • Exclusion from 1.0 scope due to missing maintainer: [Contribution Request] GenAI #1767, [Contribution Request] AI Platform / Inference Engine #1768 and [Contribution Request] Modification for Cross-VM One-Way Sharing & Streaming #2730
2. @basheerFZ - Presentation of the PoC Vehicle Service Orchestrator (VSO): https://github.com/MCO-PICCOLO/s-core-poc/
3. Chulhee Lee - security, fault manager & someip proposal from LG
4. Abhishek2581 - Feature Request DDS DDS gateway #2726
5. Misc FR - Feature Request: Vehicle External Control Interface (VECI) #2751 & Feature Request: Vehicle Agent Collaboration Protocol (VACP) #2752

Meeting minutes

to 1.

• Incubation of 1.xff features is still possible (but not in the main line)

to 2.

• @basheerFZ presented VSO PoC
• Timpany in Node 1 mainly intended as Vehicle State Management interface
• PoC does not consider integration of Pullpiri in S-CORE environment
• Next steps:
  • @basheerFZ clarify if VSO Feature Request is "only" Vehicle State Management or if further integration with Pullpiri is desired
  • @ramceb / @basheerFZ to break-out in Lifecycle FT to discuss extension of Lifecycle conditions

to 3.

• Security Pitch to be added to [Contribution Request] Security & Cryptography #2054 (Chulhee Lee / @basheerFZ)
• SomeIP stack proposal - replacement to vsomeip - to be added to [Contribution Requests] Identify maintainer for the 1.0 (2nd round - 28th (& 27th) April 2026) #1891 (Chulhee Lee / @basheerFZ)
• Fault manager proposal to be added to to [Contribution Requests] Identify maintainer for the 1.0 (2nd round - 28th (& 27th) April 2026) #1891 (Chulhee Lee / @basheerFZ)
  • clarification of scope and location - integration to OpenSOVD or replacement proposal?

[basheerFZ]

We would like to clarify on the comments captured for the below items
for ,Timpany in Node 1 mainly intended as Vehicle State Management interface --> check below comments
[LG comments]

1. Pullpiri manages the entire vehicle statemgmt , here Timpani plays the role of Global Scheduler in a multi node environment ,it can operate in local node environment also .

for ,PoC does not consider integration of Pullpiri in S-CORE environment. --> check below comments

1. Currently we have integrated both Pullpiri and Timpani in the current PoC with score, All the VSO demons are nothing but pullpiri components
2. S-Core launches all the VSO Demons and Timpani components in the current PoC.
   PFA the demo poc material
   20260413_S-Core VSO PoC v0.3.pdf

[qor-lb]

Weekly 2026-04-20

Participants

Agenda

1. 2026-04-27 8:30 - 12:00 CEST Security Contribution Pitch
2. 2026-04-27 14:00 - 17:00 CEST LGE Contribution Pitch for Some/IP & Diagnostics
3. Canceling 2026-04-27 due to parallel pitches

Meeting Minutes

[qor-lb]

2026-07-13

Participants

Agenda

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on July 20th.

1. [DR-002-Proc] Implement FEP process #3061

Meeting Minutes

[anmittag]

@qor-lb Agenda Point for next time: decisions on the open feature proposals/request?

[basheerFZ]

@qor-lb Agenda Point for next week: we can add the VSO FR final conclusion proposal with further course of action with recommendations from the community members. (we would like to see if any other community members have any other feedback based on last weeks discussion).
This you can add as one of the agenda.if we dont receive any comments then we can summarize it and finalize it based on yours and @FScholPer comments.

[anmittag]

2026-07-20

Participants

Agenda

1. [DR-002-Proc] Implement FEP process #3061
2. @basheerFZ VSO FR final conclusion: Suggestion: as VSO is above the scope of S-CORE it is recommended to create a separate ECLIPSE Project for it
3. @anmittag Exploration: Lightweight Container Execution for Automotive ECUs (Eclipse SSAM)

Meeting Minuts

to 2.

• concluded as suggested; VSO will be setup as a separate project integrating S-CORE
• Additional alignment/interfaces to enable the VSO functionality can be directly discussed within the respective Feature Teams

to 3.

• @FScholPer to align on potential split of lifecycle architecture to ease future feature requests around containerization
• Afterwards alignment on feature request/scope extension via newly proposed FEP

[arsibo]

Regarding point 2. #2601 (comment)
Regarding point 3: A presentation on the FT lifecycle is required. What are the supported standard interfaces? The containers should not be proprietary and must also run on alternative container runtimes.

[qor-lb]

Weekly 2026-07-27

Participants

Agenda

1. Walkthrough Feature & Enhancement Proposal (FEP)
2. Review open FEPs: Feature Requests / Modification & FEPs
3. @anmittag - What is accepted and is not in progress? Feature Requests / Modification & FEPs (view)

Meeting Minutes

to 3.

• Decision: retroactively roll-out FEP for already closed Feature Requests. Feature Request implementation tracking is then with the existing Feature team lead. Feature Requests that didn't have any contribution/FT will stay in the Accepted state. Feature Requests that did a successful call for contribution round and established a Feature Team will move to the Implementing phase and track the implementation towards 1.0.

[Haishi2016]

We'd like to add slots to present/discuss proposals: Vehicle External Interface (VECI) and Vehicle Agent Collaboration Protocol in the next meeting

[qor-lb]

Weekly 2026-08-10

Participants

Agenda

1. @RolandJentschETAS - Clarification on header/source structure for c++
2. @Haishi2016 present/discuss proposals: Vehicle External Interface (VECI) and Vehicle Agent Collaboration Protocol
3. Review open FEPs: Feature Requests / Modification & FEPs

Meeting Minutes

to 1.

• Discussion: separating header & source in the folders into src & include vs. keeping them in the same location as currently lived in baselibs & communication
• Currently no clear guideline established within S-CORE across the modules -> extension to coding guidelines & decision needed
• Next step: Setup DR to clarify decision
  • @LittleHuba / @crimson11 potentially provide input to the motivation for choosing keeping header & source in the same folder
  • @RolandJentschETAS to setup decision record to consolidate the opinion
    • Created a DR see https://eclipse-score.github.io/score/pr-3196/design_decisions/DR-003-arch.html

to 2.

• Vehicle External Interface (VECI); evaluate reference information for potential touchpoints with the FEP
  • Existing Features such as https://eclipse-score.github.io/score/main/features/lifecycle/index.html & https://eclipse-score.github.io/score/main/features/configuration/config_mgmt/index.html
  • Previous VSO FEP: vso: create initial draft feature request [#2597] #2601
  • Existing standards/implementations such as COVESA Vehicle Information Service Specification (VISS)
  • Afterwards: create PR for DR according to FEP Guide
• Vehicle Agent Collaboration Protocol
  • Existing Features such as https://eclipse-score.github.io/score/main/features/ai_platform/index.html

[RolandJentschETAS]

Weekly 2026-08-24

Participants

Agenda

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on August 31st.

1. PR Design decision include path: https://eclipse-score.github.io/score/pr-3196/design_decisions/DR-003-arch.html

Meeting Minutes

Misc

[Abhishek2581]

From the Valeo side, we would like to add “Clarification of FR Shepherd role and effort expectations” to the agenda.

[RolandJentschETAS]

Weekly 2026-08-31

Participants

Agenda

1. PR Design decision include path: https://eclipse-score.github.io/score/pr-3196/design_decisions/DR-003-arch.html (add design decision include path #3196)
2. From the Valeo side, we would like to add “Clarification of FR Shepherd role and effort expectations” to the agenda.

Meeting Minutes

1. Anyone should review the pr-3196 and give his comment. -> The name collision shall be clarified in another DR.
2. The main effort is to the feature requester and the shepherd only guides to community and the process. -

Misc

[qor-lb]

Weekly 2026-09-07

Participants

Agenda

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on Sept 14th.

Meeting Minutes

[arsibo]

Weekly 2026-09-14

Participants

Agenda

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on Sept 21th.

Meeting Minutes

[qor-lb]

Weekly 2026-09-21

Participants

Agenda

1. @FScholPer - FCP for Propose DDS communication support for mw::com #3263 / DDS gateway #2726
2. @RolandJentschETAS - add design decision include path #3196
3. Andreas Zinkl - NM Feature Request
4. Review Feature Requests / Modification & FEPs

Meeting Minutes

to 1.

• @FScholPer to confirm when ready for FCP - @qor-lb to announce FCP via slack afterwards

to 2.

• Main concerns are resolved, review from broader community required before final merge
• Decision: use the FEP process also for non-functional changes such as this DR
• wish to extend tooling support similar to release process
• next step: @qor-lb to onboard to FEP; @RolandJentschETAS as the author; @LittleHuba as the shepherd

to 3.

• NM within shared source repository COMASSO
• Challenge: COMASSO is shared source only and not open source, therefore S-CORE cannot contain the FEP that discusses the NM architecture or implementation. In case of a desired integration with Communication, we could only discuss proposals for generic plugins but the integration has to be considered within COMASSO.
• Next step: Andreas Zinkl to raise a FEP to clarify also the interface between COMASSO and S-CORE with the practical example NM

[qor-lb]

@RolandJentschETAS for 2. I have created #3269 to track the FEP (DR & Implementation).

[qor-lb]

2026-09-28

Participants

Agenda

1. First FEP in FCP & new FCP mechanics: add design decision include path #3196
2. When to create incubator repos: https://sdvworkinggroup.slack.com/archives/C08C1HG5AKY/p1790241436062769
   • Before the FEP or after
3. Review Feature Requests / Modification & FEPs

Meeting Minutes

to 2.

• Options considered (use case: idea for FEP content is not yet clear and needs "incubating" before the write up)
  • Private repository in company context
    • ruled out due to inability to discuss idea with broader community & losing the git history
  • Public repository in company context
    • pro: S-CORE repo only track agreed scope
    • con:
      • accessibility of S-CORE toolchain is "complex"
      • chance to become a submarine activity
      • higher hurdle to keep git history after acceptance/transfer
  • Incubator repository in S-CORE
    • pro: easier availability of S-CORE ecosystem
    • con: might lead to a lot of stale repos (if used excessively)
• Original incubator purpose: implementations that don't follow the process yet
• Decision:
  • An incubator repo can be created if an author finds a shepherd for the FEP preparation (the FEP DR must not be present yet at that time)
  • The incubator repo lifecycle follows the FEPs lifecycle - after FEP acceptance/withdrawal/rejection the repository is archived (or renamed after acceptance)
• Next steps:
  • @qor-lb to update FEP description to accommodate this path
  • @qor-lb / @FScholPer to address the inc utilization in TL round
  • @LittleHuba to open FEP for inc_ecu_model tracking

[qor-lb]

2026-10-05

Participants

Agenda

1. Next 3 weeklies will be taken over by deputy @arsibo (12.10 & 19.10. ; 26.10. by @RolandJentschETAS)
2. @FScholPer AI Platform changes
3. @LittleHuba versioning before S-CORE v1.0
4. @basheerFZ - [Contribution Proposal] SOME/IP Stack LG Electronics #2807 (comment)
5. Review Feature Requests / Modification & FEPs

Meeting Minutes

to 2.

• update of the feature request of the AI Platform on Ai platform update #3260
• Praveen Gudi (LTTS) presented the AI Platform approach (see slides)
• Next Step: formalize motivation/approach via FEP

to 3.

• Questions/Thoughts
  1. What are the targets that should be fulfilled before the v1.0.0 is defined within a module?
  • QM vs ASIL distinguishing?
  • Prove that a module is acutally integratable (e.g. outside/within the module)
  • Can a module arrive at v1.0.0 before the overall reference_integration arrives at the v1.0.0
  • Relation to https://eclipse-score.github.io/score/main/design_decisions/strategy/DR-003-strat.html - can e.g. an experimental module be already at v1.0.0?
  • How are breaking changes handled? How long do we want to maintain backwards compatibility
  2. Will multiple versions be supported (e.g. patches of a previous version)
  • Do we support LTS like e.g. Ubuntu? Or do we only work on "the next release" within the community?
• Next steps:
  • DR/FEP to agree on the versioning strategy
    • Input from process community regarding maturity
    • Input from TL/PL community regarding strategy/maintainability
    • Input form modules regarding individual opinions
    • Goal: clarification for multiple stakeholders
      • The developers/contributors/maintainers behind S-CORE
      • The user integrating S-CORE: distributors/integrators/users
    • @anmittag to draft the FEP

to 4.

• moved to next weekly

[qor-lb]

2026-10-12

Participants

Agenda

1. @basheerFZ - [Contribution Proposal] SOME/IP Stack LG Electronics #2807 (comment)
2. Review Feature Requests / Modification & FEPs

Meeting Minutes

1. https://github.com/LGE-OSS/lg-someip/tree/main also presented in the com CFT
   @LittleHuba Extentionpoint for Some-IP Stack/ SW components is required (e.g. Comaso implementation). There are different solutions possible. 1. Comaso provides a SOME-IP Gateway. 2. S-CORE SOME-IP Gateway has a extension point for the SOME-IP Stack.
   Please discuss to add this in Req. & Design.

Agenda for 2026-10-19

• System Monitoring FEP  #3333 @mina-hamdi Please present the topic.

[arsibo]

2026-10-19

Participants

Agenda

1. @mina-hamdi: System Monitoring FEP  #3333
2. @sunildevda: Migration of supporting of Hashing functionality from Baselib to Security Crypto.
3. DDS Next steps -> @FScholPer
4. Review Feature Requests / Modification & FEPs

Meeting Minutes

1. Karim Wafik (Valeo) shows https://eclipse-score.github.io/score/pr-3333/design_decisions/architecture/DR-010-arch.html

• What is the integration approach? SMon can hook into different S-Core features. It will be realized as a daemon due to the access rights concept.
• Is there an adapter concept, for example, for GPU support? Yes, there is a plugin concept.
• Do you would also contribute the implementation? PoC is available. Open Sourcing is in discussion. Feedback can be expected next week.
• A Shepherd is requested from Valeo side.

2. Sunil (ETAS) presented the topic based on the information under "Background of Point 2".

• Question to Config management team will be asked by Sunil.
• The baselibs hash functions are used by users in projects.
• In general, baselibs provides APIs/functionalities which are needed by more than one module (rule of thumb).
• Focus on crypto algorithms only. Non cryptographic hashing functions algorithms stay in baselibs. If an algorithm is used in both, it will be in crypto.
• Decision: accepted
• Next Steps
  • Feedback from the baselibs users are required
  • See Milestones
  • information by
    • [sdv-wg-SCORE] Alignment Tech Leads, Community Leads & Feature Team Leads
    • baselibs release notes

3. @FScholPer : Discussions

• Repo structure:

  • Common repository for all gateways
  • Single repository per gateway

• Req: It shall be easy to replace gateways in projects.

• Note: An additional meeting will be scheduled for this topic.

• Action Item: @ALL to provide pros & cons as a basis for the decision.

Agenda for 2026-10-26

• None -> canceled

Background of Point 2

The hashing algorithm (SHA) is currently offered as part of Baselibs. Being a cryptographic algorithm, the right home for it is Security Crypto.

Details of the first alignment with the Baselibs team: Migration of hashing from Baselibs to Crypto repo · Issue #125 · eclipse-score/inc_security_crypto

Key Differences: Baselibs vs. SCORE Crypto

	Baselibs	SCORE Crypto
Algorithm support	$\color{red}{\textbf{SHA1}}$, SHA256, SHA384, SHA512 (algorithms.h)	First release: SHA-224, SHA-256, SHA-384, SHA-512 (PR #237 – crypto: Migrate hash functionality from baselibs by kssim). In future: SHA3
Quality level	ASIL for SHA256; QM for remaining algorithms via OpenSSL	Final target: 1. Crypto API ASIL + Crypto daemon QM 2. Crypto local crypto provider QM
FIPS certified	No	Yes (depends on the underlying crypto provider, e.g. OpenSSL supports a FIPS-qualified solution)
Hardware acceleration support	No	Yes (via multi crypto provider support)

Points to Check with the Config Management Team (and Other Existing Users of Hashing)

1. Why is hashing needed? The need looks more safety-related. If so, CRC should be used instead of SHA.
2. Is SHA1 needed? It is not recommended; it is cryptographically weak and broken.
3. Are there performance requirements (e.g. start-up time or time to perform a hash)?
4. Lib + daemon only (first step):
   • SCORE Crypto will offer a solution of lib + daemon first. There is no lib-only solution yet.
   • A lib-only solution is on the SCORE Crypto roadmap for around the end of 2027 (rough timeline, subject to change).
   • The local lib-only solution will be QM only, mainly because it involves integrating a FIPS-compliant crypto driver (e.g. OpenSSL), which is QM quality.
   • Is a QM lib-only solution acceptable? If not: is Crypto API ASIL + Crypto daemon QM acceptable?
5. API stability / migration approach:
   • SCORE Crypto is still in development, so there may be minor impact from incompatible API changes, especially related to error codes and configuration (the first release only has very basic config support).
   • Our impression is that the migration can still go ahead, since these changes are minor and the code can be adapted when they occur.
   • Would you be OK with this approach?
   • Waiting for a full-fledged stable Crypto solution risks other users starting to use the Baselibs hashing feature, which might force repeating the migration effort multiple times. The cost and benefit need to be balanced.

Milestones

#	Milestone	Timeline	Comments
1	Offer the hashing algorithm in Security Crypto with Lib + daemon (PoC state)	Crypto 0.1 release (Dec 2026)
2	Update of Config management (+ any other users in middleware): migration from Baselibs API to Security Crypto API	SCORE x.x release (Feb/Mar 2027)
3	Deprecate the hashing algorithm API in Baselibs	SCORE x.x+1 release (Apr/May 2027)
4	Remove the hashing algorithm API from Baselibs	SCORE x.x+2 release (June/July 2027)
5	Offer lib-only solution for hashing in Crypto (local crypto provider)	End of 2027

[RolandJentschETAS]

Weekly 2026-10-26

Participants

Agenda

Important

Meeting was cancelled due to an insufficient number of agenda items. The next meeting will take place as scheduled next week on Nov 2th.

Meeting Minutes

[RolandJentschETAS]

Weekly 2026-11-02

Participants

Agenda

Meeting Minutes