|
| 1 | +#### Meeting from: August 17th, 2022 |
| 2 | + |
| 3 | +# Open RFC Meeting (npm) |
| 4 | + |
| 5 | +### Attendees |
| 6 | +- Darcy Clarke (@darcyclarke) |
| 7 | +- Nathan LaFreniere (@nlf) |
| 8 | +- Philip Harrison (@feelepxyz) |
| 9 | +- Rick Markins (@rxmarbles) |
| 10 | +- Ruy Adorno (@ruyadorno) |
| 11 | +- Jordan Harband (@ljharb) |
| 12 | +- Gar (@wraithgar) |
| 13 | +- Brian DeHamer (@bdehamer) |
| 14 | +- Zach Steindler (@steiza) |
| 15 | +- Owen Buckley (@thescientist13) |
| 16 | + |
| 17 | +### Agenda |
| 18 | + |
| 19 | +1. **Housekeeping** |
| 20 | + 1. Code of Conduct Acknowledgement |
| 21 | + 1. Outline Intentions & Desired Outcomes |
| 22 | + 1. Announcements |
| 23 | + 1. Introduction(s) |
| 24 | +1. **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb |
| 25 | +1. **PR**: [#593 RFC: Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @thescientist13 |
| 26 | +1. **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @feelepxyz |
| 27 | +1. **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic |
| 28 | + |
| 29 | +### Notes |
| 30 | + |
| 31 | +#### **Issue**: [#622 [RRFC] include context that a module is overridden in npm ls](https://github.com/npm/rfcs/issues/622) - @bnb |
| 32 | +- @nlf |
| 33 | + - have now added this context |
| 34 | + |
| 35 | +#### **PR**: [#593 RFC: Only Registry Dependencies](https://github.com/npm/rfcs/pull/593) - @thescientist13 |
| 36 | +- @darcyclarke |
| 37 | + - Audit Policies (WIP) RFC: https://hackmd.io/RxIFqXTaRPeqKp9xokZZMA |
| 38 | +- @thescients13 |
| 39 | + - updated RFC to use `npm query` |
| 40 | + - can be re-reviewed |
| 41 | + - will ensure they can follow up |
| 42 | + |
| 43 | +#### **PR**: [#626 RFC for linking packages to their source and build](https://github.com/npm/rfcs/pull/626) - @feelepxyz |
| 44 | +- @feelepxyz |
| 45 | + - many comments asking about how to allow personal machines to sign packages |
| 46 | + - also, people have asked about pre-built binaries |
| 47 | +- @mylesborins |
| 48 | + - there is an existing RFC for "Distributions" |
| 49 | + - 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) |
| 50 | + - requirements for building in CI |
| 51 | +- @ljharb |
| 52 | + - getting conflicting messages in the conversation on the RFC |
| 53 | + - _assuming_ that the process must be built on a trusted system for the provance to be considered a |
| 54 | + - things like pre-builds would also have to be trusted prior |
| 55 | + - what thought has been put into server-side behaivour approach (vs. putting this infront of the end-user) |
| 56 | +- @mylesborins |
| 57 | + - do not want vendor lock-in |
| 58 | + - want to work with third-parties |
| 59 | + - want to help solve the auditability of the build/source of the package |
| 60 | + - this does not prevent malicious software from being published |
| 61 | + - this work makes auditing streamlined/easy to do |
| 62 | + - what's important is the third-party |
| 63 | +- @ljharb |
| 64 | + - want to propose an altered order of prioritization |
| 65 | + - put something in sigstore about the package today |
| 66 | + - unresolve: how do you trust the claim is correct |
| 67 | + - then work on way to allow people to self-sign |
| 68 | + - then work on gradular backfill for top `X` impactful packages |
| 69 | + - goal here seems to be, find a way to reliably measure if the code in the tarball is accurate to the repo |
| 70 | + - why is "how" it was created important? |
| 71 | +- @mylesborins |
| 72 | + - most packages aren't 1:1 with their source counterpart |
| 73 | +- @steiza |
| 74 | + - seems like 3 goals: |
| 75 | + - 1. create public audit log as to how something was built |
| 76 | + - 2. linking a package back to it's source |
| 77 | + - 3. distributing package signatures to a third-party |
| 78 | + - do need to consider what happens when the link/sourcer is deleted |
| 79 | + - not sure who is responsible for validating this |
| 80 | +- @feelepxyz |
| 81 | + - have been thinking about how to create this signature outside of npm (ex. publishes machine) |
| 82 | + - seems to guarantee if npm is compromised |
| 83 | + - this work also outlines how identities are handled |
| 84 | + - this also lays the groundwork for any future |
| 85 | + - creates a vendor neutral space |
| 86 | + - want to also bubble up the idea of expanding the types of events we add into the ledger |
| 87 | + - OpenSSF is looking at standardizing the types of events |
| 88 | +- @steiza |
| 89 | + - 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 |
| 90 | + |
| 91 | +#### **PR**: [#23 Add Singleton Packages RFC.](https://github.com/npm/rfcs/pull/23) - @usergenic |
| 92 | +- Will keep this on our radar |
0 commit comments