One of the significant contributors to Envoy’s continued dependency and SLOC growth is C++ extensions. Visualizations of this are provided in “Understanding, maintaining and securing Envoy's supply chain” EnvoyCon 2020 talk (slides, video).

Many of these extensions have limited support, maintenance and production use. Some are labeled alpha or have unknown security postures (see this list). One reason for the growth in C++ extensions is that Envoy has an unstable API internal C++ API, and upstreaming an extension ensures build maintenance as this API changes.

To structurally eliminate the dependencies implied by these extensions, we can ask that new external dependencies that are immature, not widely used or that are not in some sense “core” to Envoy, be added to either:

1. An independent extension repository.
2. A contrib/ directory tree in the Envoy repository that is distinct from the rest of the Envoy source.

This extension repository/directory will be validated for build/test by CI, but will not be covered by Envoy’s security policy or product security team. When an extension meets specified maturity criteria, it can graduate from the extension repository to the regular source tree. Proposed criteria:

• The extension is stable (not alpha)
• The extension’s dependencies meet all Envoy’s dependency criteria
• The extension is known to be in production use by at least one known operator
• The extension has active maintainers
• The Envoy security team agrees that there is a compelling public interest in supporting the extension

There are also considerations and advantages around build time and binary size that might argue in favor of this approach.

A counter-argument to repository separation is that it is burdensome to work across multiple repositories for a typical git flow and we can effectively enforce extension support and dependency separation in a single repository with the above criteria being used to eliminate extensions and dependencies from security team consideration when unmet.

We might also have different standards for API and code review in the extension repository/directory, making maintainership more scalable.

Opening this issue to track discussion on pros/cons of this approach.

CC @envoyproxy/maintainers @envoyproxy/security-team