-
Notifications
You must be signed in to change notification settings - Fork 239
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: added meeting notes from 2022-08-17
- Loading branch information
1 parent
9703d3c
commit d8a72cc
Showing
1 changed file
with
92 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,92 @@ | ||
| #### Meeting from: August 17th, 2022 | ||
|
|
||
| # Open RFC Meeting (npm) | ||
|
|
||
| ### Attendees | ||
| - Darcy Clarke (@darcyclarke) | ||
| - Nathan LaFreniere (@nlf) | ||
| - Philip Harrison (@feelepxyz) | ||
| - Rick Markins (@rxmarbles) | ||
| - Ruy Adorno (@ruyadorno) | ||
| - Jordan Harband (@ljharb) | ||
| - Gar (@wraithgar) | ||
| - Brian DeHamer (@bdehamer) | ||
| - Zach Steindler (@steiza) | ||
| - Owen Buckley (@thescientist13) | ||
|
|
||
| ### Agenda | ||
|
|
||
| 1. **Housekeeping** | ||
| 1. Code of Conduct Acknowledgement | ||
| 1. Outline Intentions & Desired Outcomes | ||
| 1. Announcements | ||
| 1. Introduction(s) | ||
| 1. **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb | ||
| 1. **PR**: [#593 RFC: Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @thescientist13 | ||
| 1. **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @feelepxyz | ||
| 1. **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic | ||
|
|
||
| ### Notes | ||
|
|
||
| #### **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb | ||
| - @nlf | ||
| - have now added this context | ||
|
|
||
| #### **PR**: [#593 RFC: Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @thescientist13 | ||
| - @darcyclarke | ||
| - Audit Policies (WIP) RFC: https://hackmd.io/RxIFqXTaRPeqKp9xokZZMA | ||
| - @thescients13 | ||
| - updated RFC to use `npm query` | ||
| - can be re-reviewed | ||
| - will ensure they can follow up | ||
|
|
||
| #### **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @feelepxyz | ||
| - @feelepxyz | ||
| - many comments asking about how to allow personal machines to sign packages | ||
| - also, people have asked about pre-built binaries | ||
| - @mylesborins | ||
| - there is an existing RFC for "Distributions" | ||
| - supporting pre-built binaries seems out of scope because this usecases are for things that happen post-install (ref. https://github.com/npm/rfcs/pull/519 Package Distributions is a separate, orthogonal) | ||
| - requirements for building in CI | ||
| - @ljharb | ||
| - getting conflicting messages in the conversation on the RFC | ||
| - _assuming_ that the process must be built on a trusted system for the provance to be considered a | ||
| - things like pre-builds would also have to be trusted prior | ||
| - what thought has been put into server-side behaivour approach (vs. putting this infront of the end-user) | ||
| - @mylesborins | ||
| - do not want vendor lock-in | ||
| - want to work with third-parties | ||
| - want to help solve the auditability of the build/source of the package | ||
| - this does not prevent malicious software from being published | ||
| - this work makes auditing streamlined/easy to do | ||
| - what's important is the third-party | ||
| - @ljharb | ||
| - want to propose an altered order of prioritization | ||
| - put something in sigstore about the package today | ||
| - unresolve: how do you trust the claim is correct | ||
| - then work on way to allow people to self-sign | ||
| - then work on gradular backfill for top `X` impactful packages | ||
| - goal here seems to be, find a way to reliably measure if the code in the tarball is accurate to the repo | ||
| - why is "how" it was created important? | ||
| - @mylesborins | ||
| - most packages aren't 1:1 with their source counterpart | ||
| - @steiza | ||
| - seems like 3 goals: | ||
| - 1. create public audit log as to how something was built | ||
| - 2. linking a package back to it's source | ||
| - 3. distributing package signatures to a third-party | ||
| - do need to consider what happens when the link/sourcer is deleted | ||
| - not sure who is responsible for validating this | ||
| - @feelepxyz | ||
| - have been thinking about how to create this signature outside of npm (ex. publishes machine) | ||
| - seems to guarantee if npm is compromised | ||
| - this work also outlines how identities are handled | ||
| - this also lays the groundwork for any future | ||
| - creates a vendor neutral space | ||
| - want to also bubble up the idea of expanding the types of events we add into the ledger | ||
| - OpenSSF is looking at standardizing the types of events | ||
| - @steiza | ||
| - not super familiar with Rekor but the OpenSSF/Sigstore teams are looking into how to mask data for security/safety/compliance with GDPR/DMCS-type requests | ||
|
|
||
| #### **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic | ||
| - Will keep this on our radar |