►
From YouTube: Open RFC Meeting - Wednesday, Dec 16th 2020
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
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
december.
The
16th
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
number.
A
I
believe
it
was
issue
number
296.,
I've
copied
and
pasted
the
hackmd
dock
for
notes,
if
you'd
like
to
add
yourself
as
an
attendee
and
we'll
be
following
along
there,
a
quick
code
of
conduct
acknowledgement
just
that
these
calls
and
and
all
communication
in
the
rfc's
repo
is
covered
under
code
of
contact.
We
just
asked
that
you'd
be
kind
and
please
raise
your
hand
if
people
are
speaking
and
I'll
call
on
you.
We
have
a
short
agenda
today,
but
just
a
couple
of
announcements.
A
I
want
to
say
that
this
is
the
last
rfc
call
of
the
year,
so
I'm
a
bit
festive
today,
but
I
just
want
to
also
say
thank
you
to
everybody.
That's
been
coming
out
to
these
calls
this
past
year,
it's
been
working
quite
well
as
a
forcing
function
for
us
to
continue
to
collaborate
with
the
community
and
just
give
another
mechanism
for
us
to
push
forward
features
that
we
want
to
see
made
in
the
npm.
A
We'll
be
returning
in
the
new
year
so
wednesday
january,
6th
2021
will
be
the
first
open.
Rfc
call
that
we'll
we'll
have
in
the
new
year
so
feel
free
to
put
that
in
the
calendar
and
or
there's
a
link
to
the
public
events
calendar.
A
I
think
in
one
of
the
issues
on
the
npm,
rc's,
repo
and
or
the
readme,
I
think
great
miles
see
you
joined,
feel
free
to
add
yourself,
hello,
cool.
So
if
there's
nothing
else,
any
other
announcements
folks
want
to
bring
up
if
not
we'll,
dive
right
in
so
the
three
items
we
have
are
listed
there,
the
first
of
which
issue
number
287.
A
I
believe
this
is
the
item
that
we
want
to
do
a
deep
dive
on
the
last
action
item.
I
think
was
just
to
schedule
that,
as
far
as
I'm
aware,
so
this
is
a
the
concept
of
providing
a
flag
or
a
mechanism
for
changing
the
behavior
of
install
to
not
like
not
voiced,
let's
say
workspace
dependencies.
A
B
I
think
that's
where
we
landed
on
it
yeah.
There
was
a
lot
of
a
lot
of
back
and
forth
and,
and
you
know
clearly,
there
was
kind
of
some.
B
You
know
reasonable
minds
disagreeing
about
some
things,
but
you
know
also
the
use
cases
are
quite
subtle,
so
you
know,
there's
a
bunch
of
cases
where
no
hoist
is
is
absolutely
terrible
and
a
bunch
where
that's
actually,
what
you
need
is
to
not
hoist
things
and
treat
each
workspace
as
top
level
depths,
and
even
some
cases
where
you
kind
of
need
a
mix
where
you
need
like
this
thing
to
be
hoisted,
but
this
other
these
other
things
not
to
be
okay,.
A
We
do
have
a
doc,
no,
we
we
did
a
bit
of
a
deep
dive
on
workspaces.
I
think
was
the
the
thing
that
we
talked
a
little
bit
about.
We
did
have
a
long.
A
About
I
would
say,
like
a
month
back,
we
took
up
a
good
20
30
minutes
on
this,
but
I'm
going
to
remove
the
agenda
label
for
now
on
this
specifically
and
then
I'm
going
to
take
the
action
to
set
up
a
call
for
that
specifically
and
then
we'll
poke
I'll,
make
an
issue
and
I'll
poke
the
relevant
folks
to
hopefully,
hopefully
join
in
in
the
new
year.
A
So
moving
on
to
the
rfc
and
I'm
not
sure
if
we've
created
an
rfc
for
this
yet
but
275..
So
this
is
the
registry
protocol
concept
that
isaac.
I
know
you've
proposed
again
yeah.
B
That's
that's
also
yeah,
so
the
the
update
on
that
is
it's
still
where
it
was
last
week,
it's
somewhat
uncontroversial,
just
kind
of
need
to
write
up
the
spec
and
then
outline
all
the
places
where
we
need
to
to
do
it,
but
in
terms
of
the
actual
like
dx
and
usage
of
it
yeah,
it
seems
like
everybody
just
wants
it.
So,
just
a
matter
of
just
a
typing
problem.
A
Okay,
and
then
I
guess
the
last
item
that
I
just
added
here,
I
know
we
talked
a
little
bit
about
a
package
maintenance
working
group
yesterday
and
I
know
bradley
has
started
to
draft
this
pr.
Did
you
want
to
maybe
speak
to
the
poll
request
297?
E
I'm
fairly
open
to
whatever
design
it
seemed.
It
seemed
when
we
were
discussing
this
with
the
package
maintenance
working
group.
They
were
centered
on
the
idea
of
it
being
about
needing
incentives
for
package
authors
to
put
this
in
their
package.json
field
and
that
kind
of
ended
up
with
me,
realizing
that,
although
in
the
previous
rfc
call,
I
got
sent
there
that
wasn't
the
right
location
for
a
discussion
of
such
a
field.
E
Basically,
the
idea
is,
we
add
some
kind
of
field
to
package.json,
to
allow
package
consumers
to
see
what
permissions
are
expected
to
be
granted
to
packages,
and
so
they
can
actually
grant
those
or
deny
things
that
are
not
listed.
E
E
It
wouldn't
be
meaningful
in
the
package
maintenance
working
group,
they
did
have
feedback
that
maybe
a
different
tool,
not
within
their
working
group,
might
be
a
better
place
for
such
an
attempt,
so
we're
making
mpm
rfc
directly
rather
than
trying
to
go
through
the
node
working
group.
E
So
I've
listed
some
motivations
and
some
things
like
that.
But
if
you
go
and
you
look
at
user
polls
and
things
surveys,
people
using
dino
people
using
browsers-
even
they
really
want
to
understand
what
permissions
they're
granting
to
things
that
they
run
currently
node
has
a
mechanism
to
enforce
some
levels
of
permissions.
E
It's
adding
more,
but
there's
no
real
way
for
you
using
the
package
managers
mpm
in
this
case
to
actually
show
what
permissions
are
being
granted
during
running
things
and
there's
no
way
for
you
to
say
you
don't
want
to
grant
more
permissions,
and
so
what
I'm
proposing
is
a
little
bit
two-fold.
E
We
need
a
field
for
package
authors
to
be
able
to
list
their
expected
required
capabilities
that
they
need
for
their
package
to
work,
and
we
go
into
a
little
bit
of
detail
on
why
alternatives
like
a
command
line
flag.
Don't
don't
really
appeal
to
things.
So
if
we
were
to
use
dino's
approach
where
you
basically
add
a
lot
of
command
line
flags,
you
get
to
cases
where
different
packages
are
treated
as
being
in
the
same
security
boundary.
So
let's
say
we
had
event
stream
event
stream.
E
They
wanted
it
because
they
were
running
web
servers,
and
so
we
need
this
kind
of
finer
grained
permissions
model
kind
of
on
a
per
package
level.
That's
a
bit
complicated,
but
we
want
to
be
able
to
avoid
specific
incidents
that
we've
seen
in
the
past
like
event
stream,
and
so
we
need
to
be
able
to
state
things
like.
E
I
want
express
to
have
https,
but
I
do
not
want
event
stream
to
have
https,
and
so,
when
you're,
installing
things,
if
we
use
the
command
line
flag,
it
would
not
be
easy
for
a
human
to
specify
all
those
flags.
As
often
people
are
installing,
without
listing
the
dependencies
because
they're
installing
from
a
package.json
they're
installing
multiple
packages
at
once,
because
they
put
more
than
one
on
the
command
line,
and
so
this
also
has
a
bad
workflow.
E
Where,
if
you
you
do
this
command
line,
you
basically
try
to
run
with
your
granted
permissions
from
the
command
line.
It
fails
to
run.
You
see
the
error,
you
add
that
permission
to
your
command
line
and
you
repeat
until
it
runs,
and
so
this
works
okay
to
some
extent
it's
not
pleasant,
but
it
also
doesn't
go
through
and
state.
Oh
this
feature.
If
you
use,
it
will
require
a
thing.
E
A
All
right
one
one
thing:
maybe
I'll
I'll,
make
a
couple
notes
and
I
see
jordan's
hands
up
as
well,
so
I'll
give
them
some
time.
So
just
one
one
clarification
here
as
well.
This
is
just
a
drafted
pr
so
far
and
and
I'm
sure
you're
looking
for
some
support
and
collaboration
to
to
make
it
more
formal
right.
A
E
A
D
Yeah,
so
I
was
in
the
discussion
yesterday
and
the
things
you're
saying
are
clear
bradley.
It
seems
that
me
at
least
I
did
not
do
a
good
job
of
being
clear,
because
that
is
has
nothing
to
do
with
what
we
were
trying
to
say
the
like.
I
think
the
future
is
good.
I
think
what
you
sketched
out
in
your
rfc
makes
sense.
I
think
it's
the
best
like
approach
to
providing
this
extra
signal
for
individual
packages.
D
You
know,
obviously
you
can't
rely
on
it
because
of
you
know
malicious
authors,
but
like
you
can
use
it
as
a
signal
to
determine
like
if
it's
changed
or
how
risky
the
package
is,
and
that's
great
that's.
I
think
this
is
a
good
thing.
The
what
we
were
I
think
stemming
on
a
bit
yesterday
in
the
call
was
that
as
a
package
author,
how
would
I
know
what
permissions
to
put
what
magic
strings
to
put
in
there?
So
my
package
works.
I
have
to
be
able
to
test
it.
D
People
are
going
to
ask
me
for
this,
and
I
have
like
the
number
of
people
that
ask
me
is
going
to
influence
how
how
willing
I
am
to
put
in
effort
to
put
in
this
field
and
justify
the
complexity
and
the
npm
cli
in
the
first
place.
Right,
because.
D
No,
I
know
I'm
sorry,
I'm
bringing
that
up
right
now,
I'm
saying
like
like
if
there
there
should
be
something
out
of
the
mpmcli
to
make
this
feature
most
effective.
I
agree
with
that
and
that's
why
the
and
discussing
that
here
is
the
best
venue
for
that,
but
adding
that
complex
this
complexity
to
the
cli
needs
to
be
justified
by
usage.
E
No
one
ends,
you
want
everything
to
be
a
carrot,
and
this
is
very
much
not
a
carrot
style
feature.
You
spoke
that
malicious
authors
could
exploit
this.
So
using
policies.
We
have
a
strict
security
model
and
like
if
you
list
something
we
will
deny
you
everything
else,
so
I
don't
understand
how
it
would
be
exploited.
There.
D
Oh,
I
mean,
as
I
can
like,
if
one
version
of
a
package
doesn't
request
file,
system
access
and
the
next
one
does.
The
change
might
alert
people
that
there's
a
problem
but,
like
you,
can't
necessarily
know
what
that's
doing,
whether
that's
legitimate
or
not
and
then
separately.
If
my
package
already
needs
file
system
permission,
you
know
it
could
be.
The
next
version
could
do
something
malicious
with
the
file
system
right.
So
I
I
was
just
pointing
out
that.
E
D
I'm
not
suggesting
that
that
like
diminishes
the
value
of
this
as
a
feature,
I
continue
to
think
it's
valuable
and
that
we
should
have
it
almost
exactly
as
you've
sketched
it
out.
I
I
what
I'm
saying
is
that
in
practice,
if
package
authors
don't
end
up
adding
it,
the
capability
of
like
this
capability
won't
end
up
being
useful.
A
So
maybe
I
can
add
one
thing
or
note,
or
our
idea
here
and
then
christian,
I
see
your
hands
up
and
I
think
wes
also
had
his
hand
up
at
one
point,
and
my
guess
is
that
there
would
have
to
be
a
default
if
we're
asking
that
there's
a
new
thing.
That
is
a
requirement
for
package
authors
to
like
add
as
a
signal
right
like
that's.
Why?
I
think
this
is
is
good
as
a
function
of,
and
then
we
can
potentially
have
something
that
you
know
actually
enforces
around.
A
You
know
these
these
permissions.
Then
there
probably
have
to
be
a
default
to
ensure
that,
like
historical
packages
that
may
never
get
updated,
essentially
would
have
to
default
to
asking
for
all
permissions
right
like
that
might
be
the
default.
Is
that
a
package
author
doesn't
have
to
do
anything,
so
the
expectation
is
that
they,
they
essentially
are
requesting
all
the
potential
permissions
right.
So
that
might
be
like
the
baseline.
A
It's
like
you
don't
have
to
do
anything,
but
you
know
what,
like
the
the
the
packages
and
and
maintainers
that
want
to
you
know,
create
a
safe
ecosystem.
Are
adding
these
new?
This
new
field,
which
essentially
specifies
you,
know
the
types
of
permissions
that
their
their
packages
want
access
to,
and
you
know
that's
a
good
indicator,
as
you
say,
like
a
good
indicator
of
like
you
know
a
package
you
probably
want
to
be
using
because
they're
starting
to
opt
into
this
new,
like
concept
that
you
know
is
hopefully
gonna
make.
A
You
know
the
ecosystem
a
bit
safer,
so
that's
sort
of
like
where
my
head
goes
is
like
there
would
have
to
be
some
sort
of
baseline
or
ability
to
support.
Let's
say
all
the
historical
packages
that
have
ever
been
created
without
having
to
ask
them
to
burden
themselves
with
like
updating
their
their
packages
and
just
saying
that
you
know
the
default.
Is
that
you're
you?
A
You
request
all
access
and
that
that
is
an
indicator
to
me
as
the
consumer
of
that
package
that
I
may
not
want
to
use
it,
because
I
don't
want
to
give
it
all
this
access
right
so
and
yeah
so
once
that
christian
has
had
his
hand
up
and
then
feel
free
to
rebuttal.
F
I
was
a
bit
afraid
that,
like
people
would
put
the
default
as
in
like
I
just
want
every
permission,
there
is
because
that's
just
simple
I
mean
I
can
see
this
feature
being
useful
because,
like
I
can
go
to
the
security
guy
and
just
tell
him
like
you
know,
we're
not
doing
anything
bad
like
here's,
the
printout,
you
can
look
at
it,
however,
also
like
all
those
permissions
like
I
don't
know,
they
may
convey
something
that
is
not
there
like.
F
D
F
F
A
Yeah
isaac,
I
see
you
have
your
hand
up.
B
Yeah,
so
this
is
kind
of
interesting.
I
think
I
think
that
there's
where
I'd
like
to
go
with
this
conversation
is,
you
know,
there's
kind
of
two
two
things
that
we're
talking
about
here.
B
One
is,
and
I
think
bradley
like
you
outlined
it
really
eloquently
like
we
need
to
have
per
package
or
perhaps
even
per
module
permission
settings
right,
because
just
saying
it
you
know
setting
it
for
your
entire
application
is
kind
of
pointless
like
every
node
application
is
touching
the
file
system
in
the
http
like.
B
So,
if
that's
where
I'm
granting
it
that
doesn't
make
any
sense
and
it
needs
to
be,
you
know
it
would
be
good
for
it
to
be
kind
of
declared
by
somebody
who
knows
what
this
module
is
doing
I.e.
The
package
author,
like
that,
does
make
the
most
sense.
So,
let's
say
hypothetically,
I
you
know
we
just
we
have
a
thing
in
package.json
where
you
declare
what
permissions
you
need
and
that's
all
that
your
module
or
anything
in
your
you
know
in
that
module
scope,
kind
of
has
access
to.
B
Maybe
some
of
my
dependencies
or
meta
dependencies
might
have
different
permissions
right.
So
I'm
and
then
that
kind
of
becomes
potentially
like
a
loophole
where
well,
I'm
not
doing
any
file
system
access,
but
I'm
using
this
other
module,
which
does
and
it
has
permission
to
and
maybe
that's
something
we
want
to
do
or
don't
want
to
allow
like.
We
could
figure
that
out
later
the
then
the
the
interesting
question
becomes
without
without
burdening
anybody
with
excess
work,
or
you
know
kind
of
unpleasant
or
tedious
ux.
B
How
do
we
get
to
a
place
where
most
node
apps,
where
most
of
the
modules
in
most
node
applications,
have
these
declarations
and
they're
active?
So
there's
two
things
that
that
I
can
think
of
one
is,
you
know:
incentivizing
incentivizing,
the
authors
who
who
do
this,
who
opt
into
this,
could
be
as
simple
as
sort
of
prioritizing
them
in
the
in
our
search
algorithm.
B
So
you
know
if
you
like,
if
you're
searching
for
modules,
you're
going
to
find
the
ones
that
have
declared
a
a
you
know,
a
a
thing
that
that
declares
its
permissions
over
those
that
don't
the
other
thing
that
we
can
do.
You
know
it's
it's
easy
to
talk
about
carrots
and
sticks,
but
I
think
often
we
forget
about
just
like
greasing
the
skids.
B
So
one
of
the
you
know,
maybe
even
more
effective
than
providing
incentive,
is
just
making
it
the
default
and
making
it
easy
so
that,
if
you're
lazy,
this
is
what
happens,
and
I
I
don't
see
an
an
obvious
way
to
do
that.
Maybe
we'll
think
of
one.
If
we
keep
kind
of
chewing
on
this,
but
you
know
we
could
have
some
kind
of
automated
tool
that
looks
at
like
which
node
modules
you
know
which
node
built-ins
you
require
and
when
you
do
npm
init,
it
just
automatically
says
like
hey.
B
B
Then
I
think
it's
and
so
for
legacy
packages.
We
could
also
do
something
where
potentially
we
like
go
through
and
look
at
and
like
run
this
same
kind
of
init
tool
against
all
the
packages
in
the
registry
and
maybe
start
you
know,
sending
out
prs
or
even
just
defaults
to
what
we
put
in
the
pacument
so
that
those
things
can
kind
of
be
brought
forward.
That's
maybe
a
bigger
project
that
we
could
put
off
until
later,
but
for
the
for
the
initial
step,
I
think
we
should
think
about
like
like
hey.
B
I
I
think
that
the
the
feature
as
proposed
is
good.
Then
the
question
becomes
like:
how
do
I
get
people
to
use
it,
and
my
my
two
kind
of
suggestions
are
just
make
it
easy
and
prioritizing
the
search
algorithm.
E
So
yeah
I'd
agree.
I
think
there
is
value
in
the
permissive
by
default
because
it
doesn't
break
anything
yeah.
E
No
we're
that's
not
a
route,
I
would
even
entertain.
There
are
a
couple
of
existing
tools
that
do
what
you
say
and
other
bundlers
have
basically
the
same
capability,
and
so
maybe
it
would
make
sense
for
a
github
bot
or
something
that
people
could
tap
into
for
it
to
scan
their
stuff.
E
That's
one
approach,
like
you
said
you
could
kind
of
do
it.
As
an
author
manually,
I
don't
think
that
that'll
be
super
clear,
but
if
things
do
show
up
in
the
search,
I
I
don't
think
you
should
have
the
default.
All
permissions
show
up
as
all
the
component
permissions
really
because
it'll
scare
people
into
thinking.
A
Yeah,
so
I
see
jordan
and
wes
have
their
hands
up.
I
think
jordan.
You
were
first
if,
if
I
remember.
D
Yeah,
I
just
wanted
to
add.
I
think
that,
in
addition
to
search
results
and
npm
in
it,
which
are
great
suggestions
for
greasing
the
skids
as
it
were,
I
think
I
have
no
idea
and
haven't
looked
into
it,
but
how
to
use
policies,
but
if
it
becomes
super
easy
to,
as
a
package
author
run,
my
tests
with
policies
enabled
to
see
what
permissions
like
so
that
I
can
see.
D
B
Does
node
have
like
a
permission,
auditing
mode
so
like
run
with
all
permissions,
but
then
at
the
end
of
the
process,
be
like
here's
what
you
did
so.
D
The
way
lava
mode
works
is
is
essentially
it.
It
tries
to
do
the
same
thing
at
runtime
without
node
integration
and
like
it
can
print
out,
essentially
a
module
map
of
which
modules
have
have
access,
which
types
of
scary
things
it's
not
robust,
because
it's
you
know
it's
heuristics
and
stuff,
but
I'm
wondering
if
maybe
node
could
have
something
like
that,
where
I
could
just
run
my
tests
with
this
mode
enabled
and
it
would
spit
out
a
json
file,
and
then
I
could
programmatically
verify
that
my
permissions
match
with
that
within
that
json
file.
E
D
Yeah,
I
mean
just
anything
that
that
wraps
at
all,
whatever,
whatever
it
is,
anything
that
wraps
it
all
up
in
a
way
that
is
trivial
for
the
package
author.
I
think
that
also
goes
a
long
way
to
incentivizing
it,
because
I
think,
if
it's
easy
and
prevents
regressions
and
is
automated
largely,
I
think
that
it's
going
to
be
a
really
hard
like.
I
can't
imagine
package
authors
being
like.
D
Yes
exactly,
but
if,
but
if,
if
the
pr
can
arrive
with
all
those
things
done
or
if,
like
a
package,
author
who's
incent
who's
motivated
to
to
do
it
can
like
easily
do
it,
then
it
seems
like
like
at
that
point.
I
would
easily
do
it
on
all
of
my
packages,
because
I
would
have
confidence
that
I
was
doing
the
right
thing
and
that
it
wouldn't
break
in
the
future.
G
I
think
all
of
them
sound,
like
they're
they're
gonna
make
for
a
much
straight,
more
straightforward
user
experience
for
package
authors,
I'd
like
to
talk
a
little
bit
about
what
the
application
authors
get
once
they
have
this
world
where
all
the
the
module
authors
have
or
you
know,
package
authors
have
sort
of
instrumented
their
packages,
so
I'm
I
I
see
the
the
sort
of
main
ask
is:
have
the
package
installer
read
through
all
of
these
at
install
time
and
generate
a
policy
right
which
is
great
because
it
it
avoids
the
currently
rather
tedious
thing
that
you
mentioned,
which
is
run
your
process
with
nothing.
G
Add
one
see
if
it
works.
You
know
iterate
until
you
finally
get
a
fully
running
app
right,
which
obviously
is
going
to
be
a
pretty
much
non-starter
for
most
actual
application.
Authors.
I
say
most
obviously
not
all.
I
wonder,
though,
even
with
all
of
this
instrumented,
I
still
think
there's
this
trust
model,
because
now
all
I'm
going
to
so.
If
it
changes,
I'm
going
to
see
an
error
right
because
it
will
fail
to
start
because
the
policy
that
was
generated
originally
isn't
there.
So
then
my
process
would
be
okay.
What
changed?
Okay!
G
This
package
now
asked
for
file
system
permission.
What
is
the
average
engineer
going
to
do
to
investigate
whether
or
not
it's
fine
to
say
yes
right?
The
the
process
that
I
go
through
when
I
get
a
cve
report
in
an
application
is
like
super
painful
for
me,
and
I've
been
on
teams
where
I'm
the
only
one
who
does
that
and
then
I
find
that
it's
not
applicable
right
and
that's
like,
and
it
is
problematic
the
times
that
it
has
been
applicable
have
actually
been
times
where
it
wasn't
even
running
a
node
thing.
G
Where
you,
you
would
try
to
figure
out
how
to
slide
it
in,
under
an
already
requested
permission
at
that
point
me
as
an
application
author,
I'm
still
basically
just
at
the
point
of
saying
yes
without
unless
I
go
and
do
a
ton
of
extra
work
to
go
and
investigate
exactly
how
that
thing
is
using
that
new
api
I
just
requested.
So
I'm
wondering
if
we
do
all
this
work
to
get
this,
you
know
instrumented.
Have
we
really
meaningfully
changed
the
security
for
the
end
user?
Who
is
the
one
who
has
to
say
yes
or
no.
G
I
think
that
was
it.
The
end
question
was
just
we
do
all
this,
which
I
think
is.
It
sounds
all
great
on
paper.
I
just
want
to
make
sure
that
we're
driving
toward
an
end
goal
where
the
end
you
like.
How
are
we
meaningfully
changing
the
end,
user's
experience
in
a
way
that
improv
that
improves
their
security
and
and
confidence
in
their
code?
Sure
without
just
saying
yes
to
it
right
because
that's
like,
I
think,
dependency
for
a
lot
of
people
is
just
to
be
like
yes,
accept.
A
A
A
So
I'll
give
you
the
floor
here
in
a
sec,
and
then
maybe
we
can
put
a
time
frame
on
this
a
little
bit.
I
did
have
a
list
of
discussions.
I
wanted
us
to
follow
up
on
so
maybe
give
another
five
minutes
to
this
discussion.
But
one
thing
to
note
there,
just
based
on
what
you
just
said:
wes,
I
don't
think
security's
like
binary,
like
I
think
that,
like
you
know,
I
think
you
know
it's
incremental.
You
make
things
safer
over
time
and
I
think
that
this
is
like
you
know.
A
This
won't
get
us
all
the
way
there
and
securing
completely
securing
like
your
your
applications,
but
like
it's
like
you
know,
improvements
over
time
are
going
to
make
it
better,
and
so
I
think
that
this,
like
at
least
for
me,
I
see
this
as
being
like
a
step
in
the
right
direction.
It's
not
going
to
solve
everything
right
like
it's
not
going
to
solve
all
your
security
issues.
So,
like
that's
how
I
I
look
at
this
sort
of
proposal.
G
I
think
the
ability
to
do
this
is
absolutely
an
incremental
improvement
so,
but
I
just
want
to
make
sure
we're
very
clear
on
how
this
is
going
to
impact
the
end
user
right
which
we
haven't.
I
don't
think
that
couple
the
documents
I've
read
have
really
covered
that
in
a
way
that
it's
unique,
it's
clear
to
me
right
sure
and
it's
how
we
design.
B
B
Yeah
I
want
to
speak
to
that
specifically
a
little
bit,
so
I
think
we
can
safely
assume
that
most
developers
are
not
wes
and,
as
a
result,
most
developers
are
just
going
to
click
accept,
accept,
accept
because
that's
how
I
get
my
job
done
and
go
on
to
the
next
thing,
where
this
ends
up
being
valuable
and
providing
some
value
to
that.
You
know
rationally
lazy
developer,
who
is
just
accepting
everything.
B
B
At
some
point
there
is
a
a
cve,
because
there's
a
you
know,
a
module
version
that
that
is
doing
some
bad
thing.
One
of
the
questions
that
always
ends
up
being
really
challenging
to
answer
is:
are
we
actually
vulnerable
to
it?
And
for
how
long
have
we
been
vulnerable
to
it?
You
know,
and
and
in
the
worst
case
like
have
we
been
actually
owned,
not
just
vulnerable,
but
you
know
successfully
attacked.
B
So
that's
and
that's
a
question
that
this
kind
of
ongoing
record
would
would
help
you
answer
right.
So
you
could
say,
like
you
know,.
D
B
We
did
we
install
malice,
malicebot
2000,
and
the
answer
is
yes.
Okay,
but
did
we
give
it
the
permissions
to
run
child
processes?
Yes,
we
did
on
you,
know,
march
13th,
and
then
we
revoked
them
on
march
17th
and
so
like.
Let's
go
look
in
that
timeframe,
so
in
that
case
like
we,
we
have,
we
have
a
record.
We
have
an
artifact
that
can
be
tracked.
It
doesn't
mean
you're,
safe
from
attack.
It
means
that
you
can
recover
more
effectively
from
an
attack
and
that's
you
know,
that's
not
nothing.
That's
actually
pretty
good.
G
B
I
mean
it's
similar
to
the
benefit
of
checking
in
a
package
log
file
right,
if
you're,
if
you're,
deploying
an
application
checking
in
the
lock
file
means
that
later
on
down
the
road.
If
I
find
out
that
there's
some
problem,
I
I
have
even
if
it's
not
easy,
it's
possible
to
like
go
through
and
audit
like
which
dependencies
were
in
use.
Where
and
we've
seen.
This
leveraged
by.
B
You
know
like
the
the
github,
vulnerability
detection
and
other
products
and
and
stuff
from
soda
type
and
jfrog
like
that,
has
actually
provided
some
hooks
for
other
state-of-the-art
security
stuff
to
to
build
up
more
safety.
G
Yeah,
that's
a
great
point
and
I
think
it
would
be
very
useful,
then,
to
start
when
this
feature
is
rolled
out
with
some
sort
of
blog
post
or
great
documentation.
That
says
here
is
the
best
way
to
use
it,
and
why
and
and
very
strongly
recommend
committing
it
to
the
repository
the
output,
whatever
the
artifact
is
because
if
you
don't
the
traceability,
if
it's
not
committed
goes
way
down,
you
know
in
value
and
see
bradley's
face.
G
So
I'm
actually
love
to
hear
what
bradley
thinks
in
this,
because
you
brought
up
some
stuff
that
I
hadn't
thought
about
with
having
it
in
the
same
directory
structure,
which
is
good,
and
I
haven't.
E
Copied
out,
that's
fine,
but
you
you
don't
want
it
in
the
same
directory
structure
itself,
because
often
the
directory
structure
on
containers
and
stuff
is
on
immutable
fs,
and
so
it
could
be
stored
in
git.
That's
fine!
But
when
actually
running
it
a
best
practice
would
be
to
copy
it
somewhere
else
and
use
that.
G
So
like
something
had
file
system
write
access
to
the
policy
file
right,
the
attack
would
be
that
it
changes.
The
policy
file
before
executing
right
is
that
no.
E
G
Okay,
having
click,
I
guess,
having
clarity
on
that
would
be
really
valuable,
because
that
to
me
makes
makes
the
feature
compelling
right
and-
and
that's
going
to
be
very
important
to
to
justify
investment
right
like
if
I'm
going
to
go
to
my
co-workers
at
netflix
and
say:
look
because
I've
been
asking
this
I'm
like
we
got
this
policy
api
shouldn't.
We
should
we
be
using
it
and,
like
the
answer,
has
just
been
well.
G
We
have
a
what
api
like
I
didn't
know
about
that
right,
and
so,
when
I
go
to
them
with
this
story
and
say,
look
I
want
to
help
make
these
applications
more
secure
by
using
this
policy
api.
I
need
to
have
that
answer
right.
Here's
the
best
practices,
here's
what
it
does
for
you
and
here's
how
we're
going
to
roll
it
out
and
to
me
now
that
I
understand
like
the
audibility,
is
really
the
sort
of
core
strength.
G
I
think
I
could
make
that
case
much
better
than
I
could
before
that,
and
so
that's
where
I
would
like
to
see
the
you
know
if
there
is
some
big
concern
about
having
in
the
same
directory
and
if
everybody
has
their
packages,
you
know
with
package.json
at
the
root
then
like.
How
would
I
do
it
correctly
is
like
sort
of
the
story
that
needs
to
be
worked
out
for
this
rollout
to
succeed.
In
my
opinion,.
D
E
A
Okay,
okay,
so
I
just
want
to
be
mindful
of
time
here:
we've
got
about
15
minutes
left
and
I
think
there's
been
some
really
good
discussion
here.
I'm
wondering
what
some
like
next
steps
could
be,
so
we
keep
keep
this
rolling
because
I
I
think
we
there's
some
general
consensus
that
this
is
a
good
idea
to
implement.
E
So
it
sounds
like
the
feedback
was
we
need
to
have
a
written
out
description
of
application,
authors
what's
their
delta
over
time
and
experience
that
needs
to
be
written
up.
We
need
to
write
up
defaults,
expect
expected
and
separately.
E
A
E
Those
were
alternatives
we
could
look
at
grants
are
just
going
to
be
urls,
so
every
node
built
in
actually
lives
at
node,
colon,
fs
or
whatever,
in
policies
and
in
newer
versions
of
node.
That's
true
in
stack
traces
and
the
debugger
as
well.
E
B
We
can
get
that
yeah
broke
all
my
tap
stack
stack,
trace,
munders.
E
Sorry
I
like
it,
it's.
A
List
happen,
though
we
could
like
say
this
is
the
what
potentially
yeah
so
adding
that
I
think
would
also
be
helpful
in
the
rfc
as
well,
apparently
sure
cool,
so
there's
some
some
actions
there.
We
can
also
I'm
not
sure
roy.
I
appreciate
that
you've
been
taking
notes,
I'm
not
sure
if
you
got
those
last
few
things
as
awesome.
A
Okay,
or
so
that
was,
I
was
jordan.
Sorry
I
apologize.
I
was
trying
to
read
chat
at
the
same
time
as
my
brain
to
mouth
is
not
working
right
now,
yeah,
so
maybe
if
we
can
get
some
other
discussion
as
well
like
if
you
have
any
other
feedback,
you
want
to
give
to
this
rc
feel
free
to
add
comments
async,
but
yeah
this.
This
sounds
pretty
good,
something
that
we
can
work
on
in
the
new
year
together.
A
I
want
to
quickly
circle
back
on
there's
a
number
of
discussions
that
haven't
got
much
feedback
to
them.
I
was
hoping
that
maybe
we
could
run
through
in
the
last
sort
of
50
minutes
time
here.
I
could
pull
up
potentially
the
list
that
I
had
and
see
if
we
can
maybe
close
out
some
of
these
or
give
some
add
some
light
to
maybe
answer
some
of
these
at
the
end
here.
C
A
So
everybody
can
see
that
so
yeah.
This
list
is
just
pulled
from
the
discussions
that
we
have
actually
opened
in
the
rfc
repo.
So
I
know
jordan.
I
appreciate
you've
been
pretty
active
in
in
issues
and
and
discussions
lately,
so
this
discussion
number
292
make
known
modules
folder
more
space
efficient
by
having
a
production
flag
to
install
only
the
files
used.
So
I'm
not
sure
jordan,
like
you
obviously
asked
the
question
here,
I'm
not
sure
if
we
can
like
answer
this
title
sums
it
up.
D
Yeah
I
mean
that
sounds
nice,
but
like
if
there
was
a
way
in
javascript
to
statically,
know
all
the
used
files.
Then
I
suspect,
bradley's
policy
stuff
would
also
be
way
easier,
like
in
general,
like
it's
a
hard
problem
to
figure
out
the
dependency
graph.
B
Right
and
also
we
should
we
would
be
listing,
you
know
we
would
be
automatically
listing
the
files
in
the
package
json
files
field
right,
like
that's,
that's
something:
we've
explored
a
few
times
adding
to
npm
init
and
it
turns
out
it
is
really
challenging
to
know
which
files
you're
going
to
need.
A
So
can
we
give
some
feedback
here?
We
generally
think
that
I
don't
think
this
is
something
that
we
can
support
or
will
support.
C
A
G
E
G
We
don't
want
to,
can
I
just
say
I
think
we
don't
want
to
the
point.
Is
we
want
authors
to
be
able
to
ship
what
they
want
as
a
you
know,
needs
change
and
there's
lots
of
times
where
not
where,
where
a
author
might
want
to
ship
a
fat
package
with
seven
versions
and
like
that's
actually
an
intent,
that's
a
feature,
not
a
bug.
That's.
G
B
So
one
one
area
where
this
has
come
up
and
I
just
kind
of
want
to
I'm
sure
it's
probably
news
to
no
one,
but
I
just
kind
of
want
to
throw
it
out
there
in
this
feed.
B
One
thing
that
people
have
objected
to
or
complained
about,
including
in
packages,
is
the
license
and
readme
files,
which
does
end
up
being
pretty
repetitive
and
a
considerable
amount
of
you
know
just
bytes
on
disk.
If
you
install
a
lot
of
packages,
the
downside
of
omitting
the
license
file
from
the
package
is
that
you
know
I
am
not
a
lawyer
and
I'm
not
your
lawyer.
If
I
was
but
like
a
lot
of
licenses
specifically
say
you
must
include
this
license
with
all
distributions
of
the
of
the
code
that
it
covers.
D
Enough
people
have
filed
issues
on
old
packages.
I
maintain
that
don't
have
a
license
file
saying
that
their
legal
team
requires
one
because
the
license
they
say
the
license
requires
one
that
I
think
that
enough
lawyers
believe
that
that's
a
requirement
that
it
doesn't
matter
if
it
actually
is
or
not.
B
For
like
when
I
worked
at
google,
if
there
wasn't
an
explicit
license
file
and
a
repo
on
github,
we
were
not
supposed
to
send
patches
upstream,
and
that
policy
is
a
publicly
available
policy
that
you
can
find
yeah.
So.
D
B
But
as
far
as
like,
even
as
far
as
like,
can
we
make
it
easy
to
default
what
files
you
should
include
in
your
package,
you
know,
if
you
have
a
defined
main,
is
here's
kind
of
the
the
thinking
was
like
you,
you've
defined
a
main
and
maybe
in
you
know,
modern
world
you've
defined
some
specific
exports,
which
is
kind
of,
like
you
know,
main
main
plus
right.
You've
said
these
are
the
things
you
can
require.
B
B
E
Yeah,
I
don't
know
if
it's
ever
been
discussed
before,
but
the
idea
the
only
way
I
could
see
this
feasibly
working
is
if
packages
when
they
are
published,
effectively
listed
multiple
packages
that
they
were
going
to
do
multiple
distributions.
E
So,
like
somebody
mentioned,
you
could
support
seven
different
versions
of
your
package.
Who
knows,
I
think,
maybe
a
recommendation
that
we
could
do
was
would
be
to
tell
people
if
they
want
more
minimal
ones,
they're
going
to
have
to
publish
separate
packages
for
all
those,
because
that's
effectively
the
only
thing
you
could
do
under
the
hood
right
right.
G
This
conversation
because
we
focused
on
the
solution
they
proposed,
so
the
problem
which
I've
actually
run
into
at
my
previous
company.
We
had
to
do
some
configuration
changes
on
our
ci
servers,
because
the
node
modules
had
were
blowing
up
the
inodes.
It
was
literally
just
number
of
files
right
that
was
causing
our
ci
servers
to
to
fail
to
build,
failed
next,
installs
or
whatever
I
think
node
was
complaining
about.
G
For
I
can't
remember
exactly
how
they
do
it
anymore,
but
and
it's
possible
that
future
things
with
like
tank
style
may
actually
be
what
this
person
is
looking
for
in
the
long
run,
and
you
can
still
solve
the
problems
with
the
legal
teams
and
licenses
and
all
that
other
stuff
in
more
creative
ways
than
just
having
like
this
sort
of
explicit
production
file
list
or
static
analysis
to
do
it
so
yeah
and
I
think
you're
yeah
anyway,
I
I
just
I
I
don't
want
to
like
squander.
G
I
don't
want
to
tell
this
person
like
personally,
I
wouldn't
tell
this
person
you
d,
this
isn't
a
real
problem,
we're
not
going
to
solve
it.
I
would
say
something
like
the
way
you're
proposing
we
solve
it
isn't
going
to
work,
but
maybe
you
could
spend
some
time
thinking
about
like
alternate
proposals
that
or
or
maybe
just
even
elaborating
on
the
problem
more
because
it
because
it
is
a
real
problem.
B
B
A
D
A
That
you
know
based
on
this
discussion
a
bit.
This
is
not
something
necessarily
we
think
we
can
solve
for
and
a
recommendation
that
we
might
have
is
you
know
they
could
potentially
like
fork
whatever
package
they
have,
and
only
you
know,
create
a
smaller
package
that
only
contains
you
know,
essentially
production
files.
That's
one
way.
I
guess
the
current
ecosystem
is
solving
for
this
right.
B
D
C
Floated
don't
we
have
another
conversation
about
the
different
types
of
packaged
publications
somewhere.
A
D
G
D
The
only
solution
is
if
npm
supports
multiple
tarballs
with
the
same
package
version,
but
then
there's
the
other
class,
which
is
like.
I
want
to
publish
an
es5
version
and
an
es6
version
and
a
node
15
version
of
my
package,
and
you
know
the
the
solution
to
all
of
those,
I
think,
involves
some
some
design
around
npm
accepting
multiple,
either
multiple
yeah,
pretty
much
multiple
tar
balls.
I
think
on
publish
for
a
package,
and
I
mean.
B
Yeah,
the
state
of
the
art
on
that
is
you,
you
bump
the
major
between
each
of
those
and
you
run
multiple
release.
Trains
like.
D
It's
right
I
mean
that's
the
only
that
is
the
that
different
package
names
or
different
or
or
multiple
release
trains
of
the
same
package.
Are
you
right
the
only
real
ways
of
solving
that?
I
guess
the
other
way
is.
You
just
include
everything
in
a
different
folder
in
the
same
package
right,
but
it's
like
those
are
your
choices.
D
B
Well
and
there's
there's
some
real
hazards
and
caveats
with
doing
that
right
if
you,
because
then
we
basically
get
to
a
spot
where
the
assumption
that
name
at
version
on
a
particular
registry
maps
to
one
definite
thing,
and
it
will
always
be
that
definite
thing
is
like
no
longer
holds
true
right,
then
we
have
like
another
another
element
in
that
vector
that
we
need
to
consider.
D
How
do
you
ensure
that
the
like
you
know,
es5
version
and
the
es6
version
are
actually
just
different
syntax
of
the
same
code,
the
same
logic
right
like
and
really
the
only
way
to
know
that
is
if
the
build
process
is
run
inside
npm
or
something
which
is
not
not
tenable
so
like
there's,
there
is
definitely
a
lot
of
yak
shaving
around
this
that
kind
of
feature
but
like
I
just
don't
think
that
there's
for
for
everything
except
disk
space
which
which,
like
tink
and
yarn
to
solution
and
so
on,
like
I,
I
don't
think,
there's
really
another
viable
solution.
C
Yep,
I
think
at
some
point
even
proposed,
like
a
kind
of
sub
standard
using
just
the
current
registry,
just
formalizing
the
this
way
of
publishing
moda
multiple
turbos
for
this
target.
G
A
Okay,
well
just
to
be
mindful
of
time
here.
I
know
we're
about
a
minute
over
and
appreciate
everybody
jumping
on
here.
I'm
gonna,
you
know,
do
some
wordsmithing
and
and
try
to
make
this.
You
know
sound,
encouraging
and
also
outline
sort
of
everything
we've
discussed.
I
wanted
to
know
again,
I
said
at
the
beginning
the
call
I
want
to
say
it
again.
I
appreciate
everybody
and
your
support
over
this
past
year
and
joining
us
in
these
calls.
A
It's
been
super
helpful
and
I
want
to
continue
it
and
I
think
we've
done
a
lot
of
great
work
and
yeah.
I
want
to
wish
everybody,
you
know
a
happy
new
year
and
and
hopefully,
if
you're
taking
holidays,
you
know
you
have
safe
holidays
wherever
you
are
and
yeah.
I
just
want
to
thank
you
again
for
joining
us,
and
hopefully
we
can
keep
the
discussion
going
for
the
next
little
while
we'll
be
back
in
the
new
year
january,
6,
20,
21,
so
yeah.