Rename L3AF eBPF Package Repository to L3AF Public eBPF Package Repository

[sanfern]

@dthaler 16 days ago
Per discussion on line 119, maybe add the word "Public" here, since the L3AFD daemon can work with other package repositories too. Indeed, if there is any actual "code" or scripts for such a repository, then we should separate implementation from policy. I.e., implementation would be a repo that could be used by anyone when creating their own package repository, and policy is anything specifically for the L3AF Public eBPF Package Repository that may not apply to local repositories (e.g., the fact that you're proposing having to contribute source code instead of byte code is in my opinion, something that varies by repository).

@jniesz jniesz 12 days ago Member
I think adding public makes sense here and for the l3af public eBPF package repository IMO it makes sense to require source code

@dthaler dthaler 11 days ago
Here’s my issues with requiring source code for all packages in the L3AF repo:

If the authoritative version of ebpf source is already in some other existing repo, such as it is for Cilium, Calico, etc. today, then adding a copy under L3AF has both efficiency issues (why copy? Which one is authoritative? How do you submit a patch?), as well as possible governance issues (is the licensing model compatible? Is the CLA/DCO process compatible? Is the security vulnerability reporting process compatible? Etc.) since it’s in two different open source governance organizations.
If the tooling requires source code, rather than byte code, then there can be cases where the tooling won’t work for use in enterprise-private package repos if enterprises want to use their repo to contain both OSS packages and commercial packages they may not have source code for, so that they can use common L3AF tooling and program lifecycle management for all their ebpf needs. This would result in multiple package repo implementations instead of reuse.
Using byte code in the repository, with recommending a pointer to where source can be found, would avoid both types of issue above. This is why I think the initial version should do that instead of source.

@jniesz jniesz 11 days ago Member
My comment was really around the initial version and the limited set of (seed) programs added to this repo. I don't think it is feasible to review / accept eBPF packages by l3af maintainers without the source code.

Once there are more checks and gates in place, I don't think we should require source code and byte code alone would be sufficient.

@dthaler dthaler 11 days ago
I don't think it is feasible to review / accept eBPF packages by l3af maintainers without the source code.

My opinion is that manual review is not scalable. If the "public" (or whatever) repo is limited to only what can be done via manual review, then I would expect it will always only contain a small number of small programs, and additions will take a long time to get reviewed, and the reviewers will have a long backlog of requests, and people will get displeased with the length of time it takes to get anywhere, and go elsewhere to a different "public" repo that is automated and does not attempt to make promises about security vetting, but leaves that responsibility to those pulling from the repo, and reinforce the point that one should never point l3afd at the "public" repo only at one's own vetted repo (which would contain a small number of programs by comparison). Personally I would rather have the initial version do the latter rather than doing something that requires much more effort and still doesn't solve the security concerns.

@jniesz jniesz 11 days ago Member
I agree that manual review is not scalable and not something we should offer to the public until we have the automation in place. What if we keep the name "L3AF eBPF Package Repository" repository for now and then change it to "Public L3AF eBPF Package Repository" when we are ready with the automation? I think this is a good initial place to store the build artifacts (byte code) for several of the eBPF programs contributed already under L3AF (xdp-root, ratelimiting, connection-limit). In my opinion it seems cleaner to store these here vs. in the l3afd repository. When we are ready to open this to the public they will already be added and can be reference examples for other folks to contribute their own eBPF packages to this repo.

@dalalkaran dalalkaran 10 days ago Member
I think it is important to distinguish between the initial and future version spec of the "eBPF Package Repository".

In the initial version spec, the proposal is to simply have a GitHub repository to store eBPF program source code. This is to make sure that all the contributed eBPF programs can be made available in a single repository. The proposal acknowledges that the initial version won't have automation in place, and so all submissions will be manually reviewed and published in this repo. The review process will also ensure that the code submissions conform to L3AF's eBPF program chaining mechanics. In this context, it may not be possible to review and accept eBPF packages without source code.

The future version builds on top of the initial version and aims to include a fully automated build-release system that can perform reviews and build/upload the package to a storage repo. The proposal for future version discusses the option of allowing contributors to upload the eBPF package without sharing the source code. It also aims to address various other challenges such as security (vulnerability detection, signing, semantic code analysis) and portability. The eBPF Package Repository Committee will discuss the future spec in detail to draw agreements and can choose to add the word "public" to "eBPF Package Repository".

Hope this helps clarify!