From e56d9b2ba03351370d575b7cfb8110a899126586 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Mon, 21 Oct 2019 17:05:09 +0300 Subject: [PATCH 01/12] Add 2FA doc outline --- docs/drafts/2fa.md | 47 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 docs/drafts/2fa.md diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md new file mode 100644 index 00000000..4546ce92 --- /dev/null +++ b/docs/drafts/2fa.md @@ -0,0 +1,47 @@ +# Baseline practice: use 2FA when publishing + +## Potential solutions + +### Release manager + +- Cons: + - complexity + - compatibility + - effort to build + - maintenance + +### Remote OTP + +#### Approval via mobile + +POC: https://github.com/nearform/optic + +- Cons: + - dependency on Firebase + - needs a server + +#### Entry via chatbot + +POC: ask https://twitter.com/MarshallOfSound + +- Cons: + - dependency on Slack + - needs a server + - needs the OTP to actually be typed out + +#### SaaS + +- Cons: + - none publicly available and free + - trust + +### Use remote decryption service + +- Cons: + - requires setup + +### Use GitHub releases / alternative registries for staging + +Cons: + - requires setup + - requires a manual action From 6e086f54d2d2c36716200b035a77c4fcb7a0cd5d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sat, 9 Nov 2019 11:53:56 +0200 Subject: [PATCH 02/12] Add 2FA doc intro --- docs/drafts/2fa.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index 4546ce92..0b3fe9e8 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -1,4 +1,20 @@ -# Baseline practice: use 2FA when publishing +# Baseline practice: using 2FA when publishing + +To avoid malicious use of stolen package registry tokens, it is advisable to enable two-factor authentication (2FA). When it is enabled every call to `npm publish` requires a unique one time password (OTP) to be entered. + +To make sure that the code is a _second_ factor it should be generated by a human on an independent device. The secret seed of the OTP generator should be protected in such a way, that it cannot be obtained together with the registry token. + +At the moment, the advice to use 2FA is at odds with advice to automate the testing and release processes, esp. with publishing automatically from Continuous Integration (CI) systems (e.g. Travis). + +This document outlines possible solutions to bridge this gap with the goal of enabling easy setup of automated releases from CI, using 2FA (human approval), for individuals and for teams. + +## Related docs + +* [Publish guidelines (draft)](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/PUBLISH-GUIDELINES.md) +* [CI/CD guidelines (draft)](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/ci-cd-guidelines.md) +* [Testing guidelines (draft)](https://github.com/nodejs/package-maintenance/blob/master/docs/drafts/testing-guidelines.md) + +Note: at the time of writing neither documents or gives advice on using two-factor authentication when publishing. ## Potential solutions @@ -42,6 +58,6 @@ POC: ask https://twitter.com/MarshallOfSound ### Use GitHub releases / alternative registries for staging -Cons: +- Cons: - requires setup - requires a manual action From eed234b82f297b5f4f27f89b09ca8dbbf64560c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sun, 10 Nov 2019 11:11:28 +0000 Subject: [PATCH 03/12] Add 2FA options - release manager, ci extensions --- docs/drafts/2fa.md | 53 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 46 insertions(+), 7 deletions(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index 0b3fe9e8..b51ff148 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -18,13 +18,45 @@ Note: at the time of writing neither documents or gives advice on using two-fact ## Potential solutions +All of the listed solutions below have their pros and cons. While the order of desireability of these solutions has been discussed, the list below does not imply any order of preferences. + ### Release manager -- Cons: - - complexity - - compatibility - - effort to build - - maintenance +The release manager could be a place where packages are staged after `npm publish` without an OTP. A human would need to use the manager (CLI/GUI) and could release one or more pending packages, approving the publishing with an OTP. This would need be implemented by the registry (for public packages - npm). + +Such a manager should enable further tooling to integrate notifications and approvals via email or chat systems. + +The primary benefit of this is the simplicity of using this for teams - the CI can publish the package under a bot account + +Possible complications: + +- Are the version numbers reserved once published/staged? +- Are the users allowed to install the "staged" packages by explicitly opting in? +- Existing tooling may already be too dependent on a specific version becoming visible in the registry immediately after publish. +- Can this be standardized enough to work with alternative registries? +- This may required signficant effort to build and maintain, incl. by npm Inc. + +Poor man's version: + +- Allow adding a 2FA approval on specific versions retroactively. This would allow tooling to be built on the consumer side to avoid non-2FA releases, while the maintainers keep the option of "singing off" the releases. + +### Extension in CI providers + +As 2FA in CI is partly a problem because there is no way to enter the OTP, it can be solved by simply adding a way to enter an OTP in CI. + +For maximum usability, the required input should integrate with various ways of notifying the maintainers, possibly by also allowing the input via the notification channels (e.g. chatbots), and should provide for graceful timeouts. + +Some CI systems (e.g. Jenkins) already do have some form of user input at build time. + +Possible complications: + +- Requires a lot of coordination with many different CI providers. While Travis is the de-facto standard in the npm ecosystem and Github Actions have a lot of initial traction, there are many other systems. +- The cost of building such a feature is likely non-negligible for the CI providers (input is harder than output), even if the feature itself may have many other practical applications. +- The setup would vary system by system, which could lead to unnecessary complexity in the ecosystem (esp. for maintainers who contribute to multiple projects). +- Unclear if there's an easy way to make the input work for teams, because the 2FA is tied to a single identity, i.e. who can enter the OTP when the CI is waiting for it? + - Could be solved by configuring multiple publish tokens and selecting the correct one, but this requires configuration complexity. + - Could be solved by using a team account to publish, but this requires sharing a secret across the team. + - Could be solved by using the identity of the person who kicked off the release build (i.e. the person who merged a PR), but this requires interpersonal coordination and couples merge priveleges with publish priveleges. ### Remote OTP @@ -51,13 +83,20 @@ POC: ask https://twitter.com/MarshallOfSound - none publicly available and free - trust -### Use remote decryption service +### Remote decryption service - Cons: - requires setup -### Use GitHub releases / alternative registries for staging +### Alternative registries/release repositories for staging - Cons: - requires setup - requires a manual action + +### Alternative second factors (e.g. package signing) + + +## Somewhat related other ideas + +- Registries should allow including a meta field to link back to the CI job used to publish a specific version for audit purposes. From f9ee289f8d29963fb5a5939a19478f5d6c682d80 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sun, 10 Nov 2019 11:49:29 +0000 Subject: [PATCH 04/12] Add 2FA options - remote OTP entry --- docs/drafts/2fa.md | 81 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 62 insertions(+), 19 deletions(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index b51ff148..a251aa26 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -57,46 +57,89 @@ Possible complications: - Could be solved by configuring multiple publish tokens and selecting the correct one, but this requires configuration complexity. - Could be solved by using a team account to publish, but this requires sharing a secret across the team. - Could be solved by using the identity of the person who kicked off the release build (i.e. the person who merged a PR), but this requires interpersonal coordination and couples merge priveleges with publish priveleges. +- Notification fatigue. ### Remote OTP -#### Approval via mobile +The below options all center around an idea that a CI job would make a request to a pre-configured somewhat-secret URL, which would trigger a notification to the maintainer, whereby they could enter the OTP. + +It's worth noting, that there are already existing commercial system thsat are used in enterprise settings to provide a second factor via mobile notifications, calls and SMS. However these systems are complex and likely too expensive for small OSS teams and sole maintainers. + +Possible complications: + +- Similar to the extension in CI providers, there could be complexity in setting things up for teams (i.e. selecting the correct publish tokens and humans for providing the OTP). +- Server costs (all of the below require servers for making requests, which depending on the approach could be long running requests, i.e. they could be costly even on serverless implementations). While it is possible to design a system which relies on a public git repository as a backing store, there may additionaly be database costs. +- Maintenance costs (the software running on the servers needs to be updated, monitored, etc) +- Trust problems (depending on the approach, a third party system might be undesirable, as it may be hard to ensure that such a third party is unable to retrieve the secret OTP generator seed). +- Notification fatigue. + +#### Remote OTP entry via mobile POC: https://github.com/nearform/optic -- Cons: - - dependency on Firebase - - needs a server +The POC is a PWA, which can be added to the home screen. It allows scanning a QR code to initialize the OTP generator and can work as a standalone authenticator application. Once a token is configured, it provides a URL which responds with the OTP after the maintainer pushes the "Approve" button on their phone/browser. + +The CI system can be configured to wait for a response from this URL just before publishing and to provide the code to npm via `--otp` or an environment variable. + +Additional cons: + +- Dependency on Firebase to deliver notifications (vendor lock in, possible costs). +- Needs a server. +- Likely should not be trusted to be run by a third party, i.e. a maintainer should run a private instace of this, unless a trustworthy organization would be able to do that (npm Inc.? OpenJS Foundation? One of major Node.js contributor organizations?). + +Missing features: -#### Entry via chatbot +- Impossible to move to another device without resetting the URL, i.e. changing the phone requires re-configuration of CI. +- Possibly scary, as the first thing it asks for is the generator secret (i.e. needs UX and documentation work). + +#### Remote OTP entry via chatbot -POC: ask https://twitter.com/MarshallOfSound +POC: still on it's way to be OSS - ask https://twitter.com/MarshallOfSound for details + +The POC is a chatbot integration. There is an API endpoint which can be trigger a question and another endpoint which can be polled for the response. + +The CI system can be configured to use a client module which deals with the API. + +Additional cons: + +- Dependency on Slack. +- Needs a server. +- Needs the OTP to actually be typed out. + +#### Remote OTP entry via authentication SaaS provider + +As there are existing commercial systems to provide 2FA APIs to organization, these could potentialy be used for OSS. + +Possible providers: -- Cons: - - dependency on Slack - - needs a server - - needs the OTP to actually be typed out +- Duo +- Authy +- Okta +- Auth0 -#### SaaS +Additional cons: -- Cons: - - none publicly available and free - - trust +- Would require reaching out to providers and negotiating to get a free-for-OSS plan. +- Trust. +- Vendor lock-in. ### Remote decryption service -- Cons: - - requires setup +Cons: +- requires setup ### Alternative registries/release repositories for staging -- Cons: - - requires setup - - requires a manual action +Cons: +- requires setup +- requires a manual action ### Alternative second factors (e.g. package signing) +Similar to using a decryption service ## Somewhat related other ideas - Registries should allow including a meta field to link back to the CI job used to publish a specific version for audit purposes. +- npm client should have an `otpUrl` config option in `.npmrc`. While it is easy enough to provide a `--otp=$(curl http://example.com)`, depending on publishing methods used (e.g. `semantic-release`), such an integration is trickier. +- Managing the publish tokens in CI can be cumbersome, esp. if you have a lot of repos - there is scope for more tooling to deal with Travis, Github Actions APIs to mass-manage multiple repos as a member of multiple organizations and as an organization. From 55f60b4514da6dd7b1675f29d8c7402713865cb6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sun, 10 Nov 2019 12:10:36 +0000 Subject: [PATCH 05/12] Add 2FA options - remote decryption services, alternative registries as staging --- docs/drafts/2fa.md | 35 ++++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index a251aa26..6957b11e 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -38,7 +38,7 @@ Possible complications: Poor man's version: -- Allow adding a 2FA approval on specific versions retroactively. This would allow tooling to be built on the consumer side to avoid non-2FA releases, while the maintainers keep the option of "singing off" the releases. +- Allow adding a 2FA approval on specific versions retroactively. This would allow tooling to be built on the consumer side to avoid non-2FA releases, while the maintainers keep the option of "singing off" the releases at their convenience - tooling can be built to help these tasks as well. ### Extension in CI providers @@ -63,7 +63,9 @@ Possible complications: The below options all center around an idea that a CI job would make a request to a pre-configured somewhat-secret URL, which would trigger a notification to the maintainer, whereby they could enter the OTP. -It's worth noting, that there are already existing commercial system thsat are used in enterprise settings to provide a second factor via mobile notifications, calls and SMS. However these systems are complex and likely too expensive for small OSS teams and sole maintainers. +It's worth noting, that there are already existing commercial system that are used in enterprise settings to provide a second factor via mobile notifications, calls and SMS. However these systems are complex and likely too expensive for small OSS teams and sole maintainers. + +The major benefit of this is that this works today, with existing tooling (at least a POC level) and does not depend on any third party action (even if it could potentially be helpful). Possible complications: @@ -120,26 +122,41 @@ Possible providers: Additional cons: - Would require reaching out to providers and negotiating to get a free-for-OSS plan. -- Trust. +- Trusting a third party. - Vendor lock-in. ### Remote decryption service +(krypt.co?) provides a way to have private keys stored on the mobile phone and use them for remote signing. This means that a CI system can be configured to have the encrypted OTP generator seed on it, and the decryption would be requested via an API. The maintainer can then approve the access to the seed, which can be used to generate the OTP and pass it to `npm publish`. + +Alternatively, if package registries accepted package signatures as a second factor, the service could be used to sign the package remotely, using a personal device. + Cons: -- requires setup + +- Potentially complicated setup. +- Trusting a third party. +- Vendor lock-in. ### Alternative registries/release repositories for staging -Cons: -- requires setup -- requires a manual action +While it is hard to integrate CI systems and the public npm registry _with_ 2FA today, a small scale release manager can be built by using non-npm registries or GitHub Releases as a staging area. + +The CI system could be set up to publish packages into an alternative registry or to upload the tarball to a release artifact storage area. Tooling can then be built to query such storage areas for unpublished packages and it could possibly publish things en-masse. + +Such tooling can be further extended to e.g. allow pre-publishing unsigned packages under a different scope even on a public npm registry, to allow e.g. easy nightly releases or a way to manage the release of commercially supported versions (see `@commercial` scope of Hapi.js). -### Alternative second factors (e.g. package signing) +The major benefit of this approach is team management - anyone with publish access could run `npm publish [tarball URL]` to unstage a release. The tarball sha hash could also be pre-pushed by the CI system into the release storage area for integrity verification. + +Cons: -Similar to using a decryption service +- Requires potentially complex setup. +- Requires a manual action on the maintainer's computer, with a non-obvious notification mechanism. +- Requires tooling to be built and maintained. +- GitHub release assets are mutable (?). ## Somewhat related other ideas - Registries should allow including a meta field to link back to the CI job used to publish a specific version for audit purposes. - npm client should have an `otpUrl` config option in `.npmrc`. While it is easy enough to provide a `--otp=$(curl http://example.com)`, depending on publishing methods used (e.g. `semantic-release`), such an integration is trickier. - Managing the publish tokens in CI can be cumbersome, esp. if you have a lot of repos - there is scope for more tooling to deal with Travis, Github Actions APIs to mass-manage multiple repos as a member of multiple organizations and as an organization. +- It's been a long standing request from the community (regardless of whether it solves any problem) to have package signatures. The tooling for staged releases/alternative registries and remote decryption/signing services could be used to also publish the signatures on GitHub releases. From 5d6a4541171230709274af1a139f59621d0d494f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sun, 10 Nov 2019 12:11:30 +0000 Subject: [PATCH 06/12] More ideas --- docs/drafts/2fa.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index 6957b11e..1e78f6c7 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -147,6 +147,8 @@ Such tooling can be further extended to e.g. allow pre-publishing unsigned packa The major benefit of this approach is team management - anyone with publish access could run `npm publish [tarball URL]` to unstage a release. The tarball sha hash could also be pre-pushed by the CI system into the release storage area for integrity verification. +Another feature that could be built on top of this is using the tarballs directly from build artifacts as input into CITGM for package ecosystems. + Cons: - Requires potentially complex setup. From 7d23c85289be4f8e22b441ee07a1361118b394d0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Sun, 10 Nov 2019 13:34:28 +0000 Subject: [PATCH 07/12] Security note --- docs/drafts/2fa.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index 1e78f6c7..e022a5dc 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -162,3 +162,4 @@ Cons: - npm client should have an `otpUrl` config option in `.npmrc`. While it is easy enough to provide a `--otp=$(curl http://example.com)`, depending on publishing methods used (e.g. `semantic-release`), such an integration is trickier. - Managing the publish tokens in CI can be cumbersome, esp. if you have a lot of repos - there is scope for more tooling to deal with Travis, Github Actions APIs to mass-manage multiple repos as a member of multiple organizations and as an organization. - It's been a long standing request from the community (regardless of whether it solves any problem) to have package signatures. The tooling for staged releases/alternative registries and remote decryption/signing services could be used to also publish the signatures on GitHub releases. +- Package signing from CI might not be good enough, as the CI job is triggered by a merge, which is not protected by 2FA. From 27f4e95e36e20b930f9caceacdb2db9ac4aee183 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Mon, 11 Nov 2019 10:27:15 +0000 Subject: [PATCH 08/12] Fix a link --- docs/drafts/2fa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index e022a5dc..b3424f14 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -127,7 +127,7 @@ Additional cons: ### Remote decryption service -(krypt.co?) provides a way to have private keys stored on the mobile phone and use them for remote signing. This means that a CI system can be configured to have the encrypted OTP generator seed on it, and the decryption would be requested via an API. The maintainer can then approve the access to the seed, which can be used to generate the OTP and pass it to `npm publish`. +[krypt.co](https://krypt.co) provides a way to have private keys stored on the mobile phone and use them for remote signing. This means that a CI system can be configured to have the encrypted OTP generator seed on it, and the decryption would be requested via an API. The maintainer can then approve the access to the seed, which can be used to generate the OTP and pass it to `npm publish`. Alternatively, if package registries accepted package signatures as a second factor, the service could be used to sign the package remotely, using a personal device. From 09035d7c5bdd5e82bec97f39596b452ebd6991ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Mon, 11 Nov 2019 16:24:45 +0000 Subject: [PATCH 09/12] Reword to avoid presenting automated releases as an agreed best practice --- docs/drafts/2fa.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index b3424f14..337363d7 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -4,7 +4,9 @@ To avoid malicious use of stolen package registry tokens, it is advisable to ena To make sure that the code is a _second_ factor it should be generated by a human on an independent device. The secret seed of the OTP generator should be protected in such a way, that it cannot be obtained together with the registry token. -At the moment, the advice to use 2FA is at odds with advice to automate the testing and release processes, esp. with publishing automatically from Continuous Integration (CI) systems (e.g. Travis). +When releases are created by humans running `npm publish` (or via tooling such us [np](https://www.npmjs.com/package/np) or [publish-please](https://www.npmjs.com/package/publish-please)) on their local environments, using 2FA is not an issue. + +However, some maintainers prefer automating the release process (e.g. by using [semantic-release](https://semantic-release.gitbook.io/semantic-release/) or [merge-release](https://github.com/mikeal/merge-release)) and publishing directly from their Continuous Integration (CI) systems (e.g. Travis). This is at odds with advice to use 2FA, as there usually is no obvious way to provide the OTP for the publish command. This document outlines possible solutions to bridge this gap with the goal of enabling easy setup of automated releases from CI, using 2FA (human approval), for individuals and for teams. @@ -16,7 +18,7 @@ This document outlines possible solutions to bridge this gap with the goal of en Note: at the time of writing neither documents or gives advice on using two-factor authentication when publishing. -## Potential solutions +## Potential solutions for 2FA in CI All of the listed solutions below have their pros and cons. While the order of desireability of these solutions has been discussed, the list below does not imply any order of preferences. From 1d1cecf3f54cddbccaacabe9ff84c4a1f3d34c6e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Tue, 12 Nov 2019 15:32:28 +0000 Subject: [PATCH 10/12] Add links to auth SaaS providers --- docs/drafts/2fa.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index 337363d7..c00f5e8c 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -116,10 +116,10 @@ As there are existing commercial systems to provide 2FA APIs to organization, th Possible providers: -- Duo -- Authy -- Okta -- Auth0 +- [Duo](https://duo.com/product/multi-factor-authentication-mfa) +- [Authy](https://authy.com) (with [Twilio](https://www.twilio.com/docs/authy)?) +- [Okta](https://www.okta.com/products/adaptive-multi-factor-authentication/) +- [Auth0](https://auth0.com/docs/multifactor-authentication) Additional cons: From 5db216160e89c81101db545c79296c58db00cd66 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Tue, 12 Nov 2019 18:23:24 +0000 Subject: [PATCH 11/12] Clarify 2FA "non-issue" when publishing manually --- docs/drafts/2fa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index c00f5e8c..3c37934c 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -4,7 +4,7 @@ To avoid malicious use of stolen package registry tokens, it is advisable to ena To make sure that the code is a _second_ factor it should be generated by a human on an independent device. The secret seed of the OTP generator should be protected in such a way, that it cannot be obtained together with the registry token. -When releases are created by humans running `npm publish` (or via tooling such us [np](https://www.npmjs.com/package/np) or [publish-please](https://www.npmjs.com/package/publish-please)) on their local environments, using 2FA is not an issue. +When releases are created by humans running `npm publish` (or via tooling such us [np](https://www.npmjs.com/package/np) or [publish-please](https://www.npmjs.com/package/publish-please)) on their local environments, the user is present to manually input the OTP when prompted. However, some maintainers prefer automating the release process (e.g. by using [semantic-release](https://semantic-release.gitbook.io/semantic-release/) or [merge-release](https://github.com/mikeal/merge-release)) and publishing directly from their Continuous Integration (CI) systems (e.g. Travis). This is at odds with advice to use 2FA, as there usually is no obvious way to provide the OTP for the publish command. From 1a609706193bdb9febdfa76134ff474c0130b511 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dominykas=20Blyz=CC=8Ce=CC=87?= Date: Thu, 14 Nov 2019 13:42:10 +0200 Subject: [PATCH 12/12] Clarify release manager implementation --- docs/drafts/2fa.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/drafts/2fa.md b/docs/drafts/2fa.md index 3c37934c..cdb04e18 100644 --- a/docs/drafts/2fa.md +++ b/docs/drafts/2fa.md @@ -24,7 +24,7 @@ All of the listed solutions below have their pros and cons. While the order of d ### Release manager -The release manager could be a place where packages are staged after `npm publish` without an OTP. A human would need to use the manager (CLI/GUI) and could release one or more pending packages, approving the publishing with an OTP. This would need be implemented by the registry (for public packages - npm). +The release manager could be a place where packages are staged after `npm publish` without an OTP. A human would need to use the manager (CLI/GUI) and could release one or more pending packages, approving the publishing with an OTP. This would need be implemented by the registry (for public packages - npm) or as a separate application, allowing "proxy" publishing. Such a manager should enable further tooling to integrate notifications and approvals via email or chat systems. @@ -36,7 +36,7 @@ Possible complications: - Are the users allowed to install the "staged" packages by explicitly opting in? - Existing tooling may already be too dependent on a specific version becoming visible in the registry immediately after publish. - Can this be standardized enough to work with alternative registries? -- This may required signficant effort to build and maintain, incl. by npm Inc. +- This may required significant effort to build and maintain, incl. by npm Inc. Poor man's version: