Distributing features & templates

[chrmarti]

The goal is to distribute definitions to distribute the maintenance load. We currently have 3 buckets:

• The main set of definitions will be maintained by the Codespaces team.
• JavaScript and TypeScript definitions will be maintained by the VS Code team.
• Community maintained definitions will continue to be maintained by the community.

For the community definitions there are various levels of self-service, when useful we can use the JS&TS definitions to help dogfood the approach we decide to take. The approaches I can think of are:

1. Community submits PRs (like today). In a separate repository (one for all community definitions).

• Initially the product teams would review the PRs. In the future a team of volunteers from the community might do that (e.g., the DefinitelyTyped project does that).

2. Community pushes updates themselves. In a separate repository (one for all community definitions).

• New contributors might first contribute through PRs.

3. Community contributors can have their own repository for one or several definitions.
   a) We maintain a static registry to collect the definitions at build time, later at runtime.
   b) We have dynamic registry, definitions are discovered at runtime. New contributors can register definitions themselves.

A dynamic registry where new contributors can register definitions themselves maximizes self-serviceability, but it also raises security concerns. VS Code extensions are using such a model and it is an open issue to add support for cryptographically signing extensions, so authorship can be verified (microsoft/vscode-vsce#191). There is work being done on this that very much looks like it could be used for other types of artifacts too, but it is too early to tell if we could use it for definitions.

I suggest we take the following steps (progressing from 1. towards 3. above):

• Move community contributions to a separate repository.
  • Keep updating them with PRs and grant commit rights to long-time contributors.
  • Long-time contributors may also start reviewing PRs from the larger community.
  • Consider splitting up the new repository further to ease maintenance and introduce a static registry.
• Move JS&TS definitions to a new repository for VS Code. Setup security scans for base images (Community definitions currently do not build their own base images.)
• Move remaining definitions to a new repository for Codespaces. Setup security scans for base images.
• Initially we can collect the definitions at build time. We will consider updating them at runtime later.

Open questions:

• Library scripts are reused across definitions and will need to be copied or pulled/pushed.
• How would the community scan their base images if they had any? I think all the security scans are internal infrastructure.
• Policy-wise unclear if Codespaces can move their base images to the GitHub Container Registry and if they would continue to use the same security scans.

/cc @2percentsilk @bamurtaugh

[Chuxel]

@chrmarti Another open question related to the script topic is dev container features - particularly 1st party ones. I'm kind of assuming they'd live in the same location as the scripts, but technically that would not have to be the case.

[joshspicer]

I would elect for approach (3) above, allowing users to create their own repos which they maintain themselves on GitHub.

I think it would be really powerful for the extension(s) to dynamically search GitHub for templates given a search query. Perhaps some simple naming convention or repo topic can be devised to filters repos showing up in the search.

This is how you pick a codespace - I can imagine a similar search mechanism for the extension.

We'd still show our "default" templates without needing to search, allowing for a user to quickly pick from a list of "good starting points".

[bamurtaugh]

I like the idea of searching. I have some initial questions on it, if we go with users all having their own repos vs one central community repo:

• Discoverability: would we expect users to know the precise repo name/location of the definition they want? Or to just keyword search by tech stack?
  • Do we run the risk of current users struggling to find popular, well-maintained definitions already in vscode-dev-containers?
• Trustworthiness: depending upon the accuracy of search & discoverability of definitions (i.e. if users just search Go), users may end up with unintended or untrustworthy definitions?

I'm thinking of the VS Code core Extension search experience. Users may initially want to select an extension they weren't intending, but in the Extension view, they can view the publisher and description to understand where exactly this extension is coming from and if it's the one they want. I wonder if we'd want to link an easy way for users to view the repo on GH before selecting it?

[Chuxel]

@bamurtaugh I think we would want to surface who "published" the definition in all cases. Right now there's only two modes: "Microsoft" and "Everyone else". I'm sure this prevents some people from contributing since everything looks like it is unofficial unless Microsoft created it (e.g. see microsoft/vscode-dev-containers#1238). Given our desire to be open to alternate sources, many of these may also be "official" if viewed from the perspective of the technology in the definition rather than the tool. For example, Google or Amazon, or the core language teams for Rust or Swift could opt to add their own official definitions - they're really no less official than the Microsoft maintained ones.

The question then is how you reliably identify the "publisher". Right now for public dev container features, the model in preview uses a public GitHub org - which is a pretty good proxy.

Search, then, is really a separate question. For a tool / service agnostic model, we could start by using GitHub topics, which then allows you to search within the topic. This is how Actions is setup: https://github.com/topics/github-action GitHub then layered in a service specific marketplace UX (https://github.com/marketplace?category=&query=&type=actions&verification=), but I believe the APIs would allow anyone to create their own index if they so choose (including for VS Code or something else).

VS Code and Codespaces UX is really beyond the scope of dev container spec discussions tho, so we could iterate on what we'd like to present there elsewhere. I don't think a single vs multi-repo path really affects it.

[chrmarti]

While I agree with much of what is being discussed, in a first step I would like to keep producing the list of available definitions and ensuring their authorship simple (discoverability and trustworthiness). The proposal is to start with 3 repositories (Codespaces, community and VS Code) and collect the definitions at build time.

As we increase self-serviceability from there, we will need to think more about security. (@Chuxel you mention a GitHub org as proof of origin, if a personal account counts as "org", it wouldn't be strong, so maybe you have corporate accounts in mind?)

On container features: I think we can split these up the same way as definitions for now. For features having a way to update between releases is more important than for definitions I think, so we should also continue productization of that existing effort.

[Chuxel]

As we increase self-serviceability from there, we will need to think more about security. (@Chuxel you mention a GitHub org as proof of origin, if a personal account counts as "org", it wouldn't be strong, so maybe you have corporate accounts in mind?)

@chmarti Totally agree - we need proof of origin. The nice thing about an org, is individuals cannot easily pretend to be an "official" org for a given language/product/team. Users can also not pretend to be another user (since the ID is tied to your github profile). If I publish something, the org will be chuxel - and github.com/chuxel tells you what you need to know. Something official would be expected to be in an org owned by a company, OSS project, team of enthusiast, etc. e.g. aws for Amazon, rust-lang for official rust projects, etc. Certainly there's situations where an individual has something that could look official (e.g. github.com/vscode), but GitHub also has the concept of verified orgs already, so we can use that as well.

[chrmarti]

From a security point of view, it matters that anyone can create a GitHub account. It seems 'verfied' orgs are only available for company accounts, but not personal accounts (from what I could find in the documentation). Verified accounts would help, but we would need this for all contributions of definitions.

Note that I'm not suggesting to not do this, but we need to think about the security implications (and get these reviewed). While this requires more discussion and investigation, my proposal above is to start distributing definitions in a way that avoids the need for more sophisticated security measures.

[Chuxel]

From a security point of view, it matters that anyone can create a GitHub account. It seems 'verfied' orgs are only available for company accounts, but not personal accounts (from what I could find in the documentation). Verified accounts would help, but we would need this for all contributions of definitions.

Ack - yeah, it looks like you can only be "verified" with the enterprise tier... which isn't corporate per-se, but the price point is high enough that teams and OSS may not have it - let alone individuals. Drat! 😭

[elaine-jackson]

An issue to consider is once the list gets large enough it's going to be incredibly tedious to scroll through even with the search functionality. I'd like to propose menus.

For example you might first select Java then a menu of possible configurations. Java 8, Java Standard (e.g. 11 or 17), Java with MariaDB, Java with Redis, etc. This would reduce menu cluttering and differentiate between a language and optional features you may need such as a database or cache.