Upload v2 Secure Releases Guide Markdown #283
Conversation
|
|
||
| **DO NOT** | ||
|
|
||
| * Transfer access tokens using end-to-end encrypted (E2EE) channels like email, Slack, and Teams |
There was a problem hiding this comment.
"like email, Slack, and Teams" and "like Signal and Whatsapp" aren't meaningfully different to me, and don't give me any info how to figure out whether a service is in the "do" or "do not" category, nor why these are in these categories.
are perhaps these meant to be "non-E2EE"?
|
|
||
| * Transfer access tokens using end-to-end encrypted (E2EE) channels like email, Slack, and Teams | ||
| * Copy access tokens or recovery codes into your clipboard (especially on Linux and Windows) | ||
| * Print out access tokens or recovery codes using a that does not belong to you (such as a work printer) |
There was a problem hiding this comment.
| * Print out access tokens or recovery codes using a that does not belong to you (such as a work printer) | |
| * Print out access tokens or recovery codes using a printer that does not belong to you (such as a work printer) |
|
|
||
| *Safe Storage and Use of Access Tokens* | ||
|
|
||
| The npm CLI uses the .npmrc file for configuration. Included in this file is the _AuthToken variable, which npm uses to authenticate to the public registry or a private registry. Npm’s decision to store access tokens in a plain text file is inherently unsafe and additional measures must be taken to properly use and store it. |
There was a problem hiding this comment.
| The npm CLI uses the .npmrc file for configuration. Included in this file is the _AuthToken variable, which npm uses to authenticate to the public registry or a private registry. Npm’s decision to store access tokens in a plain text file is inherently unsafe and additional measures must be taken to properly use and store it. | |
| The npm CLI uses the .npmrc file for configuration. Included in this file is the _AuthToken variable, which npm uses to authenticate to the public registry or a private registry. npm’s decision to store access tokens in a plain text file is inherently unsafe and additional measures must be taken to properly use and store it. |
| This scenario has many potential approaches. First, use the correct access token for the job: | ||
|
|
||
| * GATs should never be stored on a local hard drive (eg: in an .npmrc file) |
There was a problem hiding this comment.
i'm confused; afaik this is the only way to store it.
| * Is automatically granted read/write permissions for new packages added to the organization. | ||
| * Cannot be removed from organization packages. | ||
|
|
||
| Given these behaviors, it’s recommended to not use the developers team when granting users write access to packages. Instead, set its access to read for each existing package in the organization. |
There was a problem hiding this comment.
instead of "set its access to read", i'd suggest making a different team for each package, adding the package to that team, and then removing the package from the developers team. (the order matters) ie, your next section
meaning, the developers team should have zero packages on it at all.
notably, there is no "read" and "write" - either you have full 100% owner access on a package, or you have zero access to a package.
Original gDoc: https://docs.google.com/document/d/1OMg0U-lOIyaVbWvD47LYnNadzgmjVhp8_1wz-9kwQp0/edit?tab=t.mbtm6n9jd2ja
Related to #257