Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Minutes/Updates

  • RepoSupport #69
    • Create document document (see below)
    • Changes look great. Need a test or a doc page.
  • OpenSSF scorecard
    • Best practices badge now merged
    • Some GitHub actions
      • Someone with Admin in the L3AFd permissions needs to set up PAT.
    • Create read only token and add it under the security tab.
    • Generates score between 0-10.
    • Jason Niesz to do this.
  • Added some tests #66
    • Dave has permissions.
    • When should Merge be done?
      • 2-3 code owners sign off
      • Second person merge or third person merge?
      • 2 approvers besides the submitter to merge.
  • Reposupport #69
    • Guidelines for PR
      • 100% code coverage
      • full documentation
      • There is no documentation change here.
      • Couldn't find a doc that needs to be updated. Is there one?
      • The code changes look good, but should there be a doc page? Should we add tests?
      • We need to create a document. Santhosh Fernandes
    • l3af.io needs refreshed
      • Add Cloud Native eBPF presentation
      • Lj: PAge was set up through the LF creative services group.
        • Can we put this in a GitHub repo where we can maintain it?
        • Dynamically generated from GhPages feature
          • Doxyfile - generates HTML from Markdown.
          • GitHub workflows: UpdateDocs - creates site from DoxyGen file
          • Switch branch to GhPages and check in there.
        • eBPF.io website generated by netlify
          • Runs in CI/CD and generates a preview.
          • We just want to be able to manage the website without having to ask an outside entity.
        • Is ebpf.io going to be community managed or is there going to be a contractor?
          • Who will set this up in GitHub? LFIT or community?
          • Can we take over WebMaster for l3af.io? Lj
          • Does eBPF.io use the free version? Dave Thaler to find out.
  • Roadmap planning
    • LFN board meeting in May
      • Challenges: Roadmap, release management, contib diversity, community growth.
      • What is our Roadmap and Release cycle?
        • We can get media attention with this.
          • LFN blog, linked in pages, our company linked in and blog posts
        • This will help us build our community.
      • 1-2 people to take on Release Manager role
        • Training and consulting is available for release management is available
      • We should define release management cycle
        • We will get some more resources soon → We should assign the release manager roles then.
      • In the interim we can define the roadmap. Put some dates on it.
        • LFN board and at the end of June the LF board. Project updates.
        • They can help with guidance and resources
    • Lj: back in 2 weeks (29th of June) Vacation and Dev end test forum.
  • Security for the localhost
    • Don't have a database to store tokens in the l3afd environment
    • Need to auth with username/pass, get a token back and validate based on token
      • Two types: Normal and Admin user
    • Some kind of script that will generate token
    • Hostname and role will be passed
      • Token will be stored in l3afd.cfg file as a part of deployment
    • First we pass the token and check for validity
      • Should we validate on host that the roles are matching?
      • "If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., Argon2id, Bcrypt, Scrypt, or PBKDF2). See also OWASP Password Storage Cheat Sheet). [crypto_password_storage] This criterion applies only when the software is enforcing authentication of users using passwords for external users (aka inbound authentication), such as server-side web applications. It does not apply in cases where the software stores passwords for authenticating into other systems (aka outbound authentication, e.g., the software implements a client for some other system), since at least parts of that software must have often access to the unhashed password."
        • Should we be storing the password in a file?
        • This is probably not best practice. How do ensure that the file cannot be read by the world?
        • Today we do not encrypt the file.
        • Storing secrets in a file is probably not best practice.
          • Can we store a hash of the key?
            • ..."Iterated hashes using a per user salt"...
          • We could look at public key to connect on localhost
            • Use cert signed by CA
          • We could create a CA in mTLS which has a private key. It could issue a client cert and then we only allow TLS.
          • Token Base or tcert public key or something like this
        • Atul: if we try ssh type authentication private and public keys
        • Dave: Can we do this with mutual TLS and put the client cert as the TLS cert?
          • Doesn't work in browser land.
          • Could be done with a fancy rest api
        • Make l3afd a group and members will be validated to the password in the system?
          • Different code for Linux and Windows
          • TLS will have the same code for Linux and Windows.
          • We should, if possible, optimize for user experience.
        • Only ever store public info in files. Never store secret keys anyplace in the file system.
        • Unless we make a dynamic key like a hostname or a some combination then the client cannot generate the token again.
        • pub/private key is probably the easiest or we have to have a hash value stored in the file.
          • Store the hash value as a key, but...
          • We need a way for the client to generate the hash file.
    • Satya will be pursuing other opportunities. Will be here next week.
      • New resources coming in July.

Action Items

Future Agenda Items

...