►
From YouTube: Open RFC Meeting - Wednesday, August 4th 2021
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
are
live
on
youtube.
Welcome
everyone
to
another
mpm,
open
rfc
call.
Today's
date
is
wednesday
august
4th
2021
we're
going
to
be
following
along
the
agenda
that
was
posted
in
issue
number
426.
A
This
conversation
is
going
to
be
more
like
a
deep
dive
on
specifically
the
npm
audit
assertions,
rc
and
just
audit
improvements
in
general.
As
we
outlined
last
week,
we
wanted
to
go
in
and
probably
spend
a
whole
hour
on
this
space,
and
so
I've
queued
up
essentially
a
number
of
resources
there
in
the
rfc
agenda
itself
and
if
folks
have
been
following
along
in
the
422
rc
audit
assertions.
A
They'll
know
that
there's
been
a
lot
of
discussion
since
last
time
we
talked
last
week
when
tierney
opened
this
just
before
we
jump
into
that
and
and
the
topic
of
audit
improvements.
I
just
wanted
to
again
outline
that
this
call
and
all
calls
and
comms
are
governed
under
a
code
of
conduct
that
we
ask
people
to
please
be
mindful
and
respectful
of
each
other.
A
B
I'm
not
sure
if
that's
an
announcement,
but
I've
added
a
comment
and
I
can
post
it
also.
So
in
the
chat
I
managed
to
publish
in
the
the
format
that
I
derived
from
audit
resolver
and
added
some
modifications
to
make
it
not
just
for
storing,
but
also
for
exchange
of
of
the
reports,
assertions
decisions
whatever
we
want
to
call
them
and
the
rfc
documents
in
there
also
lists
all
of
the
use
cases
that
I
intended
to
cover,
and
the
list
is
quite
long.
A
Awesome
yeah,
I
did
add,
I
saw
you
added
that
zb
and
I
I
added
to
the
references
and
resources
here
put
it
beside
your
audit
resolver.
Pr
that
I
know
has
been
opened.
Rfc
has
been
open
for
a
long
time
number
18.,
so
hopefully
that's
captured
there
now
as
well.
I
appreciate
the
reference
there
so
want
to
quickly.
Maybe
let
tierney
go
over
the
initial
rfc
and
sort
of
the
outline
and
sort
of
reason
why
you
made
this.
A
We
didn't
have
a
lot
of
time
last
week,
so
maybe
you
can
just
give
a
quick
synopsis
of
what
it
is
you're
looking
to
try
to
introduce
and
and
sort
of
the
approach
you
took
with
the
spec
like,
however,
you
spec
it
out
so.
C
Largely
so
the
the
basic
the
basics
are,
this
is
a
effectively
a
counterclaim
mechanism
intended
to
allow
maintainers
and
that
that
part,
I
think,
is
a
part
I
want
to
focus
on
and
have
a
discussion
here
about
is,
is
maintainers
their
group,
but
largely
to
allow
maintainers
to
assert
that
their
modules
aren't
impacted
by
advisories.
C
Advisories
is
the
npm
name
of
you
know
what
audit
uses
it's
the
npm
advisory
site
intentionally
built
it.
So
it's
not
necessarily
attached
to
that,
but
I
do
want
to
use
that
nomenclature
here.
Basically,
this
is
a
cli.
C
You
know
extension
of
the
cli
that
maintainers
can
use
to
say,
hey
this
advisory,
that
went
out
for,
let's
say
low
dash,
because
that's
what
everyone
likes
to
pick
on
sorry,
jdd.
You
know
this
this.
This
slo-dash
vulnerability
is
not
applicable
to
us.
It
is
presently
a
boolean,
so
it
is
impactful,
true
or
false.
C
That
is
a
point
that
people
you
know
had
issue
with,
which
I
think
is
fair,
but
yeah
basically
say
this:
module
isn't
or
is
impacted
by
this
id
this
advisory
identifier
and
with
a
comment
which
was
a
very
handy
piece
of
feedback
from
the
github
security
team,
which
I
appreciate
basically
saying
why
the
maintainer
does
or
doesn't
think
that
assert
the
that
vulnerability
is
applicable.
C
That's
basically
it
from
the
mechanism
side.
Ideally,
this
would
also
get
surfaced
through
audit,
so
audit
would,
by
default,
ignore
modules
with
impactful
false
assertions,
and
by
ignore
I
mean
not
surface
when
you
type
npm
install
and
you
get
a
list
of
here-
is
the
low
medium
high
and
critical.
I
think
I
could
be
off
in
that
name,
but
basically
drop
it
from
that
list.
C
C
The
one
that
you
know
I
spoke
with
dan
about
was
create,
react
app
and
how,
when
someone
starts
using,
create
react,
app,
there's
a
bunch
of
vulnerabilities
and
that
someone
just
starting
to
use
pre-react
app,
probably
isn't
going
to
be
super
familiar
with
javascript,
isn't
already
going
to
be
desensitized
to
audit,
and
so
they
get
scared
by
that,
which
is
a
very
valid
thing,
and
you
know
the
great
reactive
team
point
has
assessed
those
vulnerabilities
and
figured
out
that
they're
not
actually
impacting
them
so
effectively.
C
They
are
unvulnerable,
and
this
is
a
way
to
kind
of
help
surface
that
knowledge
from
the
maintainers
to
users
without
having
to
kind
of
communicate
that
one-to-one.
It's
a
way
to
do
it
at
scale
yeah.
So
that's
that's
kind
of
that
side
of
it,
of
course,
being
very
upfront
that
there
is
a
way
to
always
get
all
of
the
information
available
and
yeah.
That's
that's!
Basically
the
proposal
here
I
see
wes
and
zb
have
their
hands
up.
I
think
west
was
first.
D
Yeah,
absolutely
so
just
to
add
on
to
the
sort
of
problem
statement
that
tyranny
laid
out,
which
I
think
is
spot
on.
If
you,
if
anybody
wants
to
check
out
the
video
that
darcy
and
I
put
together
for
the
opengs
conf,
we
did
a
series
of
interviews
with
people,
including.
D
And
one
of
them
was
the
maintainer
of
node
red,
which
has
similar
user
base
like
create
wrecked
app
and
they
and
nick
was
the
is
the
maintainer.
We
interviewed
had
a
very
similar
bit
of
feedback
about
their
new
users
and
the
the
fear,
and
then
they
had
a
very
specific
case
where
they
wanted
to
make
a
counter
claim,
and
in
this
case
they-
and
I
don't
know
if
we
want
to
go
into
too
many
details.
But
basically
there
was
some
caveats
around
the
counter
claim.
D
It
was
like
okay,
well
we'd
like
to
get
this
updated,
but
we
can't-
and
this
is
why-
and
users
unless
you
were
in
this
very
specific
case-
which
no
one
really
was,
because
that's
just
their
user
base-
and
it
was,
you
know,
pretty
pretty
straightforward
to
not
introduce
the
the
security
vulnerability.
D
It
just
didn't
apply
right
and
so
there's
a
lot
of
precedence.
I
think
outside
of
just
those
two
examples
that
you
know
might
also
have.
To
be
honest.
That
was
one
of
the
things
I
think
maybe
in
this
rfc
looking
at
the
discussion
and
some
of
the
directions
it
took,
I
feel
like,
unfortunately,
some
of
the
folks
who
are
a
little
less
familiar
with
the
discussions
that
have
happened
in
this
group.
D
The
package
maintenance
group
and
a
few
of
the
others
maybe
are
getting
frustrated
with
our
responses,
but
it's
not
because
we're
not
responding
well
or
I
don't
want
to
say
correctly,
because
obviously
it's
there's
certain
opinions
involved
here.
D
But
I
think
that
there's
a
lot
of
missing
context
for
those
folks-
and
I
think
the
rfc
as
it
stands-
might
benefit
from
laying
out
a
bit
more
of
the
like
prior
art
and
foundation
that
this
discussion
has
just
not
just
stan's
post,
and
I
think
you
know
just
to
bring
those
folks
up
to
speed
a
little
bit
better,
because
I,
I
feel
really
bad
the
way
that
the
one
person
has
seemed
to
feel.
D
I
and
I
don't
know
their
their
name
offhand,
because
I
understand
where
they're
coming
from
it's
just
we've
hashed
out
a
lot
of
these
conversations
in
prior
pieces,
and
so
it
feels
like
we
need
to
maybe
at
least
have
some
like
go
here.
First,
read
all
of
these
things
watch
some
of
these.
You
know
you
know
prior
discussions.
D
The
video,
maybe
like
some
of
this
other
stuff-
that's
absolutely
applicable
here,
even
if
it
doesn't
end
up
all
directly
being
a
part
of
this
rfc
people
just
take
this
rfc
and
sort
of
run
with
the
entire
security
supply
chain,
security
story
and
the
fact
that
we
don't
have
like
a
call
out
at
the
beginning
that
says
hey.
This
is
not
meant
to
tackle
all
these
other
things.
D
A
Good,
that's
that's
good
feedback
wes
like
in
terms
of
like
scoping.
This
conversation
is
the
key.
I
know
in
other
deep
dives
as
well.
A
That's
one
of
the
the
things
that
we
want
to
narrow
in
on
and
might
be
good
just
so
that
we
stay
on
on
topic
here,
as
well
as
like
defining
the
scope
of
just
what
this
rfc
is
specifically
what
the
topic
is
and
conversation
we
want
to
have,
but
it's
also
good
to
like
document
that
so
that
might
be
a
good
takeaway
to
your
knee
for
us
to
add
tb.
Did
you
want
to
comment.
B
Yeah,
so
I
I
wanted
to
get
into
a
bit
of
a
nitty-gritty,
maybe
for
for
some,
but
I
think
it's
important
to
add
this
on.
So
this
is
going
to
be
mostly
referring
to
my
comment
in
the
pull
request
with
the
rfc.
B
That
starts
with
bold,
deep
dive
statements,
so
it's
a
wall
of
text,
so
maybe
not
all
of
you
are
familiar,
but
to
summarize
it
shortly,
the
idea
is
the
current
way.
This
rfc
defines
a
counter
claim
is
not
sufficient
for
claiming
against
your
own
dependency.
B
So
if
you're
a
package
maintainer,
your
package
is
called
lodash
since
we're
talking
about
it
already,
and
you
want
to
claim
that
one
of
your
dependencies,
that's
marked
as
vulnerable,
is
not
used
in
your
package
in
a
way
that
makes
you
vulnerable,
it's
not
enough
to
give
the
advisory
id
the
module
would
be
depending
on
the
interpretation.
I
think
the
rfc
is
not
a
hundred
percent.
This
one
option
here,
but
I'm
assuming
the
module
value
would
be
the
name
of
the
package
in
your
dependencies.
B
But
then
this
is
not
complete
information
allowing
you
to
ignore
this
or
counter
claim
this,
because
it's
it
doesn't
pinpoint
the
specific
package-
and
this
is
something
that
I
aimed
to
solve
in
in
my
previous
work
with
audit
resolver
and
what
I'm
doing
there
and
I'm
gonna
recommend
it
to
everyone
is
to
point
to
a
path
in
your
dependencies.
Otherwise,
you're
opening
yourself
to
a
situation
where
you
evaluate
that
a
certain
vulnerability
is
not
affecting
you
in
your
direct
dependency
and
then
another
of
your
dependencies
takes
the
same.
B
Vulnerable
dependency
takes
it
on.
It
appears
as
a
new
dependency
in
your
tree
with
another
version,
update
and
you're
already
set
up
to
ignore
that
vulnerability.
Even
though
there
is
a
new
supply
chain
leading-
and
I
mean
dependency
path,
leading
to
this
vulnerability
that
might
actually
be
active
this
time.
So
what
I'm
suggesting
is
well,
I'm
going
to
be
direct
about
it.
I'm
suggesting
adopting
the
format
that
I
documented
for
pointing
at
a
dependency
and
storing
the
decision
about
it.
The
format
includes
the
advisory
id
and
path
in
dependencies.
B
It
also
lets
you
declare
that
you
intend
to
represent
a
specific
package
whose
recommendations
these
are,
so
this
format
can
be
used
to
exchange
the
information
as
well-
and
I
I
know
I'm
pushing
for
for
my
work,
but
this
is
one
of
the
possible
implementations
that
I
intend
to
open
for
discussion
and
improvement
within
the
group
out
there
in
open.js
foundation.
C
So
I
would
like
to
actually
raise
something
that
got
brought
up
to
me
in
a
different
venue.
I
would
actually
prefer
that
this
or
any
mechanism
of
this
be
based
on
something
that
is
being
built
by
other
experts
that
is
portable.
C
It
seems,
like
you
know,
through
the
discussion
of
this
vex,
the
oasis
csaf
stuff.
I
don't
know
what
the
correct
name
is,
but
I'll
call
it
vex,
because
that's
what
it
seems
to
be
referred
to
in
their
heading.
Let
me
post
the
link
here.
It's
linked
in
the
the
rfc
meeting
minutes
and
the
issue
I,
but
I
posted
it
in
the
chat
as
well.
C
This
format
seems
to
be
a
not
standardized
but
openly
developed
format
that
I
I
you
know
if,
if
this
is
something
we're
going
to
go
down
like
if
we're
going
to
go
down
the
route
of
like
defining
a
spec
for
this,
I
would
prefer
that
we
base
it
on
the
work
of
others
who
are
trying
to
do
this
in
a
more
wide
scale
thing
and
who
are
frankly
more
experts
on
this
than
we
are
like.
C
I
am
not
an
expert
in
this
to
the
degree
that
these
people
are
by
any
means,
but
whether
it's
you
know
oasis
or
open
ssf,
there's
work
being
done
here
and
I
would
prefer
that
we
begin
to
build
on
the
work
of
the
security
ecosystem.
C
Rather
than
our
own
kind
of
special
formats,
this
spoke
that's
a.
A
Very
good
word
bespoke
thank
you
using.
I
took
out
my
thesaurus
for
that
one
wes.
You
still
have
your
hand
up.
Would
you
like
to
comment?
I
guess.
D
Oh
yeah,
that
was
a
re-raise
just
to
chat
about
a
couple
of
the
things.
So
so
yes,
I
agree
tierney
we
should
definitely
be
leveraging
the
community
other
community
resources.
D
I
did
pass
along
some
of
the
links
that
came
up
in
this
to
some
of
the
security
folks
at
netflix
and
they
were
not
aware
of
this
work.
So
I
want
to
be
careful
that
we
don't
just
pick
a
prior
art
for
the
sake
of
the
fact
that
somebody
else
did
it.
We
should
we
should
be
really
pretty
careful
about
vetting.
So
I
read
some
of
the
the
links
posted
and
this
is
what
I
was
trying
to
get
at
from
the
person
who
posted
it.
D
I
think
that
there's
first
one
of
the
documents
just
seems
like
incomplete
and
then
the
and
I'm
on
my
phone.
So
I
can't
click
the
link.
You
posted
to
be
sure.
If
that's
the
same
one,
I
remember
looking
at
the
other
one
didn't
raise
any
like
the
folks
that
I
talked
to
now.
This
is
not
a
representative
sample,
so
you
know
I
I'd
love
to
hear
from
more
folks
in
the
community,
but
they
had
my
contacts
that
netflix
had
not
heard
of
that
effort.
There's
also
the
google
one.
C
D
They
cover
some
of
these
things
as
well,
so
I
I
would
really
love
to
have
like
maybe
a
a
good
comparison
of
what
different
features.
These
support,
because
I
didn't
see
a
mention
of
some
of
the
stuff
in
the
the
links
that
were
posted
in
this
thread
of
the
same
kind
of
things.
That
zb
is
mentioning
so
like.
D
Maybe
it's
just
a
matter
of
us
working
with
those
groups
to
get
a
you
know
these
features
or
whatever
key
pieces
of
data
like
the
the
you
know,
transitive
dependency
path,
you
know
whatever
it
is
into
one
of
those
would
be
great,
but
I
also
want
to
say
I
don't
think
there's
anything
wrong
with
us
treading
new
ground
as
long
as
we
vet
that
we're
not
like
reinventing
the
wheel
for
no
reason
I
I
do
think
you
know-
and
this
is
one
of
the
things
darcy
and
I
talked
about
in
the
in
the
presentation.
D
D
Authors
of
go
but
like
they
just
have
a
very
different
set
of
problems
than
we
have
and
I
was
looking
at
their
work
and
it's
like
well,
okay,
yeah,
it
could
work,
but
we
need
to
extend
it
in
a
bunch
of
ways
in
the
like.
They
can't
leave
room
for
the
extension,
but
it
doesn't
necessarily
like
codify
it
and
so
like
either
way
we're
going
to
have
to
come
up
with
some
language
specific
things
to
help
us
express
what
we
need
to
express.
D
So
I
just
want
to
make
sure
we
balance
that
conversation
like.
I
think
we
should
be
reaching
out
to
those
folks,
maybe
inviting
them
to
have
a
conversation
with
us
and
say
like
hey.
Can
you
share
how
this
works,
so
we
can
figure
out
how
it
would
apply
to
npm.
How
would
apply
to
you
know
javascript
projects
unless
they
have
better
white
papers,
because
the
white
papers
that
were
linked
are
like,
I
don't
know.
A
Very
descriptive,
so
just
so,
I
capture
what
you're
saying
correctly.
You
agree
with
us
pulling
in
the
subject
matter,
experts
and
also
poking
on
the
organizations
that
have
already
tread
some
of
these
past
already.
What
might
be
good
is
it
sounds
like
you're
referencing
wes,
like
let's
at
those
people
potentially
or
bring
them
into
this
conversation,
is
that
right?
Is
that
a
good
summary
yeah.
D
Yeah
definitely-
and
I
think
we
should
also
have
a
specific
ask
them
to
help
us
understand
how
their
proposals
would
fit
into
our
ecosystem,
because
that's,
I
think,
what
we're
really
looking
for,
because
none
of
them
that
I,
like
literally
searched
a
couple
of
those
documents
for
npm
and
javascript,
and
they
like
barely
reference
it,
which
is
fine
that
doesn't
make
it
wrong.
It
doesn't
mean
it
won't
work.
We
just
need
to
have
you
know
not
just
assume,
based
on
reading
some
of
their
docs.
D
We
need
to,
I
think,
have
some
some
good
interaction
with
them.
Maybe
maybe
some
folks
from
github
security
also
would
be
able
to
chime
in,
like
I
said,
I
talked
to
some
netflix
folks
and
I'd
sure
have
some
of
them
would
be
happy
to
to
join
in
it
as
well.
But
I
think
github
has
a
much
more
unique
position
here.
So.
A
Michael
has
mike's
waving
his
hand,
he's
from
our
security
team
and
leading
product
there,
so
that
he's
started
to
join
these
conversations
for
sure
cb.
I
see
your
hands
up
and
then
miles.
I
know
you're
also
waiting
to
comment
feel
free
to
go
cb.
B
I'll
try
to
make
it
quick,
so
in
defense
of
the
bespoke
format,
it's
been
used
in
a
while
for
over
four
years
now-
and
this
is
the
next
iteration
of
it.
So
it
does
have
some
experience
behind
it,
and
I
think
the
biggest
benefit
of
a
bespoke
format
is
that
it's
gonna
be
human,
readable
and
small
in
scope,
these
referenced
ones.
B
Having
a
separate
like,
I
would
imagine,
a
separate
file
or
a
separate
advisory
or
how
we
want
to
call
them
which
overall,
they
seem
like
an
overkill
for
our
situation,
where
it
would
be
very
hard
that
would
require
a
lot
of
knowledge
context
or
tooling,
to
be
able
to
create
a
correct
specification
of
that.
Meanwhile,
what
we
really
need
is
something
very
specific
to
how
dependencies
work
and
is
not
found
in
those
or
many
other
examples
of
prior
art
where
we
can
have
copies
of
the
same
dependency.
B
E
Miles
hello
I'll
get
on
camera
again,
so
you
can
see
me
hello,
a
little
bit
of
a
tangent,
but
just
something
you
know
worth
bringing
up,
but
I
think
this
is
kind
of
partially
what
tyranny
was
getting
at
to
here.
I
think
that
there's
going
to
be
a
lot
of
motivation
to
fix
things
in
npm,
which
is
reasonable,
because
you
know
there's
a
lot
of
things
that
we
can
improve.
E
I
do
think
that
there
also,
though,
will
be
a
lot
of
motivation
to
come
up
with
solutions
that,
in
my
opinion,
can
be
a
little
bit
over
engineered
extremely
large
in
scope
and
much
harder
to
like
execute
and
roll
out,
as
opposed
to
like
kind
of
like
smaller,
as
we
refer
to
them
at
github,
like
paper,
cuts
that
we
could
roll
out
faster,
quicker
and
actually
solve
the
problem
to
me,
the
problem
that
we're
talking
about
here
there's
a
bunch
of
them,
but
one
of
them
is
that
there's
a
lot
of
noise,
which
is
the
inverse
of
there's,
not
a
lot
of
signal,
and
I
think
it's
important
to
remember
both
of
those,
because
almost
every
solution
I
ever
hear
is
about
reducing
noise,
but
never
actually
about
increasing
signal,
which
is
a
whole
other
thing.
E
We
can
path,
we
can
go
down.
There
are
ways
that
I
think
we
can
solve
this
with
ux,
just
in
what
the
cli
prints
out
to
people.
What
we
have
right
now
is
super
freaky
in
the
way
that
the
pandabot
rolls
things
out.
I
think
that
there's
things
that
we
could
do
that
are
like
smaller
iterations
that
clean
it
up
a
bit
that
could
reduce
a
whole
bunch
of
the
noise
which
goes
into
the
other
thing.
E
I,
though,
am
not
a
hundred
percent
convinced
that
necessarily
like
you
know,
solutions
that
go
in
the
space
of
overrides
or
heavily
engineered.
E
New
infrastructure
is
going
to
be
the
solution.
I
personally
think
that
this
boils
all
the
way
down
to
cves
being
somewhat
inherently
broken,
and
I
use
that
term
kind
of
loosely.
You
have
this
concept
in
the
cve
of
severity
and
that
severity
high
severity
is
availability.
So
if
you
have
a
dos,
it's
extremely
high
severity
that
is
completely
non-contextual
if
you're
using
a
cli
tool.
I
don't
necessarily
I
mean
like
it
sucks
if
it
crashes,
but
that's
not
high
severity
to
me.
E
The
other
thing,
too,
is
like
we
always
kind
of
think
of
things
here,
very
binary
on
or
off
it's
vulnerable
or
if
it's
not
vulnerable,
you
know,
and
that
also,
when
we
think
about
some
of
the
solutions
we're
seeing
here,
like
kind
of
leans
into
that,
but
it's
like
hey,
it
was
turned
on
as
vulnerable,
so
I
want
to
turn
it
off,
so
it's
not
vulnerable
anymore
versus
if
we
had
like
a
trinary
of
like
very
bad,
bad
and
non-existent.
E
This
starts
to
get
into
that
space
where
we're
solving
for
increasing
signal,
as
well
as
reducing
noise,
where
we
could
say
hey,
you
know
like
this
one's
really
bad.
You
should
definitely
pay
attention
to
it
and
so
kind
of
like
summing
up
all
of
that,
I
am
extremely
concerned
about
proprietary
solutions
that
carve
out
an
island
for
npm
to
paper
over
a
problem
that,
arguably,
is
not
an
npm
problem.
E
The
npm
problem,
specifically
that
we
have
right
now,
are
usability
ux
and
noise,
not
maybe
even
take
out
the
noise,
but
the
problems
that
we
have
around
like
knowing
how
applicable
a
cve
a
vulnerability
is
to
the
context
of
how
you
use
it.
E
We
can
roll
out
over
the
next
quarter
or
two
well,
we
at
the
same
time,
you
know,
engage
with
people
in
these
standards,
engage
with
the
people
who
are
running
these
vulnerability,
databases
and
think
about
how
we
solve
this
problem
of
applicability,
which
I
don't
think
is
an
npm
specific
problem.
This
is
an
ecosystem,
wide
security
issue.
That's
it
for
me.
For
now,
I
think
wes
has
their
hand
up.
F
I've
been
taking
a
lot
of
notes
and
have
a
lot
of
thoughts,
but
I'll,
try
and
I'll
try
and
keep
it
quick,
I'll,
go
and
kind
of
reverse
order.
A
couple
of
things
that
miles
said
struck
me.
So
the
comment
about
signal
to
noise.
We
did
this
in
dependable.
F
We
went
ahead
and
changed
it
to
no
longer
notifying
affected
folks
for
low
and
medium
and
only
doing
high
and
critical.
I
was
just
looking
at
the
data
on
this,
the
fix
rate
or
that.
Well,
I
guess
two
things
the
the
sort
of
like
engagement
rate
on
the
notifications
has
remained
roughly
the
same,
and
the
patch
rate
has
has
trended
slightly
up
over
time,
but
the
customer
satisfaction
aspect
has
gone
up
significantly.
F
So
that
was,
I
think,
a
very
reasonable
point.
I
think
there
was
a
second
one
on
reducing
the
work
for
maintainers,
and
I
was
thinking
about
this
a
lot
because
it
felt
like
one
of
the
sort
of
main
points
of
tension
in
the
proposal.
Was
you
know
what,
if
a?
What?
If
a
maintainer,
is
malicious
and
marks
something
as
safe
when
it's
not
the
sort
of
like
there's
a
human
element
of
choice
that
goes
on
here
and
I
was
sort
of
thinking
like?
F
Is
there
a
way
of
removing
the
human
from
the
element?
I
know
that
some
tools,
some
tools,
have
the
ability
to
just
do
static
analysis
and
check
if
a
function
is
called,
and
so
there's
part
of
me-
that's
like,
oh,
you
know.
Can
we.
You
know
at
least
me
because
I
work
at
github.
We
can
look
at
code
on
github
and
say:
yes,
you
actually
call
this
function
and
I'm
curious
if
that's
a
signal
and
like
that's
a
very
different
signal
than
saying
mark
safe.
F
It's
like
we
know
you're
affected,
or
you
know,
there's
a
high
probability
that
you're
affected.
I'm
curious.
If,
if
thinking
about
it
from
that
lens
would
would
shift
the
conversation
a
little
of
like
it's
static
analysis,
you
can't
argue
with
static
analysis
versus
this.
Is
a
human
judgment.
Call
I
see
people
laughing
about
canning.
Are
you
yeah?
Computers
are
hard.
F
The
other
thing
that
we
were
thinking
about
was
starting
to
only
alert
on
direct
dependencies,
so
that
again,
this
is
a
noise
problem
of
like
people
who
are
downstream.
They
probably
can't
do
anything
other
than
choose
to
not
use
whatever
the
upstream
dependency
is.
I
think
if
we
stopped
alerting
on
directs
and
potentially,
if
we
stopped,
you
know
notifying
indirect
in
either
github
or
downstream
tools.
That
would
probably
do
a
lot
for
customer
satisfaction
and
then
the
last
one
on
the
standards.
F
So
my
colleague,
william,
who
commented
on
the
doc,
is
more
of
the
standards
wonk.
I
admit
that
I
am
much
more
of
a
pragmatist.
The
two
standards
mentioned
vex
and
oasis,
and
then
the
google
one
they're
not
really
complete.
There's
still
a
lot
of
discussion
going
on,
I
know
william,
is-
is
attending
black
hat
and
they're
talking
about
it
there
so
they're
still
very
much
in
flux,
though
I've
had
a
couple
conversations
with
him.
F
The
implementation
mentioned
of
sort
of
you
know
package
or
module
version
status,
or
you
know
status
in
terms
of
impacted
and
then
a
comment
is
minimal,
and
so
I'm
not
super
worried
as
long
as
we
have
those
that
is
the
sort
of
subset
that
I
think
zb
mentioned,
like
we're
gonna
be
fine.
We've
had
to
do
this
in
other
things
at
github
as
well,
so
the
advisory
database
is
effectively
the
same
thing.
It's
we
had
to
come
up
with
a
minimal
subset
of
things
that
are
required.
F
It's
a
little
tedious,
but
it's
not
it's
not
the
end
of
the
world
to
do
those,
and
so
I
am
less
worried
about
us
backing
ourselves
into
a
corner.
I
think
that
the
standards
are
all
generally
reasonably
well
aligned
on.
Like
that's
what
we
want
to
get
done.
I
will
say
the
other
thing:
a
lot
of
the
standards
care
a
lot
about
s-bombs
and
provenance,
so
the
whole
goal
there
is
less
about.
F
They
care
a
lot
less
about
advisories
and
resolving
advisories
to
never
getting
to
an
advisory
in
the
first
place,
and
so
they
they're
caring
a
lot
about
how
are
they
doing
package
signing?
And
how
are
you
know
if
someone
signs
this
from
an
ip
range,
that's
outside
of
the
normal
one
or
it's
from
a
different
maintainer
like
flagging
those
things
as
potential
signals
early
on?
F
A
D
Mine
are
my:
I
have
a
gambit
of
responses
because
there's
a
lot
yeah
we've
talked
about
a
lot,
so
I
think
both
of
these
last
two
topics
are
not
within
scope.
I
think
here
and
so
here's
why
I
think
scope
is
so
important
for
us
to
have
this
discussion
talking
about
s-bomb
you
know
and
and
how
we,
you
know
miles
said
something
like
the
sources
that
the
cves
are.
You
know
we
got
to
fix
this
at
the
source.
D
These
are
not
npm
problems.
These
are
not
javascript
problems.
These
are
industry-wide
problems
and
that's
why
I
don't
think
going
deep
into
them
until
we
have
established
one
that
will
unless
we
are
vetting
them
to
see
whether
they
will
work
for
us.
I
don't
think
going
deep
on
this
call,
and
I
don't
think
going
deep
in
this
forum
is
the
correct
answer
because
we're
we
need
like
we
need
to
have
some
decision
makers
right
and
you
are
all
the
npm
decision
makers.
Maybe
we
have
a
github.
D
We
have
some
github
representation,
which
is
awesome,
but
we're
if
we're
going
to
repurpose
this
meeting,
to
be
how
is
dependapod
going
to
work
with
the
ecosystem.
Tooling.
How
is
you
know?
How
are
we
going
to
like?
I
need
this
to
work
for
me
at
netflix,
and
probably
that
means
having
some
snick
folks
in
because
we
pay
them
for
something
I'm
not
actually
sure
what
but
like
like.
Those
are
the
kind
of
things
where
this
spans.
D
I
would
love
it
if
you
could
report
back
on
those
things
I
I
will
personally
be
trying
to
keep
up
and
read
along
with
them
and
and
learn
as
I
go
and
then
again
bring
in
netflix
security
folks
to
help
you
know,
inform
my
opinion
and
and
help
as
well,
but
I
I
really
think
that
this
is
not
like.
We
need
to
focus
in
on
either
these
one
of
these.
D
A
couple
of
these
rfcs,
like
mike
miles
said:
maybe
some
ux
changes
first
and
not
try
to
boil
the
ocean
here,
which
is
what
all
of
these
topics
have
been
going
to
originate.
I'm
not
saying
the
oil
need
the
ocean
needs
to
boil
at
some
point.
D
It
just
is
not
necessarily
us
who
needs
to
do
it
right
now
to
make
meaningful
and
impactful
change
in
the
you
know
in
the
tooling
we
have
so
I'm
worried
that
we're
going
a
bit
astray
from
tyranny's
proposal
and-
and
you
know-
maybe
that's
not
super
valuable
or
maybe
we
need
to
move
the
conversation
over
to
the
collab
space
so
that
we
have
you
know
a
non-npm
specific
forum
to
to
bring
people
in.
D
You
know
I
don't
know,
I
just
don't
want
us
to
go
too
far
down
this
rabbit
hole
and
then
all
of
us
go
leave
this
meeting
and
say:
well.
We
just
spent
45
minutes
talking
about
problems.
We
can't
solve
right,
which
is
what
it
feels
like
a
little
bit
right
now
to
me
at
least
all
right.
C
So
I
I
do
mildly
agree
with
with
wes
like
I
would
absolutely
love
to
see
dependable
get
better,
because
I
have
plenty
of
feedback.
That's
felt
like
it's
gone
into
a
void.
I
also
don't
think
that
this
is
the
forum
to
discuss
that
feedback.
Like
I,
I
am
happy
to
provide
that
feedback.
I
don't
think
that
this
is
a
useful
place
to
discuss
it,
or
at
least
not
in
the
context
of
this
specific
topic.
C
Maybe
the
rfc
meeting
is,
but
perhaps
this
deep
dive
isn't
and
I
could
be
wrong
on
that
miles.
You
might
have
different
thoughts
on
that.
Then,
okay,
I'm
gonna
dm
you
mike
yeah.
You
might
have
a
different
opinion
on
that
mouse
guide.
E
E
That's
around
usability
before
we
do,
as
you
refer
to
it
like
boiling
the
ocean
that
I
think
that
there
there
are
smaller
iterative
in
scope,
cli,
specific
improvements
that
could
be
made
and
potentially
the
only
reason
I
mentioned
dependable
in
conjunction,
is
because
the
noise
coming
from
dependable,
like
the
github
advisory
database
and
the
npm
device
advisory
databases
are
intertwined
and
so
like.
E
If
we
lower
noise
on
one,
we
kind
of
need
to
do
it
on
both
or
it's
not
like
a
full
story.
I
am
for
a
number
of
reasons,
not
convinced
right
now
that
allowing
third
parties
to
turn
off
notifications
on
on
their
like
I'll
rephrase
it
I
maintain
a
package
that
package
has
a
vulnerability.
E
I
don't
think
I
should
actually
be
able
to
stop
people
from
being
warned
about
that,
and
I
know
that
there
is
a
debate
about
that
where
people
are
saying,
I'm
the
person
who
knows
the
code,
the
most
the
whole
value
to
me
of
audit
is
the
fact
that
it's
a
third
party
like
if
I
can
just
turn
off
all
of
the
audit
notifications
of
every
single
thing-
that's
vulnerable
in
my
package,
and
we
may
as
well
just
turn
off
audit
like
the
value
of
it
is
that
it
comes
from
a
third
party.
E
Those
are
all
to
me
completely
separate
issues,
and
I
think
that
a
solution
that
is
like
I
just
turned
this
off
for
all
of
the
consumers
by
itself.
It
creates
more
problems
than
it
solves
so
can
I
can
I
once
one.
A
Second,
let
me
quickly
comment
on
what
milestone,
since
I
haven't
competent.
Quite
yet
on
that.
So
already,
a
good
portion
of
the
ecosystem
does
turn
off
npm
audit
by
default
because
they
use
a
different
package
manager,
so
yarn
and
pnpm
do
not
do
auditing
by
default
when
you're
installing
packages.
So
it's
like
it's
just
good
to
recognize
that
you
know
the
tooling
ecosystem
at
large.
A
You
know,
you
know,
is
fragmented
and
that
the
recommendations
that
we
have
for
npm
are
not
shared.
You
know
like
our
our
values
are
not
shared
and
that
the
product
is
not
the
way
that
we
see.
The
value
in
audits
are
is
not
shared
with
everybody
else
in
the
ecosystem.
A
So
just
wanna
be
mindful
that
that
you
know
we're
talk
when
we're
talking
about
the
value
of
cvs
and
then
bubbling
up
vulnerable
packages
like
our
strategy
is
different
than
some
of
the
our
our
competitors,
let's
say
or
our
our
peers
so
and
then
yes,
wes,
feel
free
to
top
up
and
and
I'm
not
sure,
tierney
or
zb.
Who
was.
D
One
thing
that
we
dropped
from
this
conversation,
but
we
had
had
with
a
few
other
folks,
is
the
ability
to
have
a
a
trusted
third
party
source.
So
in
this
case
at
netflix
we
don't
want
to
trust
npm,
like
not,
you
know
any
just
we
did.
We
want
to
have
our
own
layer
of
trust
right
and
to
do
that.
What
I
want
out
of
this
is
actually
the
the
interchange
format
and
then
to
be
able
to
point
npm
at
our
some
of
our
packages
or
some
server
that
we
have.
D
That
provides
this
interchange
format
of
things
that
our
security
team
vetted
right
or
or
some
internal
maintainers
or
whoever
and
that's
not
involving
npm
inc
or
well,
I
guess
github
whatever
now
you
know,
however,
you
all
decide.
This
feature
belongs,
but
right.
So
I
I
that's
something
I
would
want
out
of
this
and
if
we
went
with
defining
an
interchange
format
and
a
way
that
npm
could
consume
that
interchange
format,
I
think
that
would
be
a
lot
more
beneficial
and
it
would
remove
one
of
the
key
things
miles.
D
You
said,
which
is
like
that
level
of
trust.
You
want
a
third
party,
so
now
we
could
then
go
and
netflix
could
publish
ours
internally
and
then
we
decide.
Oh
well,
maybe
there's
some
use
open
sourcing.
This
and
somebody
could
say:
okay,
I
trust
their
judgment
or
you
know
specific
security
companies
could
do
the
same
and
then
that
would
give
us
a
larger
ecosystem.
I
think
to
adopt
this
at
the
same
time,
really
strengthening
that
security
aspect
that
you
talk
about,
which
is
not
necessarily
putting
more
work
on
the
maintainers.
D
C
Sure
so
I'd
like
to
reclaim
just
because
I
I
seated
some
time
to
miles
because
he
specifically
wanted
to
address
a
single
point.
First,
I
do
want
to
counter
what
miles
said,
and
that
is
what
my
the
way
that
miles
framed.
This
rfc
is
not
what
it
does.
It
does
not
specifically
allow
people
to
just
maintainers
to
explicitly
ignore,
or
you
know,
silence
dependencies
for
all
of
their
users
like
there
is.
C
There
is
an
a
hatch
that
that
people
can
use
like
if
a
netflix
or
a
google
or
a
whatever
cares
to
still
get
all
of
that
information,
and
I
think
that
that
is
an
important
point
that
it
still
that,
like
that
information
is
never
not
available
or
never
completely
hidden
from
you.
It
is
just
we
are
taking
information
from
maintainer
provided
by
maintainers
to
supplement
what
the
third
party,
which
is
presently
npm,
is
sending
right.
So
it's
it's
adding
on
to
that
third-party
data
with
additional
context.
C
That
is
from
that
subject,
matter
expert,
which
I
think
is
different
than
saying.
Basically,
I
just
turned
this
off
and
there's
no
he'd
ever
hear
from
it
again.
C
There
was
other
points
I
had,
but
I've
at
this
point
lost
them,
so
good
go
ahead.
Zb.
B
Okay,
so
what
I
wanted
to
achieve-
and
I
linked
to
a
blog
post,
which
was
reaction
to
dan's
twitter
thread
in
the
first
place.
B
So
what
I
wanted
to
achieve
is
to
make
something
like
if
you
remember
early
on
with
adblock,
there
were
a
bunch
of
people
who
were
creating
lists,
and
to
this
day
one
of
the
lists
is
named
after
a
guy
who
started
it.
I
envisioned
this
counterclaim
mechanism
as
anyone
being
able
to
publish
curated
lists
of
which
dependencies
of
which
packages
or
which
dependencies
in
general,
when
this
dependency
path
exists
in
your
in
your
tree,
are
safe
to
ignore
or
are
already
fixable,
etc.
B
So
the
phone,
the
format
actually
covers
three
distinct
ways
to
market
for
now.
Anyway,
the
idea
is
that
npm
would
be
one
of
those
publishers
and
you
can
opt
in
or
with
npm
client.
If
you
want,
you
can
make
it
out
of
the
curated
list
coming
from
npm,
but
you
can
have
a
list
from
a
react
ecosystem
that
would
cover
react,
create
react,
app,
redux,
etc,
where
you
trust
them
to
know
what
they're
talking
about.
B
So
it's
not
every
maintainer
that
can
counter
claim
it's
the
maintainers
or
the
organizations
you
trust
that
can
counter
claim
and
that
solves
that
does
away
with
the
whole
problem
of
anyone
being
able
to
counter
claim
and
hide
something
because
they
got
mad
and
they
decided
to
write
a
script
that
counterclaims
everything
that
shows
up
in
any
of
their
200
packages,
which
which
I
bet
someone
will
do
once
we
released
it.
B
So
what
I'm
getting
at
is,
we
can
make
it
distributed
and
we
can
make
it
distributed
without
taking
away
the
ability
for
npm
to
create
their
own
list.
C
I
I
I
do
this
specifically
defeats
the
purpose
and
and
the
reason
that
you
know.
B
C
Can
I
can
I
finish,
though,
this
defeats
the
purpose
and
the
the
frustration
that
was
expressed,
which
is,
I
am
someone
new
to
javascript
and
react.
I
don't
know
what's
happening,
I
mpx.
What
would
it
be?
Npm
exec
react
app
right
and
then
I'm
all
of
a
sudden
alerted
by
a
million
vulnerabilities.
C
C
I'm
just
gonna,
either
trust
everyone,
or
just
no
one,
which
makes
the
feature
useless,
or
I
have
to
start
telling
people
as
a
middleware
maintainer,
like
as
a
transitive
dependency
maintainer
to
trust
me,
which
also
like,
gets
weird
and
defeats
the
purpose
for
those
who
don't
and
so
like
that
removes
the
utility
of
such
a
function.
A
So
I
just
want
to
quickly
interject,
as
we
only
have
about
six
minutes
left
here.
I
I
I
just
wanted
to
quickly
say
tunia.
I
do
agree
at
least
we've
had
conversations
in
the
past
and
we've
actually
had
some
discussion
about
where
this
information
lives,
and
at
least
my
support
is
for
any
kind
of
extra
meta
data.
Any
counter
claim
mechanism,
any
kind
of
like
source
of
truth
should
be
coming
from
the
exact
same
place
that
the
advisory
came
from
so
like.
A
I
don't
believe
that
you
should
have
to
configure
two
separate
sources
of
truth,
and
I
know
that
there
has
been
recommendation
in
recommendations
or
or
ideas
brought
up
in
the
past
about
a
potential.
You
know,
distribution
of,
ignore
lists,
or
things
like
that
or
even
you
know,
which
I
don't
think
are
are
necessarily
personally
don't
think
that
those
are
necessarily
good
ideas.
A
You
know
if
you're
going
to
choose
a
trusted
source
for
your
advisory
information,
then
that
should
be
the
same
source
for
that
any
kind
of
counter
claim
or
metadata
would
also
be
coming
from,
but
in
also
I
just
want
to
give
wes
one
more
a
chance
here
to
chime
in,
but
want
be
mindful
that
we
only
have
five
minutes
left
and
I
would
like
to
get
maybe
some
action
items
or
certain
next
steps
in
terms
of
this
conversation
going
so
wes
I'll
I'll.
D
I'm
happy
to
table
my
specific
points
if
we
can
get
actual
action
items,
I
I
and
so
I'll
say
what
I
think
the
action
items
need
to
be,
and
then
you
know
everyone
else
can
add
those,
but
I
think
we
need
to
decide
what
problem
we're
solving
before.
We
start
digging
too
deeply
into
these
solutions,
because
we've
even
the
conversation
in
the
issue
and
then
this
there's
a
lot
of
little
details
that
I
think
are
very
important.
D
Once
we
get
to
the
point
of
actually
rolling
a
feature,
I
think
this
jumped
the
gun.
I
think
that
we
have
to.
We
might
end
up
doing
something
like
this.
I
actually
think
we
should
like
I'm
all
thumbs
up
for
this.
I
just
think
that,
like
to
miles's
point
and
everybody's
really
in
agreement
that
there's
just
a
lot
of
parts
to
the
security
story,
that
we
don't
really
have
a
good
answer
for
and
some
of
them
may
end
up
being
more
important
than
counter
claims.
D
So
I
just
want
to
make
sure
that
we
don't
like
try
to
make
counter
claims
the
end-all
be-all
feature,
and
we
spend
a
ton
of
time
on
it
and
then
find
that
like
really
this
other
thing
that
was
much
easier
to
do
could
have
been
like
10
times
more
impactful.
So
I
I
really
think
we
should
take
a
action
item
to
start.
B
D
The
darn
meeting
scheduled
in
the
collab
space
and
talk
from
a
slightly
higher
level,
not
just
about
npm,
get
a
few
of
the
security
folks
involved
from
github,
specifically
but
again
I'll.
I
think
we
should,
you
know,
tap
our
resources
to
bring
as
many
in
as
we
can
to
to
see.
If
there's
you
know,
maybe
one
extra
field
that
the
advisory
databases
could
accept
from
reporters
and
it
would
suddenly
solve
like
a
whole
ton
of
the
counterclaim
problems
like
there's.
Those
discussions
haven't
even
really
been
had
in
this
group.
D
You
know
with
these
people
yet
so
I
think
the
first
and
foremost
we
need
to
have
the
like
problem
statement
really
ironed
out,
and
I
think
the
collab
space
is
the
right
place
to
do
that.
I
think,
secondly,
for
this
specific
rfc,
I
think
that
there's
both
gaps
in
the
features
required
like
some
of
the
ones
that
zebe
pointed
out
with
dependents.
D
You
know
transitive
paths,
and
you
know
I
think,
some
of
the
things
about
whether
it's
applicable
being
just
a
boolean
or
whether
it
needs
more
context
like
some
of
those
things,
I
think,
are
pretty
big
gaps
and
would
block
this
from
being
finished
anyway.
So
I
would,
I
would
propose
that
the
rfc
either
be
fleshed
out
to
add
a
bunch
of
those
things
that
have
been
mentioned
in
the
comments
already
and
to
really
like
iron,
those
out
and
maybe
make
a
much
larger
section
of
like
unanswered
questions.
D
Something
like
that,
so
that
we
have
like
real,
concrete
things
to
work
off
and
we
don't
spiral
like
the
conversation
sort
of
did
so
far
in
the
issue.
So
I
think
those
are
the
two
to
me
that
would
be
the
most
impactful
action
items
from
this.
A
Okay,
so,
based
on
the
couple
minutes
that
we
have
left
cb
is
also
plus
one
and
your
your
feedback
there
wes
so
I've
added
at
least
an
initial
action
item,
which
I
thought
was
brought
up
along
our
conversation
here,
tierney,
if
you're,
okay,
with
providing
some
more
scope
to
the
rfc
itself,
just
to
contextualize
and
try
to
focus
the
conversation
and
feedback
you're
gonna
get
on
the
rc.
It
should
help
with
people
not
trying
to
boil
the
ocean,
as
as
we've
discussed
here.
A
There's
a
second
item
or
action
item
that
I've
queued
up
here.
Based
on
you
know,
miles
is
feedback
and
internal
discussion
that
we've
already
had.
A
Our
team
is
definitely
willing
to
and
would
like
to
look
at
how
we
could
improve
the
existing
output
of
audit
and
whether
or
not
there's
some
design
decisions
that
could
be
made
to
just
make
that
experience
better
in
general,
and
I
feel,
like
that's
sort
of
a
paper,
cut
type
issue
and
may
not
even
require
necessarily
a
whole
rfc
to
to
to
improve
that
experience,
and
this
kind
of
goes
back
to
what
mike
also
was
saying
in
terms
of
the
changes
made
to
dependable
that
you
know,
quality
of
life
could
be
improved
for
developers,
whether
or
not
like
we're
actually,
like.
A
You
know,
fixing
the
root
cause
with
some
of
the
changes
we
make
there.
It
might
just
be
that
you
know
again.
People
are
more
likely
to
potentially
action
if
on
some
of
these
advisories,
if
it's
presented
them
in
a
nicer
way,
so
it
might
just
be.
You
know
this
is
a
way
that
we
can
look
at
solving
this
through
ux
and
design
just
to
make
things
better.
So
I'm
putting
that
as
an
action
home
as
well
and
then
in
terms
of
any
other
action
items
you
know
like
there's.
A
Obviously
the
which
I'm
not
gonna
take
as
an
action
item
for
us
but
wes,
I
know
you're,
you
continue
to
reference
the
cloud
space,
that's
something
that
I
think
we
can
take
offline
and
discuss
how
we
want
to
engage,
maybe
some
of
the
referenced
foundation,
external
foundations
that
are
also
doing
work
in
this
space
and
how
we
can
collaborate
with
them
in
specifically
that
group
right.
A
So
I'd
rather
be
more
tactful
here
with
the
conversation
we
have
for
for
this,
our
my
open,
rc
call
specifics
to
npm
and
then
within
terms
of
like
trying
to
solve
the
the
larger
problem
at
hand
without
the
clap
space.
Let's,
let's
keep
action
item
over
there
to
reach
out
to
those
other
organizations.
I
think
so.
A
A
No
well,
I
appreciate
everybody
jumping
on.
I
know
we're
about
a
minute
over
we'll
be
back
next
week,
hopefully
with
a
more
regular
agenda,
and
this
doesn't
mean
we
won't
go
deep
into
this
again
when
we
have
some
some
progress
and
and
sort
of
updates
to
be
had.
I
know
tierney
there's
going
to
continue
to
be
discussion
on
this
rfc
and
hopefully
folks
feel
like
they
can
continue,
add
feedback
and
we'll
try
to
continue
to
flush
this
out
so
appreciate
everybody
jumping
on
and
hopefully
see
you
next
week,
cheers.