Page Comparison

...

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
          • https://www.netlify.com/
        • 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

...