DA Meeting Minutes 2022-04-13


Apologies: PSB, LD, JO


  • Review actions from previous meeting
  • Issue 78: Upgrading node version to the latest LTS
    • Review of TGB discussion
  • Issue 88: Preventing or Mitigating Open Source Supply Chain Attacks
  • Issue 90: Change the basis of the liquidity check
  • AOB


  • PSB’s opinion on what to do:
    • To sum up my opinion on this:
      • I’m against using any form of dynamic version numbers in dockerfile or .nvmrc like “lts” or “latest”, we should always use fixed numbered versions like “16.14.2” (in fact for everything, not just dockerfile and .nvmrc)
      • We should have a repo with a json file that has the official allowed node.js versions, and a git check script that compares dockerfile and .nvmrc against this on every PR). Every 3 months, we can manually review and if needed update that json file with the adequate releases (from node.js official schedule).
      • We can also have a script periodically scanning our repos and warning to slack everytime it finds a js/ts repo without a .nvmrc file, or finds non approved node.js versions in dockerfile or .nvmrc.
      • When we release, we execute the above script to make sure everything is using the adequate versions, if not, we manually fix them at release time.
  • MR reported back from the TGB: Miller was concerned that small development tasks should not be held up because they raised an issue with the current LTS version of node.js
  • Should changes be part of a release? We could run a daily build against the LTS, which we already do.
  • Runs against the Mojaloop dev branch. Developers modify pull requests at whatever code level the repository currently is. Ensuring compliance with the current LTS is part of the merge back into the dev branch.
  • We get everything up to current version. Push version forward, if any problems then we report on them and copy people who have checked out branches which have a problem.
  • We can go up to 16 now, then we need to go up to 18 in October.
  • What about patch minor versions? Run the script, see if it’s a problem, then we can decide what to do.
  • We have a script which runs to check the version of dependencies and alert if it needs to be updated…
  • Should we check to identify libraries which are not being updated? We should be aware of it, but without necessarily doing anything.
  • Looks as if we want a regular cadence (1man-month?) per year to keep all this stuff up to date. We will know what the requirement is after MdB finishes his initial pass.
  • Issue 88
    • We have our existing security audit as part of check-in procedures. We should check to see if they are sufficient.
    • Should we also be making independent checks?
    • We already use Snyk and Dependabot
    • There may still be problems, but for core services, should we add a firewall? This would be a recommendation for deployment…
  • Issue 90
    • The proposal is to make the liquidity check more efficient.
    • Resources are available to undertake the work if it is approved.
    • Agreed that DA members will take time to review the proposal and it will be discussed at next week’s meeting. If everybody’s happy with it, we will approve and go ahead. If there are issues, we will postpone discussion until everybody’s present.
  • MR is on holiday next week and the convening is the following week. MdB kindly agreed to chair next week’s meeting.


  • Some time is available: MdB will work on the node.js upgrade from 18 April.
  • GK will review our code security procedures in the light of Issue 88 and report back.