[Feature Request]: Handle depreciated devcontainers-contrib containers

[NathanCYee]

Requested Feature

The original devcontainers-contrib account was deleted earlier this year, this left the account open for anyone to claim. This repository is referenced by many existing devcontainers which are now starting to see failing images (1, 2, 3).

I have recently claimed the account name and forked this repository. I would like to see if there is a way to have existing references to devcontainers-contrib images forward to this repository to avoid sudden failures or hand over the account to safely deal with this.

[koralowiec]

Hi Nathan! Thanks for catching that!

I'm not sure yet what to do in terms of the forwarding. Let me think about it for a bit

[bamurtaugh]

Hi @NathanCYee and @koralowiec! I'm one of the maintainers of the Dev Containers Specification. Thank you so much for raising this issue and for your great contributions to the dev container community - we really appreciate it!

My colleague @chrmarti and I would like to propose a potential path forward here that we'd be happy to drive:

• We update the Dev Containers CLI to automatically redirect from devcontainers-contrib to devcontainers-extra
• We show a warning in VS Code and Codespaces about the state of devcontainers-contrib and redirection to devcontainers-extra (to ensure users are aware and devcontainers-extra gets proper credit)
• We open up a PR to the https://github.com/devcontainers-contrib/features README with a short explanation of the scenario and solution here

Please let us know what you think!

[NathanCYee]

Hi @bamurtaugh,

Thank you for chiming in. This seems like a solid path forward and I can hand over the account for proper archival after it is complete. I also see Dependabot alerts which are used for security issues - perhaps they could be used to alert repository owners of the failing devcontainer-contrib features.

To prevent this from happening again to other repos, I was wondering if you would also be open to updating the devcontainers.github.io repository with a code of conduct for features added to collections-index.yml to properly archive the projects/accounts if they become inactive.

Please let me know if you have any feedback on this.

[koralowiec]

Hello @bamurtaugh!

Thanks for checking this out. The solution you proposed makes sense to me.

I like the @NathanCYee's idea about adding info how to archive feature collections as it may help their maintainers when they decide to close their project.

Additionally, I was wondering if it's possible to introduce a mechanism that would automatically check whether a pulled Dev Container feature is the intended one. I came across cosign which is a tool for signing containers. Maybe that could be a solution?

The features would be singed with a private key (each collection would have its own individual one). The tools like Dev Container extension and CLI could verify (using the corresponding public key) if a downloaded feature is not tampered. The public key would have to be stored somewhere publicly - It could be the additional metadata in the collection index.

I guess it could reduce the risk of introducing malicious features after squatting a GitHub namespace (so collection name). Let me know if that makes sense, maybe it can be added as an idea in a GitHub issue for the Dev Containers spec.

[bamurtaugh]

Thanks so much @NathanCYee and @koralowiec for the discussion and support!

We've opened up a PR to the CLI: devcontainers/cli#1044, and a PR to the devcontainers-contrib README: devcontainers-contrib#1.

To prevent this from happening again to other repos, I was wondering if you would also be open to updating the devcontainers.github.io repository with a code of conduct for features added to collections-index.yml to properly archive the projects/accounts if they become inactive.

Thanks for the great suggestion! We'd certainly be open to reviewing any code of conduct folks might be interested in proposing - please feel free to open a PR and tag me.

Additionally, I was wondering if it's possible to introduce a mechanism that would automatically check whether a pulled Dev Container feature is the intended one. I came across cosign which is a tool for signing containers. Maybe that could be a solution?

Thank you for this great suggestion as well. I think this would be interesting, and we'd be happy to take a feature request, though I think this may be out of scope at the moment.

[eitsupi]

Note that the steps for deprecation have already been established (devcontainers/spec#146, devcontainers/spec#163) and implemented in the CLI as of several years ago.
https://github.com/devcontainers/spec/blob/9fb374c7f29b4e3aaf55e7df69ed7514d6189dcd/docs/specs/features-legacyIds-deprecated-properties.md#2-deprecated

I believe the problem in this case is that the owner of the organization ignored this and deleted the organization and all the packages that were maintained there.

I was wondering if it's possible to introduce a mechanism that would automatically check whether a pulled Dev Container feature is the intended one.

You can use the lock file.
https://github.com/devcontainers/spec/blob/9fb374c7f29b4e3aaf55e7df69ed7514d6189dcd/docs/specs/devcontainer-lockfile.md

[koralowiec]

Heyo, I'm revisting this issue.

Currently, devcontainers-contrib is a regular GitHub user. I see that there's an option to transfer from a regular user account to an organization one: Converting a user into an organization.

@NathanCYee do you think you could do the conversion for devcontainers-contrib, and add me as an additional admin?

[evilhamsterman]

I brought this up in the devcontainers-contrib repo. I think the name devcontainers-contrib/extra should be revisited. I think a large reason why a lot of people used the original devcontainers-contrib features is that the name is easily confused to some how be officially associated with the devcontainer project.

I contributed the warning in the README, but not everyone sees the README, they just see the feature listed in on the page at containers.dev.

Though at this point maybe it's to late to rename this or another redirect would have to be created and I don't think that's a sustainable path. Maybe something on the containers.dev page to more clearly indicate community vs project features.