Date
...
Name | Present |
---|---|
Y | |
Y | |
Y | |
Y | |
Discussion items
Time | Item | Who | Notes | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 min | Kafka security | Team | The topic of Kafka security was raised as part of a conversation at the TC yesterday. The Security Team should be aware of this and probably should weigh in on the topic, or even generate proposals if we have ideas for how to solve the problem.
Today:
| ||||||||||||||||
5 1 min | OWASP/SNYK | Team |
Today:
| ||||||||||||||||
5 1 min | Cumulative upload problem | Team |
Today: 5
| ||||||||||||||||
1 min | STCOR-395 "refactor login form to avoid using any form framework whatsoever" | All |
Today:
| ||||||||||||||||
1 min | Spring versions and the Official Supported Technologies pages | I've added versions for the Spring components to the Officially Supported Technologies list. For Orchid it's easy: https://wiki.folio.org/display/TC/OrchidFor Nolana it's more complicated: https://wiki.folio.org/display/TC/NolanaThe OSS support of several Spring components ends in May 2023. This is more than three months before the end of the Nolana support period that end in August or September 2023. The next minor version of those Spring components will be released in November 2022, this is during Nolana bug fest. We need to bump to this next minor version and release a bug fix for all affected FOLIO Spring libraries and FOLIO modules in November 2022.Running unsupported Spring components is a security risk. If there is a security issue in a supported Spring component we simply can bump the patch version, no risk. If there is a security issue in an unsupported Spring component we don't get notified because it's unsupported, and if we know of an issue we need to bump the minor version, this comes with some risk. Bumping the minor version as early as possible gives more testing time and is less risky. We can discuss this today.
Today:
| |||||||||||||||||
10-15 min | Security Team processes - revisited | Team | Review/discuss the proposal shared in slack
| ||||||||||||||||
1 min | Snake Yaml Vulnerability | Julian | See SnakeYaml SafeConstructor. Handling this within the security team - triaging each snyk alert. Seems like in most (all?) cases the only yaml being processed is hardcoded configuration files, meaning the risk is low. Snyk exceptions / suppressions can be put in place where applicable. If necessary JIRA will be raised (Seems unlikely). Today:
| ||||||||||||||||
* | Review the Kanban board. | Team | |||||||||||||||||
Time permitting | Cyber Resilience Act | Team | I raised this with the TC but we should also be aware... https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/ https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act |
...