Hi everybody,

Our next TSC meeting will be on April 29^th.

For this public meeting, it would be great if we follow these items:

Release of powsybl-core (4.2.0) expected on May 20^th, please refer to the release notes to know what the release will contain: Release v4.2.0 (expected date: 2021-05-20) · powsybl/powsybl-core (github.com)

Main features or bug fixes: please refer to the draft release notes.

We except a version 4.1.2 for bug fixes tomorrow. The bug concerns the JSON serialization of Line and TwoWindingsTransformer contingencies.

Roadmap

For this TSC, I suggest to focus our roadmap on how growing our community (users + contributors)?

- Vattenfall for grid capacity estimation for DSO and TSO via PTDFs and LFs ; the methodology has to be defined and harmonized ; see slides attached.

- ACER: via pypowsybl, ACER is firstly interested in :

1) Calculation of zone-to-zone PTDFs for AC borders

2) Calculation of zone-to-zone PTDFs for DC borders/DC lines

3) Modification and creation of bidding-zones (e.g. shuffling nodes, e.g. for DK1)

- Control Room of the Future (Control Room of the Future - TenneT) : it is a working group inside the LFE. Powsybl could be used here.

- Other?

Technical discussion

I think that you all know that we pass the CII best Practices badge (BadgeApp (coreinfrastructure.org)) with 185%!

Key points must be underlined after reaching the first 100%:

- Documentation, especially in the web-site is a central subject ;

- Release candidates should be used for major release ;

- We have to focus on vulnerabilities (of the project itself and of its dependencies) ;

- Slack and official mailing lists must be used in priority ;

- Some committers must have a secure development knowledge (Secure Software Development Fundamentals Professional Certificate | edX)  + OWASP Top 10 ;

- Jars must be signed ;

- Dynamic code analysis: using Valgrind for the C++ analysis should become automatic + It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds.

Key points after reaching the last 85%:

- The project MUST document what the user can and cannot expect in terms of security from the software produced by the project ;

- The project MUST automatically enforce its selected coding style(s) if there is at least one FLOSS tool that can do so in the selected language(s) ;

- TODO: It is SUGGESTED that in the version control system, each important version tag (a tag that is part of a major release, minor release, or fixes publicly noted vulnerabilities) be cryptographically signed and verifiable as described in signed_releases ;

- Other security issues: the project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered : best-practices-badge/security.md at main · coreinfrastructure/best-practices-badge (github.com)

- Gold: double authentication in Github, not via SMS.

If you have subjects, do not hesitate to send it to me.

Thanks for joining the TSC.

Anne