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"?
| 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.
There was a problem hiding this comment.
I believe he meant GAT to be stored in a temporary terminal where no-one could read that after its usage?
There was a problem hiding this comment.
Due to spectre and also due to the nature of non-windows filesystems, it'd show up in a file somewhere. I think this line should just be removed.
| * 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.
wesleytodd
left a comment
wesleytodd
left a comment
There was a problem hiding this comment.
LGTM, its long, but this is the in depth content so I think that is reasonable.
Co-authored-by: Jordan Harband <[email protected]>
Co-authored-by: Jordan Harband <[email protected]>
| 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 believe he meant GAT to be stored in a temporary terminal where no-one could read that after its usage?
ljharb
left a comment
ljharb
left a comment
There was a problem hiding this comment.
My comments still aren't addressed.
|
|
||
| **DO NOT** | ||
|
|
||
| * Transfer access tokens using end-to-end encrypted (E2EE) channels like email, Slack, and Teams |
| 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) |
| * 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. |
Original gDoc: https://docs.google.com/document/d/1OMg0U-lOIyaVbWvD47LYnNadzgmjVhp8_1wz-9kwQp0/edit?tab=t.mbtm6n9jd2ja
Related to #257