Page Comparison

Julian Ladisch / Craig McNally 

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:

• Mike Taylor is pushing this conversation forward.  See MODCONF-131
• TC was asked to weigh in... is now looking for a champion or someone to sponsor the writing of an RFC... (sound familiar? )

• 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)
• Progress on FOLIO-3584?
  • Skott ran a scan against MG Bugfest
  • Skott Klebe  and Craig McNally to review results... weed out false positives, then bring results to next week's meeting.
  • Scan stopped at 95% (OOM issue in Firefox)
• Any other features/stories we want to create?
  • Not related to OWASP, but I think Skott Klebe suggested that our SNYK could be tuned/adjusted to better suit our needs.
  • Maybe make the Epic more generic – "Security Fitness Functions" or Create another epic to track the non-OWASP stuff?
• SNYK
  • Should define JIRAs
    • Spike to investigate how we can tune snyk to better suit our needs – Craig McNally  to create this.
  • Provided some background/history about SNYK in the FOLIO community
  • Stripes architecture reviews dependencies every other flower release (1-2x/year)
  • Currently only looking at platform level (with package.json/lock files)
    • Avoids a lot of the dev/peer dependency false alarms

Today:

• Skott Klebe will have limited time to spend on SG activities but will have some time to spend on the TBD Snyk spike in mid-December.
• It sounds like he's seeking help from someone more familiar with snyk ... either to have a conversation or provide documentation links.
  • All this means is the spike JIRA should contain documentation links
  • Also need to clarify which repos are integrated with Snyk, and what the process looks like for managing this.
  • TODO:  look at the FOLIO documentation on Snyk.

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

All

• 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. 
• Reopen STCOR-395 and block on the spike. – Done.

• Where does this stand?  Get an update from Ryan Berger / John Coburn
• Waiting for the spike (

  Jira Legacy
  server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key STCOR-651

  ) to be completed. – currently in the Open state.
• John to reach out to Skott to discuss what the level of risk associated with this.  – Still needs to happen.
• John Coburn pulled together two PoCs.  See comments in

  Jira Legacy
  server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key STCOR-651

• How do we want to move forward?
  • Solutions need to be reviewed and discussed.
  • Sounds like the iframe approach is a non-starter... actually a step in the wrong direction security-wise
• John Coburn (and others) to read up on browser CSPs

Today:

•  John Coburn has made some progress on investing CSPs
  • Will share some draft guidance we may want to include into the installation documentation (via slack)
  • SG will review and provide feedback.  Skott Klebe please take a look too
• Next up:  John to work on some spike work - focused on introducing CSPs on the folio-snapshot site
  • can serve as a reference impl of the guidance we'll be adding to the install docs

Julian Ladisch / Craig McNally 

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://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.

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

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

• There are complications with this... conversations in #folio-spring-base:

  • For details see Nolana#Frameworks.1

  • Spring Boot 2.7 has extended OSS support until 2023-11-18, this completely covers the Nolana support period (~ August 2023), no need to switch to Spring Boot 3, but see below

  • However, folio-spring-base also uses Spring Cloud, and other Spring way modules also use other Spring components without extended OSS support

  • Spring Cloud 3.1 support ends 2023-05-18, this is at least three months before the end of the Nolana support period around August 2023.

  • Spring Cloud 4.0 GA release will be in November 2022.

  • Spring Force team has agreed that Milestone versions can be used. These need to be replaced by the GA version. Nolana GA release will be in December 2022.

  • Only recently (2022-10-04) Spring Force noticed that Spring Cloud 4 requires Java 17 and only (officially) supports Spring Boot 3.

• Also introduced the topic at the Technical Council meeting yesterday but ran out of time.  The TC will discuss more in slack and if necessary at next week's TC meeting.

• Update from Julian Ladisch / Craig McNally...  Summary:

• Last week it was decided that the Spring Upgrade (Spring Boot from 2.7 to 3, Spring Cloud from 3.1 to 4) and the Java Upgrade from 11 to 17 is postponed to Orchid; and:

Two options that need to be discussed in January 2023

• Limit support of Nolana release up to May 2023

• Backport of Orchid spring-based changes to Nolana HF

Today:

• Postpone for now – at some point we need to check in with spring-force to see how things are going
• Looks like JIRAs have been created for some of this – a good sign

Jakub Skoczen / Skott Klebe 

• https://issues.folio.org/browse/MODLOGIN-186
• https://issues.folio.org/browse/MODUSERBL-150
• https://issues.folio.org/browse/MODAT-133

• Skott to needs to meet with Steve E. / Vince B. 
• Also review the associated PRs (links to these are in the JIRAs)
• Some potential concerns:
  • Having multiple authentication/login APIs... is this strategy how we want to roll this out?
  • Introduce the new API, deprecate the older one.
    • Have both co-exist for a single release cycle to allow for transition to the new API.
  • Does this increase our attack surface area?
  • Another option:  rip the band-aid off... break the existing API and force everyone to switch to the new API in a single release cycle
    • Con: Less time for transition
    • Pro: there's only a single login API in any given release
• Skott would like an option to switch off the old API on a per tenant basis for institutions that have completed the migration to the new API. 

Today:

• What's next here?  Can this topic be removed from the agenda for now?

• No progress since meeting with the release planning group.  Need to circle back with Jakub Skoczen