Skip to content

Latest commit

 

History

History
92 lines (83 loc) · 4.16 KB

2022-08-17.md

File metadata and controls

92 lines (83 loc) · 4.16 KB

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
    2. Outline Intentions & Desired Outcomes
    3. Announcements
    4. Introduction(s)
  2. Issue: #622 [RRFC] include context that a module is overridden in npm ls - @bnb
  3. PR: #593 RFC: Only Registry Dependencies - @thescientist13
  4. PR: #626 RFC for linking packages to their source and build - @feelepxyz
  5. PR: #23 Add Singleton Packages RFC. - @usergenic

Notes

Issue: #622 [RRFC] include context that a module is overridden in npm ls - @bnb

  • @nlf
    • have now added this context

PR: #593 RFC: Only Registry Dependencies - @thescientist13

PR: #626 RFC for linking packages to their source and build - @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. #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
        1. linking a package back to it's source
        1. 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. - @usergenic

  • Will keep this on our radar