►
From YouTube: Open RFC Meeting - Wednesday, August 10th 2022
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live,
welcome
everyone
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
august.
The
10th
2022.
A
we'll
be
following
along
in
the
agenda
that
was
posted
on
issue
627
on
the
npm
rfc's
repo
and
for
folks
that
have
just
joined,
feel
free
to
add
yourselves
to
the
mini
note
stock,
which
I've
shared
here
in
chat
and
feel
free
to
add
notes.
I'll
do
my
best
to
take
notes
as
we
go
along
here,
quick
reminder
for
folks
on
this
call
and
newcomers
as
well.
A
This
call
is
live
streamed
and
recorded
on
youtube,
and
we
ask
that
folks,
please
abide
by
the
code
of
conduct
which
is
posted
in
the
rc's,
which
is
linked
in
the
rc's
repo,
the
synopsis.
There
is
please
be
kind,
as
other
folks
are
speaking.
Please
raise
your
hand
and
we'll
call
on
you
to
speak,
and
just
please
be
kind
and
thoughtful
as
we're
on
these
calls
discussing
these
rc's
quick
outline
again
of
intentions
desired
outcomes.
A
The
hope
here
with
this
call
is
to
obviously
discuss
in-flight
rc's
discussions
and
hopefully
come
to
some
rough
consensus
and
move
forward,
adding
new
capabilities
to
the
npm
cli
as
well.
I
want
to
give
some
space
for
folks
in
terms
of
any
announcements
that
we've
got
this
week.
A
A
If
not,
we
can
jump
into
quick
introductions.
Potentially,
I
know
there's
a
bunch
of
new
folks
on
the
call
it
might
be
good
to
just
quickly
go
over
who
you
are
where
you're
from
and
and
yeah
you're
essentially
interest.
Here
I
can
start
quickly.
My
name
is
darcy
clark,
I'm
the
mpm
engineering
manager,
our
npm
cli
engineering
manager,
as
well
as
kev,
a
cli
engineering
manager.
Here
at
gab,
I've
been
wearing
this
call
for
about
three
years.
That's
a
bit
about
me,
I'm
not
sure.
A
B
A
I
know
gar
is
in
the
middle
of
cutting
a
release
for
us,
but
I'm
not
sure
if
he's
there
guard
do
you
want
to
give
a
quick
intro.
B
I
am
the
hello
I'm
nelther
nell
for
nathan
lafreniere,
I'm
also
a
member
of
the
npm
cli
team
working
at
github.
I've
been
working
on
npm
itself
for
what
five
years
now
I
think
so
it's
been
a
while.
A
C
Yeah,
my
name
is
luke.
C
Team,
I
don't
have
a
cool,
nickname
and
I'm
working
on
the
doc
site
right
now,
so
that'll
be.
A
Cool
fun,
and
if
we
want
to
go
to
folks
from
github
philippa,
do
you
want
to
do
a
quick
intro.
B
B
Team
with
zach.
C
C
I
was
briefly
on
the
open
ssf
board.
While
I
was
at
coinbase,
so
I've
been
paying
close
attention
to
their
initiatives
and
trying
to
provide
a
sorely
lacking
npm
perspective
in
it,
and
I'm
I'm
very
interested
in
in
particular
for
today's
agenda
in
the
linking
rfc
and
how
how
we
can
achieve
that
effectively.
A
Well,
yeah,
jordan.
I
noted
in
the
chat
here
I
think
your
portfolio
of
maintained
projects
is
roughly
ten
percent
of
the
ecosystem.
I
could
be
wrong
if
that
that
number's,
accurate
or
not,
but
I
know
it
beats
two
percent.
A
Yikes,
okay,
so
we'll
we'll
have
to
wrap
you
in
bubble
bubble,
wrap
at
some
point
cool
owen.
Did
you
want
to
quickly
say
hi
and
do
a
quick
intro.
B
Oh
sure,
thanks
yeah,
my
name
is
owen
buckley,
primarily
a
front-end
developer.
I
mostly
work
in
technical
architect
roles.
My
companies
and
I
also
really
like
coding
on
my
free
time
and
so
there's
the
venn
diagram
of
my
interest
in
npm,
so
been
a
recent
attendee.
I
actually
met
darcia
node.js
interactive
two
or
three
years
ago.
He
was
giving
a
presentation
and
yeah
slowly,
but
surely
I
ended
up
here
so
yeah.
It's
been
fun
and
cool
thanks.
A
B
Yeah
that
the
web
components
community
group
as
well
so
yeah
and
sometimes
I
am
allowed
to
speak
on
stage
at
conferences.
So
that's
always
appreciated.
A
Nice
rick
did
you
want
to
give
a
quick,
intro,
say
hi.
B
Sure,
hey
guys
rick
an
engineer
here
at
godaddy,
just
being
a
good
partner
and
just
trying
to
you
know,
stay
in
support
with
npm
and
everything.
Npmcli
really
did
also
wit,
along
with
owen
and
jordan,
part
of
the
package
maintenance
working
group,
just
making
sure
we're
keeping
that
you
know
in
alignment
secure.
B
You
know
just
doing
the
best
for
our
environments,
recent
attendee
as
well
for
the
npm
rfc
stuff.
You
know
learned
it
through
darcy
and
on
the
package
working
group
and
and
just
want
to
stay
in
touch
with
things
and
just
make
sure
you
know,
I'm
also
keeping
the
line
for
our
our
company
and
for
npm
and
everything
that's
coming
up
so
appreciate
you
guys.
A
Cool-
and
I
think
we
have
a
few
other
folks-
I'm
not
sure
how
you
pronounce
it.
B
Oh
hi,
I
honestly
I'm
it's
my
first
time
here
I
just
joined
for.
I
was
curious.
I
don't
know
what
you
guys
are
doing
here,
I'm
interested
in
notes,
but
I
see
you're
such
a
cool
crew
with
all
the
experts
I'm
gonna
be
flying
on
the
wall.
Just
listening.
If
you
don't
mind
and.
A
That
is
totally
appropriate.
Thank
you.
So
much
for
joining
excited
to
have
you
eddie.
Did
you
want
to
quickly
do
an
intro.
B
A
Awesome
thanks
great
intros.
I
appreciate
that
we
don't
do
that
all
the
time,
but
it's
nice
to
give
everybody
some
reference
in
terms
of
where
we're
all
coming
from.
I
want
to
quickly
note
I
I
did
switch
the
order
here
just
quickly
for
the
agenda
just
so,
we
can
get
some
of
the
smaller
topics
out
of
the
way
and
then
we
can
jump
into
probably
the
larger
topic,
which
is
the
linking
packages
to
source
build,
which
is
the
rc
66.
A
But
if
folks
are
okay,
we'll
actually
start
with
the
pr
593-
and
this
is
just
owen-
your
only
registry
dependencies.
Pr
just
want
to
bubble
this
up,
I'm
not
sure.
If
there's
any
updates,
you
want
to
share
or
if
we're
just
essentially
you
know
in
a
holding
pattern
year
or
if
you've
had
time
to
look
at
npm
query
or
anything
like
that
or
if
there's
any
updates,
you
want
to
share.
B
A
A
I
think
it
was
eight
point.
Sixteen.
B
Moving
moving
along
here,
yeah
I'll
just
say,
8.x
but
yeah,
the
rfc
has
been
updated
to
basically
kind
of
swap
out
its
original
implementation
or
proposal
for
implementation
with
basically
just
hey.
You
could
also
just
delegate
to
this
npm
query,
so
that's
all
in
there.
Basically,
it's
the
tldr.
Is
it's
ready
for
review
and
or
merge?
You
know
all
the
feedbacks
caught
up.
Hopefully
all
the
bike
shedding
is
through.
Oh
I
and
I
the
only
question
I
had
is
so.
B
The
query
itself
uses
the
root
pseudo
selector
and
I
didn't
know
if
that
automatically
implies
workspaces
or
not
or
if
you'd
have
to
do
like
root,
workspaces
or
colon
workspaces
or
if
you
just
did
root
and
you
had
workspaces,
would
it
just
give
you
an
audit
of
your
entire
tree?
So
that's
the
only
last
day
I
could
think
of
finishing
this
up.
C
So
you
know
how
we
have
sember.mpmjs.com,
which
is
a
really
awesome
way
of
intuitively
figuring
out
how
sembra
ranges
work.
Is
there
any
way
we
could
have
some
sort
of
query.npmjs.com
where
you
type
in
a
package
name
and
a
query,
and
it
like?
Does
it
for
you.
B
Yeah,
that's
something
that
I'm
working
on
the
plans
currently
for
to.
C
Be
built
directly
into
the
docks,
like
some
demos,
some
examples,
but
the
docs
currently
need
a
little
bit
of
architecture,
love
to
get
those
capabilities,
so
I'm
working
on
that
hopefully
going
to
have
something
in
the
next
few
weeks.
But
yes,
I
can
reiterate
that
that
is
a
really
good
idea
and
something
that
I
want
to
have
that's
awesome,
yeah
the
whether
it's
embedded
in
the
docs
or
not,
is
sort
of
you
know
do
either
or
both
but
like
please
do
make
it
directly
linkable!
A
Yeah,
this
was
definitely
something
that
we
we
thought
would
be
helpful
for
folks
to
just
even
play
within
within
our
docs
with
query
and
and
right
there
in
line
be
able
to
test
out
some
some
of
the
syntax
so
that
they
don't
actually
have
to
like
update
or
install
like
the
latest
version
of
npm,
if
they
don't
want
to
so
I
I
posted
here
in
chat,
yeah,
try
before
you
buy
a
bit
of
that,
I
think,
would
be
helpful
for
for
folks
to
get
familiar
with
query.
A
We
had
even
played
around,
or
I
think,
luke
and
I
bounce
back
the
idea
of
potentially
being
able
to
upload
a
package
json
some
way
to
back
your
stack
if
you've
seen
that
kind
of
experience
where
you
can
upload
a
package
json
and
then
and
be
able
to
figure
out
which
packages
you
want
to
essentially
go
help
fund
it'd
be
nice.
If
we
could
do
that,
I
think
we
backed
out
of
that.
Because
of
you
know,
computational
type
things.
A
A
B
Rfc
for
registry
dependencies-
this
sounds
great.
Would
it
like
just
skimming
through
it
like?
I
would
kind
of
want
this
on
the
mtm
installed,
just
being
able
to
run
into
installs
and
say
just
block
anything,
that's
not
from
registry.
A
Yeah,
so
we've
been
having
the
discussion
in
the
last
few
weeks
on
this
with
owen
as
well
about
how
we
can
make
this
more
accessible
for
folks
to
write
their
own
kind
of
policies.
I
know
somebody
from
microsoft.
I
think
the
1js
or
one
es
organization
has
also
focused
on
on
the
idea
of
creating
policies
back
backed
by
npm,
query
and
internally.
A
Here
on
our
team
we've
been
discussing
how
we
could
potentially
help
you
create
essentially
like
install
gates
or
policies
that
you
could
write
a
query
for
and
it
could
become.
You
know
we
could
leverage
query
to
help
folks
write
this
in
in
a
way
that
doesn't
sort
of
arbitrarily
expand
the
scope
of
the
check.
A
So
it's
not
just
like
a
unbounded
execution
of
code
like
pre-install,
would
is
today,
but
it
would
be
something
that's
limited
to
sort
of
the
query,
syntax
that
we
could
essentially
help
run
checks
and
validation
for
obviously
that's
going
to
slow
down
your
install,
but
it
would,
you
know,
open
up
some
opportunities
for
folks
to
write
their
own
kinds
of
logic
into
install
sort
of
gates.
I
guess
you
could
call
them
in
soul,
gates,
go
ahead,
owen
and
jordan.
B
I
think
phillips
question
unless
I
misunderstood
your
answer,
but
the
this
flagging
this
this
check
is
going
to
be
part
of
npm
on
it,
which
my
understanding
is
run
during
npm
install
and
so
by
def.
No.
B
B
Maybe
that
warning
could
be
turned
into
an
error
by
default
or
not
or
there's
a
lot
of
opportunities
to
extend
it
through
query
to
like
cve
signatures,
like
all
sorts.
C
To
elaborate
on
that,
like,
I
think
the
vision
that
at
least
I
had
when
we
chatted
about
it
in
the
previous
calls
is
that
we
would
turn
npm
audit
into
a
like
umbrella
command.
That
runs
all
the
enabled
audit
types
and
vulnerabilities
is
the
current
one,
and
signatures
is
the
one
that
we've
been
working
on
and
there's
a
bunch
of
others.
We
can
conceive
of,
including
like
dependency
types
like
only
registry
depths,
and
so
for
not
for
breaking
change
reasons.
C
The
default
set
of
audit
types
that
was
run
in
npm
install
would
just
be
vulnerabilities,
or
you
know
for
now,
and
it
would
it's
set
to
warn,
I
think,
not
fail
and
then
you'd
be
able
to
opt
into
running
additional
audit
types
in
install
or
separately.
When
you
ran
npm
audit
like
so,
you
could
there's
two
different
places
it
could
run
and
in
each
place
you
could
just
determine
whether
it's
on
warn
or
fail,
which
means
that
you're
off,
so
you
can
choose
to
silence
anything
in
either
place
independently.
B
Yeah
and
I
think
the
unless
I
mistake
it
basically,
I
think
I
think
now,
if
this
rfc
and
its
current
form
stands-
and
I
think
it's
maybe
the
right
time
to
open
another
rfc
that
basically
describes
everything
that
you
said,
jordan
so
yeah,
I
think
yeah
as
long
as
you're
still
on
okay,
with
like
a
two-step
process
to
get
there
or
two
fc.
C
My
own,
my
own
way
of
working
if
someone
else
writes
that
I
am
more
much
more
likely
to
fill
it
in
with
paragraphs
than
I
am
to
actually
create
the
skeleton
so
feel
free
to
volunteer
for
that
anymore.
B
Sure,
I
guess
so
that's
a
good
point
that
maybe
to
to
wrap
up,
or
you
know,
darcy.
However,
you
want
to
wrap
it
up,
but
yeah.
If
folks,
like
everything
that
jordan
just
said,
then
see
if
you
like
this
in
its
current
form
and
then
it
can
be
a
fixed
point
for
a
second
rfc
to
you
know
depend
on
that
behavior
like
to
cover
everything
that
jordan
said.
So
you
can
do
the
two
steps.
I
don't
mind
seeding
that
if
everybody's
okay
with
this.
A
Yep
also,
I
just
shared
a
link
of
a
work
in
progress
rc.
That
would,
I
think,
be
the
the
follow-up
to
this.
So
jordan
feel
free
to
start
to
poke
at
that.
If
you
wanna,
I
think
it's
the
ball
rolling.
We
need
to
obviously
round
out
what
the
actual
api
was.
This
was
just
something
I
threw
together
shared
it
internally
with
our
team
but
yeah.
It's
essentially
audited
policies
trying
to
document
the
existing.
A
Just
like
jordan
mentioned
the
existing
vulnerabilities
warning
check
that
we
do
today
and
then
in
the
future,
providing
a
way
to
gate
installation
based
on
the
query,
then
that
would
be,
I
think,
the
the
future
and
this
kind
of
aligns
actually
with
the
even
the
signing
linking
rc
that
we're
going
to
talk
about
here
in
a
second.
If
we
can
get
that
metadata
into
essentially
the
queryable
like
create,
essentially
a
selector
that
we
can
query
that
metadata.
A
Then
we
can
essentially
create
a
query
that
would
gate
based
on
package
build
attestations
right,
so
you
could
essentially
create
a
new
check
that
would
gate.
So
this
is
our
idea
to
holistically,
create
policies
for
people
to
self-serve
or
to
have
some
defaults
already,
which
we
do
have.
They
just
aren't
sort
of
documented
in
this
kind
of
like
way
as
jordan
mentioned,
like
vulnerabilities
does
exist
and
it
does
have
a
setting
or
type
of
warning,
but
in
the
future
it
could
also
be
gating
right
so
getting
the
installation.
C
C
In
order
to
do
a
query
against
a
packages
dependency
tree,
I
was
looking
just
for
a
second
ago
at
like
what
packages
I
could
essentially
delete
all
the
code
and
replace
with
npm
query
calls
and
because
of
that
api
requirement,
I
I
don't
think
I
can
do
it
for
any
of
them,
so
I'm
just
throwing
that
out
there.
I
can
write
an
rfc
if
that's.
D
B
A
So
root
is
only
you're
only
going
to
want
to
use
root
when
you
directly
want
to
reference
like
the
relationship
that
the
dependencies
have
to
the
root.
So
if
you're
trying
to
match
direct
dependencies,
you'll
want
to
use
the
root
selector,
you
don't
need
to
use
it.
Otherwise,
if
you
want
to
find
any
and
all
depths,
then
you
can
just
remove
that,
so
you
don't
need
roots
specifically.
A
Otherwise
I
would
suggest,
if
you
don't
care
about
workspaces
and
you
don't-
which
I
don't
think
you
do
you
only
care
about
whether
or
not
the
dependency
is
a
git
depth.
You
can
just
write
colon
type
bracket
get
and
that
should
give
you
and
then
bracket,
and
that
should
give
you
all
the
get
defenses
within
the
project.
B
A
Okay,
great
and
yeah,
we
can
take
it
offline
as
well
cool.
I
want
to
quickly
move
on
to
the
next
issue.
Hopefully,
can
be
fast,
as
you
said,
jordan
tyranny's
not
here
to
speak
to
it,
but
it's
the
rfc
issue.
622.
C
Yeah,
I
I
think
I
can
represent
it
relatively
well,
so,
when
you're,
using,
if
you're
not
using
overrides
npm
ls
gives
you
your
tree
and
npm
explain
something
tells
you
why
a
thing
is
in
your
tree.
That's
very
useful.
If
you're
using
overrides
npmls
lies
to
you,
it
doesn't
tell
you
that
their
override
is
present
and
npm.
Explain
also
doesn't
tell
you
the
overwrite
is
present
and
the
rfc
was
about
mpmls.
C
I
asked
about
npm.
Explain,
it
seems
to
me
like
npm.
Explain
is
just
has
a
bug
like
it
should
just
tell
you.
This
thing
would
be
like
this
thing
is
in
the
graph
because
of
this
override,
that's
replacing
this
in
this
location
right
and
then
how
straightforward
it
would
be
to
add
that
to
npmls
I
don't
know,
but
the
rfc
is
like.
C
Can
we
do
that
so
yeah,
it
just
sort
of
seems
like
something
that
was
overlooked
in
the
overrides
rfc,
because
here's
what
I
found
I
mean
yeah
people
want
to
be
able
to
know
why
something
is
overwritten
or
like
where
it
came
from.
A
C
A
Yeah,
it
seems
like
it's
a
bug.
We
need
to
fix
that.
So
it's
it's
not.
I
don't
even
think
it's
up
for
debate.
It
needs
to
be
represented
over
ads,
need
to
be
represented
in
ls.
Output
also
need
to
be
representative
in
query,
so
we
need
to
be
able
to
say
whether
or
not
and
be
able
to
query
essentially
by
whether
or
not
the
depth
was
overwritten
as
well.
So
it's
a
good
thing
to
bring
to
our
attention
right.
C
And
even
when
querying
an
additional
wrinkle
is
you
may
want
to
query
what
the
against
what
would
have
been
there
without
the
override
versus
what
is
there,
because
of
the
override,
so
you're
you're
kind
of
having
multiple
trees
to
query
against
potentially,
but
that's
a
probably
harder
problem.
Yeah.
A
Cool
cool,
if
there's
nothing
else
from
folks
like
we'll,
we'll,
probably
take
this
one
offline,
async
and
then-
and
it's
just
something
we
need
to
resolve
in
those
commands
so
that
they
represent
overrides
properly.
A
Let's
quickly
move
on
then
and
try
to
give
this
next
rc
the
most
of
the
rest
of
the
time
I
think
other
than
I
think
the
reason
why
we
have
singleton
packages
on
here
still
as
an
agenda
item.
I
think
it
was
for
the
folks
from
microsoft
who
were
asking
about
this
before
we
can
probably
leave
time
if
we
want
to
at
the
end,
but
I
doubt
there's
much
new
discussion
there.
A
So
if
you
want
to
we'll
dive
into
rce
626
for
linking
packages
to
their
source,
build
philip
did
you
want
to
quickly
maybe
give
this
a
high
level
synopsis
of
what
the
rc
is,
and
I
know
there's
been
some
discussion
here.
B
Yes,
yeah
thanks
everyone
for
a
huge
amount
of
comments,
there's
almost
200
comments
on
there
yeah.
So
these
summary,
the
aim
is
to
link
public
npm
packages,
they're
hosted
on
the
registry
to
the
source
code
repository
and
build
that
it
originated
from
using
oidc
id
tokens
from
a
ci
cd
system
and
leveraging
sig
stool
infrastructure.
C
So
I
wanted
to
sort
of,
I
have
my
hand
raised,
so
I
can
sort
of
ask
more
foundational
questions.
I
think
the
reaction
that
I've
had
to
a
lot
of
the
open
ssf
stuff
and
to
a
lot
of
these
sort
of
broader
security
initiatives
is
that
they
all
sound
great
in
theory,
but
it's
not
clear
that
that
all
of
the
desired
links
or
attestations
or
verification
mechanisms
or
whatever
these
things,
and
I'm
not
just
talking
about
this
rfc
but
in
general
right.
C
It's
kind
of
just
sets
off
my
alarm
bells
about
security,
theater
and
so
like
when,
as
it
relates
to
this
rfc,
one
thing
that
just
popped
into
my
head
is:
what
about
all
the
packages
out
there
without
build
processes
which
is
most
of
the
old,
the
legacy
ones
a
lot
of
the
ones
that
are
done
most
of
my
own
in
theory,
you
can
already
verify
that
the
repo
that
they
claim
contains
the
exact
copy
under
that
git
tag
of
the
code
and
no
additional
information
is
necessary.
C
You
could
go
a
lot.
You
could
do
a
lot
by
just
building
up
a
database
of
that
without
anyone,
any
maintainer
action
or
user
action,
and
it
doesn't
seem
like
that's
been
done.
C
It's
like
like,
in
other
words,
I
think
that
the
that
back
maximally
backfilling
existing
packages
should
be
a
a
very
high
priority,
almost
more
so
than
how
do
you
annotate
new
packages,
even
though
I
can
understand
the
urge
to
like
stop
the
bleeding,
and
you
know
so
on
the
anything
that
doesn't
do
a
backfill
is
not
a
complete
solution,
especially
in
an
ecosystem
like
npm,
where
you
have
lots
of
finished
modules,
and
you
have
lots
of
modules
that
work
perfectly
and
have
zero
security
bugs
and
whose
maintainers
are
dead
or
retired,
or
have
one
of
them
has
even
given
up
like
they
transferred
all
of
their
packages
to
an
account
that
they
then
destroyed
the
credentials
to
do
so.
C
Nobody
can
ever
touch
them
again
so,
like
those
are
perfectly
secure
and
can
never
be
compromised,
and
yet,
like
all
of
these
new
types
of
processes,
don't
really
account
for
them.
So
I
kind
of
wanted
to
hear
a
little
more
about
like
what
are
the
actual,
concrete
attacks
that
have
happened,
that
this
will
prevent
not
just
the
theoretical
security
that
this
may
provide.
B
B
B
But
if
you
enforced,
if
you
actually
added
the
link
and
then
enforced
that
it
was
there
for
subsequent
publishers,
for
example,
and
maybe
gated
disabling
it
behind
2fa,
it
would
prevent
an
attacker
from
just
uploading
random
code
from
their
laptop
to
the
registry.
C
I
mean,
I
think,
that,
because
of
the
developer,
friction
that
different
credentials
adds
if
you,
since
I'm
you
know
so
I'll,
speak
for
myself,
I'm
using
two-factor
everywhere.
That
has
it.
I
am
using
a
password
manager
and
not
repeating
passwords
and
all
those
best
practices.
If
somebody
steals
my
npm
credentials
alone,
they
cannot
alter
my
github
repos,
and
so
you
know
they
they
could
do
what
you're
the
attack
you're
talking
about,
and
they
wouldn't
be
able
to
hide
it
in
the
repo
or
anything,
and
they
wouldn't
be
able
to
act
as
me
for
github.
C
So
I
can
see
that
being
that
it
helping
that,
but
because
I
have
two
factor
and
that's
now
mandatory
for
anything
that
you
know
for
a
list
of
packages
that
matter
and
that
will,
I
believe,
soon
be
growing
to
everything
in
order
for
them
to
compromise
my
credentials
and
have
it
matter,
they
would
also
have
to
compromise
my
two
factor,
which
means
they
either
have
my
physical
phone,
which
means
they
have
my
email
and
everything
or
it
means
they've,
compromised
my
email
and
thus
have
everything
so
like
and
this
and
if
they
have
my
email,
they
also
have
my
github.
C
C
And
then,
if
you,
you
build
a
service
that
independently
tries
to
replicate
the
build
process
of
a
published
package
and
uses
heuristics
to
figure
out
how
you
know,
because
it's
not
going
to
be
exact
but
like
how
close
you
get
to
the
actual
published
output,
then
that
would
probably
just
work
for
all
of
the
build
process
packages
and
eliminate
you
know
and
there'd
be
some
overlap
where
there
would
probably
be
some
valid
code
packages
that
were
marked
as
bad,
because
the
build
process
was
not
deterministic
enough
and
the
attack
code
was
subtle
enough
but,
like
I
think
the
vast
majority
of
attacks
would
be
caught
by
that
approach,
and
then
you
wouldn't
have
to
make
any
registry
changes.
C
B
D
Yeah
I
mean
these
are
great
questions
so
that
I
think
I
think
the
short
answer
is
there.
There
is
such
a
overlapping,
partially
overlapping,
set
of
circumstances
that
there
isn't
one
single
approach:
that's
going
to
work
in
all
cases.
So
if
you,
if
you
have
a
package
that
doesn't
have
a
build
system,
you
know
we
could
talk
about
in
parallel.
You
know
building
a
system
that
does
this
source
comparison
of
the
repo
to
the
package,
especially
for
legacy
packages
that
are
being
very
unlikely
to
receive
any
updates
in
the
future.
D
In
terms
of
reproducible
builds,
you
know
it's
sort
of
a
sort
of
an
open
question.
It's
definitely
not
gonna
work
in
all
cases
or
for
npm
packages,
and
then
this
this
is
playing
a
bit
of
a
of
a
long
game
in
terms
of
establishing
a
new
security
capability
that
could
be
adopted
by
the
ecosystem
over
time.
It
absolutely
is
not
a
one-size-fits-all
solution
to
all
of
our
security
problems,
and
this
is
why,
in
parallel,
there's
so
much
work
going
on
to
help
improve
the
availability
of
like
multi-factor.
D
You
know
like
the
recent
adding
of
like
web
authent
and
other
sort
of
account
security
mechanisms,
even
if
today
well,
I
think
there
probably
have
been
instances
where
a
developer
was
accessing
their
account
and
decided
to.
You
know
push
some
malicious
changes
to
the
package,
not
necessarily
to
the
repo,
but
even
even
today.
D
If
those
attackers
were
doing
it
primarily
by
pushing
to
the
repo
and
then
you
know
having
it
go,
live
as
we
build,
our
defenses
attack
attacks
become
more
sophisticated
and,
to
me,
it
isn't
much
of
a
leap
of
saying
that,
even
if
today,
the
malicious
code
is
mostly
being
pushed
to
the
repo
first
and
then
goes
to
the
package
that
in
the
future,
unless
we
do
something
people
could
you
know,
attack
the
or
they
could
push
the
militia
changes
directly
to
the
package
instead
of
pushing
it
to
the
repo.
D
C
So,
for
example,
one
of
my
concerns
with
npm's
website
adding
the
types
like
the
typescripts
logo
on
packages
when
they
had
types
was
that
it
should
also
include
things
that
have
definitely
type
packages,
because
if
it
didn't
that
would
be
heavily
penalizing
packages
that
do
not
ship
types
in
the
package
and
without
we
don't
need
to
get
into
all
the
details
of
what's
better
or
worse
there.
But
with
the
current
scenario,
a
maintainer
doesn't
have
to
change
anything
about
their
own
package.
To
get
that
logo
you
they
just
have
to.
C
Somebody
just
has
to
make
the
types
for
it
in
dt,
and
so,
while
I
still
don't
think
it's
perfect,
I
think
that
the
there
hasn't
been
been
too
many
negative
unintended
consequences
of
that
badge
being
present
as
a
result.
So,
similarly,
if
attestations
can
only
be
achieved
and
you
get
a
little
badge
on
your
profile
page
or
you
get
you
know,
if
you
don't
have
that
status,
then
you
get
peop.
You
get
noise
on
your
consumers
consoles
about
your
package
right.
C
C
However,
I
have
been
publishing
for
a
decade
from
my
local
machine
in
a
way
that
is
objectively
trusted
because
it
people
do
trust
it
it's
you
know
and
it
works,
and
it
has
not
gone
wrong
and
to
penalize
me
if
I,
if,
for
some
reason,
I
don't
want
to
publish
in
ci
yet
to
penalize
all
of
my
packages,
because
I've
done
that
that
doesn't
I
don't
think
that
makes
the
ecosystem
better.
C
I
think
that
that
puts
a
sour
taste
in
maintainers
mouths
about
security
and
actually
causes
more
harm
than
no
none
of
that
security
at
all,
which
is
one
of
my
complaints
about
the
cbe
ecosystem.
Is
that
the
false
positives,
I
think,
cause
more
damage
to
the
concept
of
security
than
a
lack
of
alerts
would,
and
so
like?
C
I
I
generally
speaking,
I'm
concerned
about
anything
that,
like
yeah,
I
think
I've
spoken
in
circles
so,
like
the
the
that's
sort
of
why
I'm
mentioning
these
things
in
parallel
and
talking
about
like
how
can
we
with
zero
additional
action?
Think
of
a
better
term
than
grandfather
legacy
like
promote
like
grant
for
free
all
of
the
existing
packages?
The
appropriate
statuses,
when
applicable,
so
that
those
who
want
to
can
opt
in
to
the
newer
approaches,
but
so
that
most
cases
don't
have
to.
D
Right
so
yeah,
these
are
great
points,
so
it's
certainly
an
anti-goal
of
this
project
would
be
like
put
a
lock,
icon
or
say
like
this
is
secure
because
it
does
this
thing
you
know
we're.
We
are
we're
trying
to
forge
one
link
in
that
chain
between
the
source,
repo
and
the
package,
but
you
know,
of
course,
there's
there's
limits
to
what
that
link
can
attest,
and
so
we
don't
want,
like
you
know,
I
don't
know
some
sort
of
like
thumbs
up
or
like
verified
secure.
You
know
type
language,
so
we
do.
D
We
want
to
be
very
careful
about
how
we're
how
we're
phrasing
this
in
the
both
in
the
cli
and
in
the
registry
web
interface
yeah.
I
think
I
don't
think
we've
given
a
lot
of
thought
to
what
this
would
look
like
for
legacy
projects
and
the
like
scoping
out
the
amount
of
work
to
try
to
create
this
relationship
for
packages
without
without
any
changes.
So
that's
that's,
certainly
something
I
think
we
might
have
to
spend
more
time
looking
into
to
have
a
better
answer.
A
I
apologize
there,
jordan.
I
missed
the
beginning
of
your
your
statements
there,
as
I
was
dealing
with
some
audio
issues.
So
just
if
you
can
make
sure
notes
are
accurate
and
feel
free
to
try
to
yeah
apologies.
A
Did
anybody
else
have
time
to
to
look
this
over?
I
know
it's
a
pretty
dense
rc
as
well
or
if
anybody
else
had
any
comments
or
feedback
on
this.
I
know
it's
something
that
we'll
likely
keep
on
the
agenda
for
for
the
next
few
weeks
here
for
sure
want
to
make
sure
that
there's
enough
time
for
for
people
to
give
feedback
and
also
ask
questions,
I
know.
A
I
think,
like
your
questions
on
incentives,
jordan,
are
are
good
and
then
also
in
terms
of
the
attack.
You
know
preventer
prevention
like
what
what
whether
the
attack
vectors
that
are
being
prevented
by
by
these
capabilities.
It's
the
right
things
to
push
on
here,
yeah,
the
the
sort
of
use
cases
that
I
I
end
up,
finding
myself
falling
into
for
for
why
this
is
beneficial
is
mostly
like
auditing
gating,
based
on
build
attestations
or
the
lack
thereof
is
like,
I
think,
a
long
way
out
so
like.
A
A
That's
being
presented
is
to
add
support
into
the
sub
command,
the
npm
audit
signature
sub
command,
so
that
you
know
it's
sort
of
testing
the
the
waters
there
and
then
we
can
again
with
the
idea
of
like
more
holistic
audit
policies
or
gates,
or
things
like
that.
We
could
eventually
like
graduate
that
into
something
that
was
like
a
default
gate,
or
you
know
thing
that
we're
checking
for.
C
So
something
I
want
to
add
is
the
the
recent
addition
to
the
npm
website
to
like
actually
link
my
github
and
twitter
account.
There's
a
lot
more
that
I
think,
could
be
done
there
to
build
a
foundation
to
build
the
next
link
in
the
chain
to
be
able
to
link
a
project
to
an
organization
account,
instead
of
just
a
user
accounts
to
be
able
to
indicate
which
maintainers
of
a
package
have
linked
their
github
to
be
able
to
indicate
which
which
person
published,
which
version
and
did
they
link
had
they
linked
their
github.
C
At
that
time
you
know,
or
was
it
published
with
two-factor?
I
don't
know,
maybe
that
one's
trickier,
but
like
all
of
these
these
pieces,
because
at
a
certain
point,
when
you
have
all
of
that
information,
it
becomes
really
easy
to
see
a
like.
It
becomes
a
lot
easier
to
see
when
somebody
who
shouldn't
be
there
is
there
before
you've,
even
gotten
into
attestations
and
verifying
them,
and
so
that,
like
again
like
another
thing
that
could
be
done
in
parallel
and
possibly
should
be,
that
you
know,
is
sort
of
increasing
that
stuff.
C
You
could
also
one
more
thing:
you
could
also
verify
that
the
npm
publisher
has
write
access
or
higher
on
the
repo,
which
won't
always
necessarily
be
the
case,
but
is
probably
almost
always
the
case
and
yeah
that's
something.
Github
can
do
with
it
publicly
with
its
apis,
let
alone
internally.
A
Yeah
again,
like
things
that
are
often
fishy,
like
a
new
tracking
down
when
a
new
user
is
being
added
to
maintain
or
be
given,
access
to
to
publish
to
a
package
is
definitely
something
that
should
be
like
a
heuristic
that
we
we
should
be
mindful
of
whenever
that
changes,
and
then
somebody
quickly
publishes
is
sort
of
like
a
bit
of
a
policy
or
like
it's
a
smell
right.
It's
a
code
smell
essentially,
and
I
think
what
this
is.
A
What
we're
presenting
here
is
is
the
idea
of
being
able
to
add
more
information
into
sort
of
a
public
record
or
ledger
about
when
those
actions
are
being
taken
allows
for
some
transparency
for
folks
to
monitor
when
that's
happening,
and
this
is
essentially
where
all
this
work
stems
from-
is
the
idea
of
a
like
a
transparency
logs
and
and
having
monitors
as
well,
so
that
you
can
quickly
react
to
that
again.
A
Like
you're
you're
asking,
I
think
some
good
questions
about
what
other
work
are
we
doing
to
in
this
space
that
that
is
maybe
adjacent
to
this,
which
might
be
beneficial
to
to
maybe
prioritize
even,
but
I
I
think
it's
valid
to
say
that
there's
work
we
could
do
that
that
shores,
things
up
from
a
standpoint
of
like
monitoring
these
actions
like
like
when
somebody
gets
added
to
like
an
npm
package
like
what
kind
of
signal
do
I
have
today
and
do
I
just
have
to
be
essentially
like
pulling
even
this
ledger
in
the
future?
A
C
I
mean,
I
would
say
from
a
technical
level,
every
time
I
meaning
any
npm
user
who
has
connected
github
logs
in
or
publishes
you
should
be
able
to
use
to
at
that
time,
make
a
ping
to
the
api
and
see.
Do
I
have
right
out
like
which
repos
do
I
have
right
access
to,
or
do
I
have
right
access
to
this
repo
or
whatever,
and
when
somebody
is
added
as
an
npm
owner
ping.
C
The
api
right
then
make
sure
that
they
have
access
to
the
repo
that
the
package
is
linked
to
right,
and
you
know
that
could
be
done
in
a
that.
There's
it's
tricky
to
do
this
in
a
way
that
doesn't
privilege
github,
but
github
is
sort
of
unavoidably
privileged
already
and
I'm
sure
that
there
are-
and
it
could,
I
think,
very
in
a
straightforward
manner-
be
extended
to
to
authenticate
with
gitlab
and
with
you
know,
wherever
else
anything
that
provides
these
abilities.
C
You
just
say:
well,
yeah,
you
can
link
your
gitlab
account
and
then
you
can
use
the
gitlab
api
right
and
I'm
sure,
there's
probably
some
biz
dev
problems
there
to
work
out
to
like,
but
I
mean,
technically
speaking,
it
should
be
straightforward.
I
don't
know
just
I.
I
think
that
there's
like
like
the
two-factor
requirement,
is
such
a
minor
inconvenience
that
it's
reasonable,
albeit
sometimes
annoying
to
force
maintainers
to
do
it
right,
but
because
it's
not
revealed
who
has
two
factory
who
doesn't
even
before
it
became
mandatory.
C
It
wasn't
really
that
it
didn't
really
matter
because,
like
if
you
didn't
want
to
use
it,
you
didn't
use
it
and
if
you
should
show
like,
but
you
weren't
like
forced
into
using
it,
so
it
was
just
like
okay.
I
have
to
open
this
app
on
my
phone
and
take
three
extra
seconds
when
I'm
doing
a
special
action
right
and
I
would
think
similarly,
okay,
fine,
I
have
to
connect
my
github
and
then
okay
before
I
add
someone
as
an
npm
owner,
I
have
to
go.
C
Add
them
to
the
repo,
like
all
that
stuff
seems
relatively
low
cost,
to
ask
a
maintainer
to
do
it's
low
friction
and
it
doesn't
change
anything
fundamental
about
most
of
the
workflows.
It's
just
a
few
extra
bits
of
information
to
check,
and
I
suspect
that
in
practice
that
would
actually
catch
most
of
the
problematic
scenarios
that
have
actually
happened.
C
You
know,
or
at
least
highlight
what
like
it
would
make
it
really
a
lot
easier
to
figure
out
what
had
happened
after
the
fact,
because
you
can
see
oh
well.
This
person,
like
this
publisher,
like
was
added
to
github.
Let's
go
look,
oh,
they
were
just
added
recently.
Maybe
that,
like
the
maintainer
was
tricked
or
something
you
know
like
like
it
becomes
a
lot
easier.
C
I
think
to
piece
that
together,
when
you
have
that
sort
of
a
more
public
audit
log,
like
the
fact
that
it's
obscure
knowledge,
that
you
can
type
npm
like
info
package,
name
time
and
figure
out
date
and
time
and
publisher
of
each
package,
like
it's
not
easy
to
find
that
out
that
information
out
otherwise
and
like
being
able
to
also
find
out.
If
did
they
have
get
right
access
on
the
github
repo,
the
time
it
was
published
that
adds
a
lot
of
you
know,
ability
to
recover.
A
Yeah,
so
we
have
the
five
minutes
left.
I
just
want
to
be
mindful
of
that,
but
what
I
will
say
is
you
know,
I
think,
there's
a
lot
here.
Obviously
200
comments.
We
don't
have
quite
everybody
on
on
this
call.
I
think
that
was
given
feedback
time
zones
can
be
a
hard
thing
to
manage
here,
so
just
want
to
make
sure
that
everybody
feels
free
to
continue
to
give
the
the
feedback
that
you're
giving
even
here
during,
like
back
in
async
manner,
to
the
rfc
itself.
A
So
we
can
improve
it
and
make
sure
everybody's.
You
know,
thoughts
and
feedback
are
being
added
there.
I
guess
what
you're
speaking
to
jordan
as
well
in
terms
of
that
like
transparent
audit
log?
Is
there
any
concern,
and-
and
for
me
this
is
my
biggest
concern
with
this.
This
work
with
having
a
third,
a
new
introducing
a
new
third
party
or
source
of
truth,
and
essentially
keeping
this
information
housed
in
a
net
new
host.
A
Is
that
of
any
concern
to
folks
the
fact
that
that
audit
log
in
the
future
is
essentially
being
proposed
as
the
home
of
where
we
will
be
adding
this
type
of
those
types
of
logs
and
if
folks
have
followed
this
rc
to
any
extent,
you
will
find
like
the
infrastructure?
That's
behind
this
six
store
and
underneath
that
the
trillion
server
is
there
any
concerns
there?
I've
seen
performance
issues
open
for
the
last
few
years.
A
Actually,
some
folks
having
some
problems
with
that,
like
my
biggest
concern,
is,
is
more
the
vendor
that
is
going
to
be
responsible
for
maintaining
the
infrastructure
than
it
is
actually
and
and
also
where
they
will
be
able
to
operate
so
from
sort
of
an
organ
and
consumer
concern
like
if
I'm
a
business.
Do
I
do.
I
trust
this
new
party.
A
That's
that's
going
to
have
to
operate
and
what's
their
slos
type
thing
so
that
for
me
that
might
get
resolved
easily
through
you
know
the
open,
ssf
or
sixth
order,
essentially
presenting
sort
of
united
information
about
how
this
is
going
to
be
operated,
but
because
it's
net
new
there's
a
lot
of
questions
I
have
about.
You
know
the
long-term
viability
of
this
net
new
source
of
truth
to
be
housing.
This
information.
A
So,
just
to
play
my
show
my
own
cards
here,
like
that,
that's
my
biggest
concern.
The
actual
concept,
I
I
think
is
is
good
one
though,
and
I
think
it
does
add
something
that
again
isn't
it's
not
going
to
be
all-consuming.
I
think
zach
said
right,
like
this.
Isn't
a
silver
bullet
there's
going
to
be
a
number
of
different
things
that
we're
going
to
introduce
here
and
hopefully
the
community
is
seeing
that
we're
continuing
to
invest
in
essentially
supply
chain
security,
so.
A
A
Any
other
feedback
before
we
sort
of
wrap
here,
at
least
for
for
today's
call.
A
I
know
I
want
to
give
a
huge
shout
out
to
philip
and
and
his
team
here,
brian
as
well,
I
know,
has
done
a
bunch
of
work
on
the
six-floor
js
implementation,
which
got,
I
think,
transferred
to
the
the
sixth
order.
Org,
so
we'll
just
want
to
say
huge
congrats
to
all
the
work
that
they're
doing
and
and
appreciate
them
pushing
on
this,
especially
philip.
I
know
this
has
taken
a
long
time
to
put
together
and
you've
had
a
number
of
conversations
internally.
So
now
it's
it's
fun.
A
You
get
to
to
chat
about
this
externally.
I
know
so
I
think
github's
having
a
little
hard
time,
even
rendering
the
rfc,
at
least
because
of
the
the
comments.
So
ideally
that's
a
good
metric
to
track
of
popularity
of
this
so
cool.
What
I
think
we'll
do
is
it
will
keep
this
on
the
agenda
and
then
hopefully
this
becomes
a
good
grounds
for
for
discussion
async
in
the
rcu
repo
itself.
A
A
Discussions
might
be
a
better
better
avenue,
but
just
want
to
thank
everybody
for
jumping
on
today.
If
you
didn't
get
a
chance
to
bubble
up
any
concerns
or
thoughts
feel
free
to
do
that.
Async
and
then,
hopefully,
we'll
see
you
next
week
at
the
same
time
same
place.
What
also
is
sort
of
an
opportunity
here
is
based
on
the
traction
that
is
on
src.
A
You
may
want
to
do
a
separate.
You
know
dedicated
deep
dive,
call,
which
I
know
we've
done
in
the
past
historically
on
this,
which
might
also
allow
for
certain
folks
to
join
that
are
in
different
time
zones.
I
know
that
wednesday
is
at
2
p.m,
where
not
ideal
for
2
pm
eastern
are
not
ideal
for
everybody,
so
I
may
open
an
issue
just
asking
for
input
and
maybe
do
a
bit
of
a
pull
to
see
if
there's
another
time.