Requested Feature
Many corporations have standard Man-in-the-Middle certificate interception turned on. Doing this can cause havoc with package managers that pin their own certificate bundles (in my current immediate case, node/npm).
While there's a variety of ways to configure package managers, in many cases the avenues available to me occur too late in the build cycle.
Consider:
{
"image": "mcr.microsoft.com/devcontainers/base:3.0.7-ubuntu26.04",
"containerEnv": {
"NODE_USE_SYSTEM_CA": "1",
},
"features": {
"ghcr.io/my-org/private-cert-install-feature:latest": {},
"ghcr.io/devcontainers-extra/features/pre-commit:2.0.18": {
"version": "4.6.2"
},
"ghcr.io/devcontainers-extra/features/npm-packages:1.0.1": {
"packages": "@commitlint/cli@21.2.2,@commitlint/config-conventional@21.2.2",
},
},
}
Here, while the containerEnv directive would set the environment variable for any node project that was being actively developed, it is actually only set after features are installed (specifically npm-packages), just before container start. And this isn't for a node project, only to use commitlint. In this case, container build seems to hang due to NPM install retries.
Things that work
- Stub image build that sets an
ENV; somewhat "impure".
- Prebuilding on external CI infrastructure; doesn't work for initial exploration.
Things that don't work
- Adding code to
private-cert-install-feature to set arbitrary variables to point to the built trust bundle; The variables aren't visible to later feature installs because they run as sh processes, not as bash/login shells.
- Adding the variables to the
containerEnv section of private-cert-install-feature; would set the variable appropriately, except
- The feature would have to know about all possible package managers that behave this way
- Different host distros use different trust bundle paths, and the value has to be set at publish time, not container build time.
What I'd like
Some way to control the certificate store used during the process for the NPM feature, eg:
"ghcr.io/devcontainers-extra/features/npm-packages:1.0.1": {
"packages": "@commitlint/cli@21.2.2,@commitlint/config-conventional@21.2.2",
"use_system_cert_store": true,
},
Requested Feature
Many corporations have standard Man-in-the-Middle certificate interception turned on. Doing this can cause havoc with package managers that pin their own certificate bundles (in my current immediate case, node/npm).
While there's a variety of ways to configure package managers, in many cases the avenues available to me occur too late in the build cycle.
Consider:
{ "image": "mcr.microsoft.com/devcontainers/base:3.0.7-ubuntu26.04", "containerEnv": { "NODE_USE_SYSTEM_CA": "1", }, "features": { "ghcr.io/my-org/private-cert-install-feature:latest": {}, "ghcr.io/devcontainers-extra/features/pre-commit:2.0.18": { "version": "4.6.2" }, "ghcr.io/devcontainers-extra/features/npm-packages:1.0.1": { "packages": "@commitlint/cli@21.2.2,@commitlint/config-conventional@21.2.2", }, }, }Here, while the
containerEnvdirective would set the environment variable for any node project that was being actively developed, it is actually only set after features are installed (specificallynpm-packages), just before container start. And this isn't for a node project, only to use commitlint. In this case, container build seems to hang due to NPM install retries.Things that work
ENV; somewhat "impure".Things that don't work
private-cert-install-featureto set arbitrary variables to point to the built trust bundle; The variables aren't visible to later feature installs because they run asshprocesses, not asbash/login shells.containerEnvsection ofprivate-cert-install-feature; would set the variable appropriately, exceptWhat I'd like
Some way to control the certificate store used during the process for the NPM feature, eg: