2022-09-29 Meeting notes

Craig McNally 

Axel Dörrer 

Chris Rutledge 

Jakub Skoczen 

Skott Klebe 

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:

• Deferred - no significant progress at this time.

Jakub Skoczen  raised the idea of evaluating if FOLIO meets this OWASP Application Security Verification Standard.  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 - This is the standard
  • 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
      • OKAPI-772 - Getting issue details... STATUS
      • 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)
• TODO for all: Create a wiki page with "OWASP Application Security Verification Standard", start evaluating FOLIO against Level 1.
• All security team members do evaluation.
• Skott volunteered to run a more in-depth scan using Zap.  Will need help (being pointed to resources, etc.)
• Create a FOLIO ticket in JIRA to track this effort.
  • Craig McNally will create the ticket (umbrella) and we can revisit in a future meeting (next week or two)
  • Eventually put spikes, tasks, etc. under this
• NOTE:  new repositories need to be imported into Snyk.  Julian imported all of those that aren't archived, but something to keep in mind going forward.

Today:

• Review the JIRAs that have been created, make adjustments, create additional stories as needed, etc.
  • Epic: FOLIO-3582 OWASP checks, reviews, and fitness functions 
  • Feature: FOLIO-3583 OWASP Zed Attack Proxy (ZAP)
  • User Story: FOLIO-3584 SPIKE - investigate OWASP Zed Attack Proxy (ZAP)

• 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 the 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.

Julian Ladisch / Ryan Berger / John Coburn 

• Create a spike to investigate what's involved in divorcing the login page from the NPM ecosystem.  Will reach out to John and Ryan as needed. 
  • Created by John C. :   STCOR-651 - Getting issue details... STATUS . 
• Reopen STCOR-395 and block on the spike. – Done.

Today:

• Where does this stand?  Get an update from Ryan Berger / John Coburn
• Waiting for the spike to be completed.
• John to reach out to Skott to discuss what the level of risk associated with this.

Julian Ladisch 

Julian Ladisch  3:51 AM

I've added versions for the Spring components to the Officially Supported Technologies list.  For Orchid it's easy: https://folio-org.atlassian.net/wiki/display/TC/OrchidFor Nolana it's more complicated: https://folio-org.atlassian.net/wiki/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.

• How do we want to approach this?
  • Consult the Spring Force team... Is this feasible?  Do you have better suggestions?
    • Craig McNally  to post in #folio-spring-base, at-mentioning Petrenko.
• How do we communicate this out?  
  • Coordinate with the release manager (Oleksii Petrenko)
• How much work is expected to be required?
• Craig McNally  to follow up with Oleksii P. again to see if the team has discussed this yet.

Today:

• Met with Oleksii P. and Spring-force.  They're onboard with this proposal and will take it from here.

Jakub Skoczen / Skott Klebe 

Last Week:

• Craig McNally  to ask Firebird team to create a JIRA project for mod-data-expert-spring-migration, and move MDEXP-553, MDEXP-552 to that project.

• Ryan Berger to create tickets for modules that still use react-hot-loader 

Today:

• According to the PO (Magda Z.), mod-data-export-spring-migration is temporary/a placholder.  We don't need a separate JIRA project for it.  My understanding is that the migration from RMB → Spring Way will eventually make its way into mod-data-export and mod-data-export-worker, which both already have their own JIRA projects.