-
Notifications
You must be signed in to change notification settings - Fork 40
Closed
Description
What
Add support for registry-scoped certfile and keyfile options, e.g.
{
"//my.registry.example/npm/:certfile": "~/.secret/stuff.crt",
"//my.registry.example/npm/:keyfile": "~/.secret/stuff.key"
}Why
- Currently you can only set a
certandkeyat the top level, which means it could be used in connections against any registry. If your options are coming from@npmcli/config, then there's not a good way to control this. Ideally a client certificate would only be presented to the registry that actually needs it, and you should be able to use different ones depending on the registry. - The current
certandkeyoptions are the actual contents of the cert/key, rather than paths to them. If your options are coming from@npmcli/config, and the cert/key are auto-generated elsewhere, you need to then keep your use.npmrcin sync with that process or specify them as env vars. Both options potentially weaken security (e.g. could be accidentally checked in,.npmrcmight be readable by other users, key could be extracted from/proc/<pid>/environ, etc.).
Current Workarounds
- Specify
npm_config_certandnpm_config_keyenv vars:- You also have to specify some (possibly bogus) credentials due to [BUG] ENEEDAUTH when authenticating against a registry via mTLS cli#4765.
- If your registry validates the explicit credentials (in addition to mTLS) this may not work
- Security concerns (see
Whysection)
- Dynamically generate a temp
.npmrcwith the desired settings and use it vianpm_config_userconfig:- You also have to specify some (possibly bogus) credentials due to [BUG] ENEEDAUTH when authenticating against a registry via mTLS cli#4765.
- If your registry validates the explicit credentials (in addition to mTLS) this may not work
- Security concerns (see
Whysection)
- Spin up a local mTLS proxy to your registry and use it via HTTP_PROXY (or other env/config)
- May still require you to specify some (bogus) credentials due to [BUG] ENEEDAUTH when authenticating against a registry via mTLS cli#4765.
- Monkey-patch
npm-registry-fetchto inject thekey/certas necessary- May still require you to specify some (bogus) credentials, or monkey-patch
@npmcli/configas well 😅
- May still require you to specify some (bogus) credentials, or monkey-patch
All the workarounds are problematic, and get even more complicated in dual-publishing scenarios. For example, you might want to scope the (bogus) credentials, but that can't be done via env vars due to this bug.
Notes
- I'd be happy to put together PRs around this if the idea is acceptable. A corresponding change would likely also be needed to
getCredentialsByURI/etc. in@npmcli/config - This feature is related to [FEATURE] Raise
ENEEDAUTHerror if doing a write to something other than login #38 and [BUG] ENEEDAUTH when authenticating against a registry via mTLS cli#4765 in the sense that these could be considered new authN-related options, i.e. custom registry authN could solely be done via mTLS, in which case we shouldn't throwENEEDAUTHif these are set but token/credentials are not.
Metadata
Metadata
Assignees
Labels
No labels