DA Meeting Minutes 2022-08-24





  • Review actions from previous meeting
  • Issue 89: Code Distribution Integrity Assurance using Helm Provenance and Integrity (GK)
  • Issue 93: specifying the infrastructure Mojaloop will run on (TD)
  • AOB


  • Issue 89: Code Distribution Integrity Assurance using Helm Provenance and Integrity
    • How to ensure the integrity of our distributed packages.
    • Investigation by Aime
    • Option 1: Use Helm features
    • CI/CD process is completed, a chart is produced and stored in the repository and used to install Mojaloop.
    • Use Helm feature called Provenance and Integrity to sign chart using PGP keys, and these can be used to verify that the chart came from the Mojaloop repository.
    • Existing feature, doesn’t need anything new doing.
    • SK: Have we tried this out? GK: we don’t change anything in our existing process.
    • PB: we want to extend this to the e2e code signing that goes from the Docker image to deployment in the environment.
      • GK: definitely agree. We should try this first, then extend the investigation to close that gap.
      • PB: this is signing the tooling, not the code. We should ensure that people are aware of that.
      • GK: we’ll adjust the naming.
    • TD: does this make sure that the NPM packages are consistent?
      • GK: No, not at all. That’s a different discussion, which is still open. GK will bring this back for discussion.
    • MdB: this is a good thing, but we are only providing integrity at the top level. We should ensure that people are aware of that. We need to extend it to the Docker images and the code.
      • GK: we will bring this back for discussion
    • PB: We should make clear to users what security is being added and what isn’t there yet.
    • Approved with comments for further investigation.
    • SK: we should add an area on the site to explain this.
      • TD: Technical section of the site should have a Standards section (or a Security section). We should create it at the same level as the Standards section
    • MdB: Documentation hasn’t entirely been migrated… people should be aware.
    • GK: Do we have anywhere for it now? We don’t have anything specific about this at the moment.
      • MdB: add something under Standards
  • Issue 93:
    • Link to slides: https://docs.google.com/presentation/d/1A1iDEN0xyvX7pIYIsqTVmeSRE3pCIMk9QksLlMT_LfE/edit#slide=id.p11
    • TD: this directly affects the code that we’re going to put into changes that are happening now.
    • TD: What version of Kubernetes should we support?
    • Which versions are we prepared to test? and how do we decide?
    • PB: this is clear, which is good, provided we have the bandwidth.
      • MdB: Current release only runs up to KB 1.21. New release should support the latest version supported by the previous release.
    • TD: which versions of KB are we testing today?
      • MdB: We are not testing as part of CI/CD at the moment. The core team manually does this testing. Automated testing is done in the new chart repo…
    • SK: realistically, we need to start by documenting strictly what we support and what versions we tested it on. We have a tree with multiple branches. We’re not a commercial operation, we need to pick a single path and only go for others if we have user pressure… We shouldn’t put a burden on the community.
      • TD: Yes, but… I’ve tried to restrict as far as possible.
      • SK: we need to show it works for some widely used version.
      • MdB: that’s what we do at the moment. We document it in the deployment guides.
    • TD: I want automated testing and very clear statements on everything. We can expand the existing architecture to test against multiple versions and branches. We test against the current version, plus the K8 version which was current for the previous Moja version.
    • PB: the process is OK, we just have a problem with 1.21 at the moment.
      • TD, MdB: Agreed.
    • PB: We issue a notice: from the next release, 1.21 (e.g.) will no longer be supported.
      • MdB: No - we run it on the previous version. If it doesn’t work, we say so.


  • GK: Put documentation explaining what we’re checking and what we’re not on the Mojaloop site.
    • Should be part of the standard release notes for Helm. (SK)
  • GK: Update issue with DA approval
  • DA: Decide where the security information should go.