2022-08-04 Meeting notes

@Craig McNally 

@Julian Ladisch 

@Axel Dörrer 

@Ryan Berger 

@Chris Rutledge 

@Jakub Skoczen 

@John Coburn 

1 min

mod-configuration - should it be deprecated or not?

@Julian Ladisch 

mod-configuration has been discussed on the development channel recently. Developers like it because they can simply drop variables to the /configurations/entries API. Simply use the "configuration.*" permission shared by all modules and you are done. No need to add schema validation, no need to add dedicated permissions, no need to add a dedicated API.
Drawbacks:

• A big institution need config write permissions with module granularity. One member of staff may be allowed to edit circulation config but not acquisition config.

• No validation. mod-configuration cannot validate a POST or PUT request because it doesn't know. Only the module it belong to knows this. Relevant use case: Using curl/wget/postman/...

• No documentation. mod-configuration has no documentation, one needs to search, maybe the module's README has some? A dedicated module API always publishes the API documentation at https://dev.folio.org/reference/api/

• Performance. Requests to mod-configuration result in latency. If the config API belongs to the module the module can cache it and can invalidate the cache if the config is changed. Caching requests to mod-configuration will always result in a time period with outdated values. In mod-inventory-storage we've combined fetching the HRID config and HRID generation into a single SQL query.

• Coupling. Modules should be loosely coupled and therefore each module should store its own configs.

It was requested that a formal RFC/Architecture Decision Record been created if mod-configuration should no longer been used for module-specific configurations.

Team decided we want to have this as a RFC. Target should be to have this implemented within Nolana. Could discuss in your meetings while the RFC process moves on.

• @Julian Ladisch will create the RFC/ADR

Today:

• Julian not present this week.  I don't see an ADR or RFC yet.  Shift to next week

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.

• See https://wiki.folio.org/download/attachments/96404444/Another%20Look%20At%20Kafka%20Topics%20Per%20Tenant.pdf?api=v2 for additional context.

• It may make sense to wait until Olamide's RFC for the tenant-specific topics is created/discussed/etc.

Today:

• On hold until the RFC is available for review.

5-10 min

OWASP

Team

@Jakub Skoczen  raised the idea of evaluating if FOLIO meets these standards.  @Ryan Berger has run some tools a while back, but it's probably time to revisit, and maybe take it further.

• Maybe make this a periodic task →  e.g. once per flower release?

  • Quality gate in the release process

• Links:

  • https://github.com/OWASP/ASVS

  • https://owasp.org/www-project-top-ten/

  • https://owasp.org/www-project-zap/

  • Sonar's static code analysis reports security issues: https://sonarcloud.io/organizations/folio-org/projects?sort=-security

  • Snyk's static code analysis reports security issues: https://app.snyk.io/org/folio-org/project/0a9e64c2-4385-4fdc-b1eb-91ff710bf1a3

•  TODO

  • Refresh our memory on tooling - OWASP Zap

    • @Ryan Berger to dig up the findings from the previous run of Zap

      • https://folio-org.atlassian.net/browse/OKAPI-772

      • Anything else?

  • Can it be run in an automated fashion?

    • It's possible that maybe Kitfox or Devops could help with this (just an idea)

  • Create a FOLIO ticket in JIRA to track this effort.

    • @Craig McNally will create the ticket and we can revisit in a future meeting (next week or two)

Today:

• Deferred until we have Jakub and Julian. 

• @Craig McNally can't recall the context for the action item above... What is this JIRA ticket about?  The automation of these checks, or something else?

10 min

Brainstorm the cumulative upload problem

Team

• Regarding file upload size issues (See 

  
  FOLIO-3317 - Spike - investigate possible file upload vulnerability OPEN ), let's brainstorm ideas for mitigating the cumulative upload problem, not just he large file upload size problem.  

  • Some APIs are more vulnerable to this than others, such as those not protected by permissions - e.g. mod-login, edge APIs, etc.

Today:

• Axel provided some background/context.  We still need to give this some thought and possibly suggest a solution

*

Review the Kanban board. 

Team

• Core platform teams has prioritized several tickets and will handle them for Nolana: https://folio-org.atlassian.net/secure/RapidBoard.jspa?rapidView=80&view=planning.nodetail&quickFilter=1688&issueLimit=100