►
From YouTube: 2020-12-15-Package Maintenance Team meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
welcome
to
the
node.js
package
maintenance
team
meeting
for
december
15th
2020.
we'll
follow
the
agenda
that
was
tagged
in
the
issue
in
the
repo
which
was
issue
number
437.
C
C
D
D
It
so,
okay,
where
is
that
that
process
is
it
in
in
the
ring.
A
A
Okay,
if
not
we'll
move
on
to
the
first
one,
so
the
first
one
is
suggested
list
of
modules
to
help
get
support
info
into
that
one.
I'd
added
a
pr
to
add
to
the
node
add-on
api
repo
that
I'm
just
double
checking.
Yes,
it's
merged,
so
that'll
actually
go
out
and
then
the
release
which
is
coming
in
the
next
few
days.
A
Anything
more
to
discuss
on
that
one.
Before
we
move
on.
F
E
It
was
good,
but
yes,
I
can
definitely
push
it.
I
will
add
that
to
my
to-do
list
for
this
week,
I'll
make
sure
that
that
gets
done,
but
I'm
pretty
sure
it
was
pretty
much
complete
for
the
end
for
an
initial
pass.
Anyway,
I
think
I
was
just
trying
to
write
tests,
which
was
me
being
overly
particular
so.
A
Yeah,
I
think
we
just
we
discussed
it.
This
I
can
see
was
14
days
ago.
So
in
the
last
meeting
we
talked
about
it
and
I
just
added
the
comment
be
good
to
like
just
get
what
we
got
there
out
there
and
then
other
people
could
contribute
too
so
completely
agree
I'll.
I
will
I'll
get
right
on
that
sounds
good.
Okay.
The
next
one,
then
is
suggest
ignoring
a
vulnerability
by
the
package
maintainer.
This
is
386..
F
E
F
Link,
okay,
maybe
just
if
we
can
resurface
the
link,
I
don't
think
I've
bookmarked
it
so.
F
Yeah
I'll
give
it
once
over
and
then
maybe
we
can
like
make
a
action
to
also
try
to
get
by
the
end
of
the
week.
Just
like
get
that
out,
because
I
know
that
we
were
you
and
I
were
poised
to
to
champion
that
collaboration
space.
So
my
end
of
year
is
at
the
end
of.
F
Of
this
week,
so
any
any
to-do's
should
get
done
by
friday.
So
thanks
thanks
wes,
that's.
A
A
Okay,
got
that
one
so
on
to
the
next
one,
then,
which
is
the
next
steps
unless
yeah,
I
guess
anything.
One.
A
A
A
So
we
did
do
a
blog,
probably
needs
to
to
sort
of
revisit
that
again
at
some
point,
once
we
we
do
a
little
bit
more
progress
on
getting
things
into
modules,
blog
on
adding
a
tool
to
your
ci
aprs
to
modules
that
information
we
kind
of
have
that
issue
to
track
that
tool
to
scan
dependencies
and
reports
on
support
information.
A
I
think
that
was
intended
to
be
the
more
sophisticated
one.
So
that's
probably
a
little
bit
early
still
yeah,
that's
what
I
was
going
to
ask
is.
E
E
Update
we
just
had
update
the
tool
to
to
support
the
new
structure,
which
we
did.
I
think
before.
H
A
Or
package
dependencies,
so
I'm
adding
one
with
a
check
mark
above
and
then
I
will,
and
here
let
me
just
I'll
share
my
screen,
so
you
can
see.
If
that's
what
looks
looks
right.
So
I've
added
this
one,
which
was
like
middle
command
and
support
support
tool
to
show
support
info
for
package
dependencies,
and
then
this
one
is
to
and
just
kind
of
provide
more
comprehensive.
A
D
A
A
B
F
This
is
something
that
we
could
show
on
package
pages
on,
like
mpmjs.com
as
well,
so
I
know
that
the
the
conversation
has
been
around
bundle
phobia
supporting
us
right,
but
this
is
potentially
an
ask
that
we
could
actually
bring
to
the
npm
feedback
repo
like
even
if
it's
just
a
pro
proposal
for
hey.
Can
you
support
this
kind
of
like
metadata
or
this
meta
like
information?
F
I
think
it
would
be
a
good
good
exercise
to
see
if
we
can
push
it
through.
That
way.
A
F
A
A
F
Yeah,
so
that's
that's
information.
Definitely
that
I
think
is
helpful,
similar
to
like
licensing
information.
If
the
support
information
is
is
is
privileged
in
some
way
on,
the
website
would
also
be
great.
Okay,.
F
It's
it's
a
lot
lighter
than
that.
So,
like
the
the
feedback
topic
essentially
in
the
mpm
feedback
repo-
and
you
can
start
the
discussion
there
and
then
we've
been
doing
a
weekly
trashing
of
that
okay,
the
product
managers
and
engineer
managers
have
been
joining
those
calls.
So
getting
that
on
our
roadmapper
would
be
good.
A
Okay,
is
that
something
you
know
you
want
to
do
you
want
me
to
do.
F
It
might
be
better
if
it
comes
from
somebody
outside
of
the
org.
Just
like
shows
actual
that
there's
an
interest
for
that.
A
Absolutely
yeah,
I
know
I
can
go
ahead
and
do
that
because
that
actually
would
be
very
helpful.
I
think
in
terms
of
like
people
would
see
that
and
go.
I
wonder
what
that
is
right
and
I
think
it
would
be
it's
kind
of
help.
The
chicken
and
the
egg
thing
right,
because
people
would
wonder.
Oh
it's
shown
there.
Maybe
I
should
include
it
right.
E
Okay,
two
things:
one
jordan
is
waiting
to
be
promoted,
but
also
I'm
wondering
create
a
url
like
those
badges,
I
think
are
just
bajin,
I
think,
is
the
name
of
it.
Is
there
a
reason
why
we
would
need
something
different
than
just
that?
E
So
maybe
it
just
needs
to
be
like
those
are
not
something
I
made.
I
just
use
the
I
think,
which
I
think
is
a
fairly
active.
Can
you
remember
stifle,
I
think,
manages
that
I
think
that's
the
handle,
I'm
not
sure
of
their
real,
their
real
name,
but
I
mean
they
just
have
a
little
api
and
you
just
put
what
you
want
the
text
to
be
in
the
url
and
it
generates
the
image
and
that's
what's
using
there.
So
I'm
wondering
if
maybe
we
just
remove
that.
I
E
A
A
Okay,
now
that
that's
good
couple
good
concrete
things
to
to
do
as
a
next
step,
anything
more
we
want
to
discuss
on
this.
A
A
I
E
Like
an
amazing
job
this
year
I
was
wondering,
if
maybe
it
would
be
worth
I
don't
know,
doing
a
small
blog
post
just
about
like,
like
a
year
in
review
kind
of
thing
or
something
I
I
just
feel
like
the
the
teams
and
working
groups
all
sort
of
have
their
disparate.
E
You
know
things
going
on
but,
like
I
haven't
seen
anything
that
sort
of
brings
together
like
a
here's
thing,
here's
what
you
know
all
of
this.
All
these
people
participated.
Here's
what
they
did
all
this
great
work.
I
feel
like
this
team
would
be.
We
have
just
a
lot
of
things
happened.
Maybe
some
others
don't
have
as
much,
but
you
know
I
think
it'd
be
interesting
to
consider
like
because
because
as
an
outreach
thing,
it
would
also
be
a
pretty
important
thing
like
I
know
somebody
came
to
the
openjs
slack.
E
E
A
Right,
we
don't
just
chat,
we
actually
yeah.
No,
I
think
that's
a
great
idea,
like
the
napi
team,
recently
put
out
a
hey.
You
know:
node
add-on
api
just
hit
3
million
in
download
sort
of
a
retrospective
like
that
too,
and
talked
about
like
the
things
that
happened
in
the
past
year.
So
I
I
think
that,
like
this
is
very
much
in
that
same
vein
and
definitely
think
it's
a
good
idea
to
break
what
we
did,
but
also
you
know
get
out
there
to
see.
A
You
know
hopefully
interest
other
people
to
say:
hey
yeah,
that's
that's
cool,
maybe
I'll,
try
and
help
out
too
so
do
we?
How
do
we
want
to
like,
in
terms
of
of
doing
that?
Do
we
want
to
open
an
issue
and
do
that
early
in
the
new
year
or,
what's
kind
of
you
have
any
thoughts?
I
can.
E
I
can
open
an
issue
and
just
sort
of
bullet
point
the
idea
since
I
brought
it
up
and
we
can
see
you
know
what
we
can
maybe
just
start
a
list
of
things.
We'd
want
to
highlight
and
then-
and
maybe
then
you
know
once
we
have-
that
we
can
go
off
and
write
actual
pros
for
it.
A
It's
pretty
high
bar
yeah,
I
know,
but
I
will
say
you
know.
I
think
that
it's
a
little
bit
what
west
was
getting
at.
That
too,
is
like
we
should
be.
You
know
thankful
to
everybody
on
the
team
for
all
the
work
they've
done
over
the
last
year
and
the
contributions,
and
it's
definitely
a
great
group
of
people
to
come,
and
you
know,
share
the
ideas
and
work
on
different
things
and
yeah.
It's
great
it'll
be
great
to
look
back
because
I
think
we'll
be
surprised
actually
in
all
the
different
things.
A
E
A
A
Okay,
you
know,
if
that's
it
we'll
give
people
back
time,
and
you
know
I
hope
everybody
has
a
has
a
time
to
take
a
break
and
and
relax
a
little
bit
and
we'll
regroup
in
january
and
and
keep
on
going
happy
new
year.
Yep
thanks.
F
A
J
E
J
K
For
pointing
that
out,
I
was
just
just
doing
that,
but
I
will
delete
it
from
the
calendar
and
just
to
be
clear.
Are
we
happy
with
the
current
meeting
cadences
like
in
terms
of
schedules
and
frequencies
and
stuff,
or
is
that
something
we
want
to
adjust?
I
I
don't
I'm
not
necessarily
unhappy
with
it.
I'm
just
it's.
A
A
Definitely,
it's
definitely
lighter
yeah
that
one
I
guess
that
would
be.
We
could
certainly
consider.
C
A
Yeah,
I
I
you
know,
maybe
jordan,
any
chance.
You'd
volunteer
to
open
an
issue
to
say,
let's
review
our
time
zones
like
our
time
should,
basically,
you
know
give
that
a
maybe
it
can
be
like
fine,
never
make
you
know
can
occasionally
make
or
something
like
that
right
and
based
on
that,
we
can
see.
If
it's
you
know,
we
can
try.
B
F
Sounds
good,
so
one
quick
note
bradley
did
you
want
to
bring
up?
I
know
you
created
an
issue
for
and
wanted
to
bring.
I
think
up
in
the
agenda
the
the
issue
of
permissions
in
texas
json.
I
think.
L
L
Permission
wise
when
you
install
their
package
not
what's
being
granted
just
so
a
package
manager
could
say:
oh
you're,
installing
event
stream
and
then
you
would
see,
for
example,
why
would
it
need
access
to
http
and
then
the
package
manager,
whenever
it
gets
approved
or
denied,
could
modify
the
policy
file
and
use
the
existing
policy
mechanism
to
grant
or
deny
access
to
things?
So
that's
it.
E
A
A
I
guess
I'll
go
one
one
question
I
had
thought
that
I
had
like.
I
just
briefly
looked
at
it.
One
thought
I
I
wondered
is,
and
somebody
mentioned
this
space
right
fault
space
like
I
almost
like
we're
talking
about
how
we
can
manage
what's
in
package
jason
almost
right-
and
I
I
I
wonder
if,
like
that's
a
broader
group
than
this
group,
or
is
it
that
you
know
we
should
just
continue
to
treat
them
one
off.
I
I
don't
really
know.
F
I
think
this
is
like
a
tooling
issue
like
like
this
is,
like
I
think
and
and
badly
you
can
sort
of
like
clarify
and
scope
the
discussion.
I
think
this
is
you
know
a
tooling
issue
that,
like
you
know
yes,
maybe
out
of
this,
we
say:
there's
like
some
sort
of
standard
way
of
defining
this,
but
then,
like
the
only
way,
this
gets
adoption
or
support
is
once
the
tools
actually
like,
take
that
and
run
with
it
right.
F
So
I
I
think
the
initial
discussion
was
brought
up
in
in
sort
of
like
the
npm
rfc
calls
that
we
had.
E
F
Then
I
said
I
I
said:
hey,
let's
direct
it
over
here
and
have
have
this
discussion
here
about
what
that
looks
like
and
then
and
then
we
can
look
at
that
as
hey
like
how
are
we
going
to
support
it
in
npm
or
somewhere
else
like
other
package
managers?
Right
so
is
that
is
that
right
bradley?
Is
that
kind
of
how
you
how
you
look
at
it?
It's
like
the
only.
L
Kind
of
yes,
the
the
key
point,
is
kind
of
hinted
at
in
what
you
just
said.
This
isn't
something
that'll
actually
be
used
by
node
itself.
It's
kind
of
an
integration
with
other
tools.
L
Noda
already
has
the
policy
mechanism
and
it's
getting
more
stuff
added
to
it,
but
there's
no
way
for
tools
to
integrate
with
a
policy
mechanism,
so
you
have
to
do
it
yourself
or
with
customized
tooling,
like
we
do,
and
so
we
need
a
way
for
package
authors
to
reasonably
state
and
show
to
people
installing
their
packages.
What
permissions
are
being
granted
and
well
requested
npmr,
the
installer
itself
would
grant
the
permissions.
A
A
Should
the
package
maintenance
team
become
like
the
the
the
place
we
discuss
every
time
we
want
to
add
something
to
package
jason
or
the
metadata
that
goes
along
along
with
the
package?
Maybe
the
answer
is
yes
or
is
like
there
a
broader
group
that
we
should
involve
under
like
a
collaboration
space,
or
you
know
not
not
to
derail
this
discussion.
We
should
probably
just
have
this
discussion
here,
but
that
was
more.
E
I
E
I
think
that
ownership
of
parts
of
package.json
has
precedence
for
being
distributed
today,
and
I
don't
think
that's
a
bad
thing
in
this
case.
This
to
me
sounds-
and
this
is
a
very
brief
read
like
just
what
I
have
since
you
started
talking
in
the
link.
I
posted
sounds
to
me
really
like
an
npm
feature
or
a
yarn
feature
or
a
whatever.
You
know,
which
to
me
means
that
we
don't
really
have,
maybe
maybe
a
say,
is
not
really
the
right
thing.
E
K
L
A
E
E
K
Invokes
install
scripts
so
if
npm
is
going
to
restrict
the
permissions
of
like
or
are
you
like?
Are
you
somehow
envisioning
that,
like
it
will
install
a
package,
use
that
package's
declared
permissions,
modify
the
policy
config
for
each
package
as
it's
installed,
so
that
the
install
scripts
that
npm
then
executes,
obey
those
permissions,
or
is
it
something
more
like
like?
How
exactly
would
that
interplay
work.
L
K
I
guess
I
guess
when
I'm
I'm
like,
I
can
understand,
there
seems
to
be
a
couple
different
use
cases
here.
Right
like
I
can
understand
the
one
about
for
the
runtime
usage
of
my
package.
I
want
to
declare
the
permissions
I
need
so
that
it's
easier
for
consumers
to
say.
Yes,
you
should
have
that
permission
when
they're
opting
into
locking
things
down.
In
other
words,
you
know
making
sure
the
permissions
I
I
essentially
declare
I
need
match
what
they
expect.
K
I
should
need
so
that
seems
useful,
and-
and
just
it's
really
just
for
that,
it
seems
like
it's
really
just
picking
a
field
name
and
a
schema
for
package.json
that,
like
no
everyone
agrees
to
to
not
mess
with
and
then
like-
and
this,
I
think,
is
the
right
place
for
that.
K
That
would
seem
more
appropriate
in
the
npm
rfc
process
to
me
just
to
work
out
the
semantics
and
then
when
I
would,
when
I,
when
those
are
worked
out
and
npm
in
particular,
has
said
that,
yes,
this
is
feasible
and
makes
sense
and
like
practical,
then
it
seems
also
reasonable
to
come
back
to
this
group
to
make
sure
that
you
know
the
other
package
managers
are.
K
You
know
which
you
can
ping
them
outside
of
this
group,
of
course,
but,
like
just
kind
of
this
group,
seems
to
me
like
the
a
common
stakeholder
location
for
that
sort
of
thing,
but
but
the
way
install
scripts
are
invoked
is
so
sensitive
to
the
cli
itself
that
I
think
you'd
have
to
have
extensive
discussion
in
that
arena
with
some
of
the
folks
on
this
call,
you
know
before
we
could
even
have
a
productive
discussion
about
it,
because
those
are
like
two
vastly
different
use.
K
K
Yeah
I
mean
it's
fine
if,
like
the
scheme
is
the
same
or
something
but
but
I
would,
those
would
need
to
be
separable
because
there's
plenty
of
packages
that
need
no
permissions
at
runtime
and
vast
permissions
at
install
time
and
there's
plenty
of
packages
that
need
no
permissions
at
install
time
and
vast
permissions
at
runtime
and
everything
in
between
so
like
those
those
would
have
to
be
just
like
distinct
configs.
Even
if
it's
the
same
schema.
L
Not
exactly,
but
they
are
different
conditions.
Yes,.
K
Well
right
like,
but
but
I
guess
what
I
mean
is
as
a
package
author,
I
absolutely
would
need
to
be
able
to
specify
those
differently
and
it
ideally
would
be
convenient
for
me
to
do
so,
and
I
think
that
I
don't
have
any
packages
that
post
install
scripts,
of
course,
but
like
the
ones
that
I
have
seen
that
are
reasonable,
like
definitely
typically
need
different
permissions
than
the
runtime
code
does.
J
K
K
Not
for
locking
down
for
a
lot
I
mean
the
use
case
for
locking
down
permissions.
Is
I'm
paranoid
about
different
places
right,
but
it's
I'm
saying
that
the
the
actual
tooling.
K
Do
stuff
in
post
install
is
a
vastly
different
use
case
than
the
ability
to
do
stuff
at
run
time
right
and
so
the
like,
for
example,
it
will
be
probably
highly
disruptive
if
you
lock
everything
down
by
default
at
runtime
until
somebody
declares
they
need
it
and
you
explicitly
grant
it.
I
know
you
can
opt
into
doing
that,
but,
like
that
is
likely
to
be
a
very
painful
road.
K
However,
if
you
default
to
no
permissions
on
post
install
scripts,
that
is
not
going
to
be
that
painful
you'll
have
like
three
things
or
something
at
most
that
you
need
to
like
explicitly
say:
yeah,
that's
cool,
that's
cool,
that's
cool
and
then
you're
done
so
like
the
I.
I
think
that,
and
also
I
think,
that
most
users
might
not
care
about
locking
down
runtime
to
the
same
level
that
they
actually
care
about
post,
install
scripts,
because
the
runtime
stuff,
like
doesn't
already
doesn't
have
access
to
a
lot
of
important
things
that
the
install
scripts
might.
A
May
be
locked
down
in
a
different
way
like
they're
running
in
a
docker
container
or
somewhere
else
and
yeah.
So
I
think
from
jordan's
comments
like
I
could
easily
imagine
that
you'd
want
two
sets,
one
which
is
like
here's
the
permissions
I
need
for
post,
install
and
here's
the
permissions.
I
need
at
runtime
because
those
could
be
like
completely
different.
A
K
K
M
I
think
just
what
jordan
was
saying
is
the
way
in
which
you
arrive
at
what
needs
to
be
secured
might
be
harder
in
different
contexts.
I
think
the
use
cases
are
the
same.
The
context
is
different
now
and
that
was
kind
of
my
thought
is.
I
could
see
you
know
the
worst
case
scenario.
Is
you
have
like
a
a
key
in
package.json
that
says
you
know
permissions
npm,
permissions,
node
and
yeah.
M
The
schemas
might
be
the
same,
but
the
the
work
to
do
the
threat,
modeling
or
whatever
might
be
different,
but
does
that
mean
that
if
we
kind
of
to
jordan's
point
earlier,
if
we
can
tease
out
what
the
schema
looks
like
if
it
can
be
a
shared
schema,
even
if
the
implementation
is
different,
does
that
mean
we
could
at
least
parallelize
this?
Because
post-install
is
its
own
can
of
worms?
M
K
I
I
think
that
that
when
you
have
a
discussion
about
security
with
security,
folks,
the
it
usually
ends
up
slippery
sloping.
Its
way
to
this
is
all
equally
bad
and
it's
all
equal
security
and
everyone
cares
equally
about
securing
these
things.
But
in
practice
that's
not
the
case.
People
don't
care
or
the
same
way
about
con
securing
dev
depths
as
they
do
runtime
depths.
They
have
different
concerns
about
that.
K
Even
if
the
attack
factors
are
end
up
being
the
same
company
right
no
and
I'm
sure
there
are-
there
exist
plenty
of
companies,
yours
and
my
own-
that
are
paranoid
to
a
level
where
they
would
treat
them
the
same.
But
these
features
shouldn't
be
designed
just
for
paranoid
enterprise
companies
with
hired
security
teams.
E
Yeah,
so
I
think
these
are
all
great
points.
I
think
it
makes
it
very
clear
that
we
need
a
really
strong,
deep
dive
on
this,
and
I
do
think
that,
even
if
we
might
be
the
right
group
to
have
the,
how
does
this
look
when
you,
when
a
package
author
defines
it
in
package.json,
I
think
until
we
have
nailed
down
what
npm
is
supposed
to
do,
I
don't
think
we
can
have
the
full
productive
conversation
around
this.
E
I
think
we
need
those
all
of
those
little
nitty
gritty
details
in
some
fashion,
maybe
not
perfectly
figured
out,
but
at
least
like
you
know
here
are
the
the
goals
that
the
you
know.
These
tools
need
to
be
able
to
achieve.
We
want
to
be
able
to
secure
permissions
in
posts
and
telescopes.
We
want
to
be
able
to
secure
permissions
at
run
time.
We
want
those
things
to
be
defined
by
package
maintainers
and
then
for
users
of
the
tooling
to
look
at
it
and
approve
it
and
then
have
it
modify
this.
E
You
know
file
in
this
location
like
until
we
have
sort
of
what
I
see
as
an
npm
rfc.
That
really
outlines
the
behavior
that
we're
hoping
to
achieve.
I
don't
think
we
can
come
up
with
the
right
schema.
I
think
we
can
have
a
bunch
of
discussions
about
what
might
fit
in,
but
I
think
we
really
need
a,
and
maybe
this
actually
needs
just
a
proof
of
concept
tool
somewhere.
That
says,
like
look
here.
L
E
So
I,
like
you
know,
I
think,
the
process
that
happened
with
zb's
audit
resolver
is
sort
of
similar.
He,
you
know
built
a
proof
of
concept
tool
brought
it
to
npm.
E
Npm
has
we've
had
a
bunch
of
discussions
over
there,
and
then
we've
talked
about
what
that
looks
like
in
the
collaboration
space
discussion
and
that's
where,
like
we
would
nail
down
the
schema
right,
but
it
took
those
sort
of
preliminary
steps
for
us
all
to
get
on
the
same
page
of
what
are
the
requirements
and
what
are
the
needs
right
and
I
think
that's
where
I'm
a
little
bit
lacking
here
from
this
discussion
and
reading
the
the
thread
is
like
I
I
you
know,
I
think,
there's
just
a
lot
of
missing
pieces
that
we
haven't
fleshed
out
for
everybody
to
get
on
the
same
page.
E
K
C
C
I'd
just
like
to
take
a
step
back
very
quickly,
so
the
policy
file
it
needs
to
live
outside,
of
your
application
directory,
right
and
and
for
engineering
yeah
yeah,
which
means
that.
H
Ago
that
I
thought
yes.
L
Yes,
so
what
you're
trying
to
say
a
lot
of
people
when
they
generate
artifacts
for
things
through
their
ci
cd
pipeline,
they
actually
only
generate
a
single
directory
and
it's
what
has
their
package
json
and
things
contained
within
it.
L
So
in
general,
if
you're
going
to
be
using
policies-
and
you
want
to
have
different
file
permissions,
so
people
can't
manipulate
this
policy
file.
You
put
it
outside
that
directory,
which
means
that
it's
a
little
bit
of
a
different
workflow
than
a
lot
of
people
use
in
their
ci
cd
as
it
exists
today.
C
Why
does
npm
need
to
be
at
the
heart
of
it?
Because
really,
as
someone
I
think,
was
right,
we
could
we
could
build
a
a
tool
and
trial
this
and-
and
you
know,
get
that
tool
into
into
the
tool
chain
by
a
pre-installed
scripts
or
something
similar.
But
what
npm
really
needs
to
do?
The
only
thing
it
needs
to
do
is
to
pass
the
correct
policy
file
when
it
runs
the
preinstall
post,
install
scripts
and
then
generating
that
policy
file,
keeping
it
up
to
date,
based
on.
C
What's
in
your
dependency
tree,
that's
kind
of
a
different
concern
right:
it's
not
directly
the
how
how
how
that
such
a
tool
would
be
integrated
with
npm
and
what
kind
of
aux
it
would
have.
That's
that's
a
bit
of
a
broader
discussion
and
maybe
for
for
npm
to
consider,
but
as
it
it,
it
could
very
well
be
just
the
tool
that
lives
on
its
own.
In
a
similar
vein,
the
scripting,
whether
you
want
to
run
the
scripts
on
install,
is
a
is
a
is
a
an
orthogonal
concern
right.
C
I
do
have
the
allow
scripts
module,
which
basically
executes
just
executes
the
pre-install
post-install
script,
so
that
that
could
be
outside
of
your
install
lifecycle
altogether
right.
So
getting
the
wider
adoption
for
that
and
pushing
that
out
into
general
public
for
folks
who
may
not
even
be
aware
that
you
know
they
could
use
policies
for
that.
B
A
B
C
But
the
sound
is
coming
out
the
wrong
speaker
now,
bluetooth,
yeah
and
I'm
plugged
in
with
the
cable,
and
it
doesn't
help
yeah.
So
so
I
think,
there's
there's
a
lot
of
different
tools
that
can
be
built
and
that
they
can
then
be
combined
into
a
tool
chain
and
then,
in
terms
of
package
managers,
it's
up
to
them
to
decide
whether
they
want
to
take
these
tools
in
or
build
something
else
and
what
kind
of
an
experience
they
want
to
provide.
C
C
Of
a
manifest
of
of
of
you
know
what
the
package
and
each
folder
is,
the
scope.
I
see
a
suggestion
for
a
scope,
I
guess
that's
a
folder
or
a
file,
or
maybe
a
glob
each
each
each
each
package
can
declare
what
they
want.
You.
You
may
then
want
another
tool
which
syncs
that
up
with
you,
know
scans
the
folder
and
sees
that
you
know
these
permissions
are
actually
declared
and
all
of
that
to
generate
that
policy
and
to
generate
the
permissions
manifest.
K
So
so,
in
terms
of
the
development
workflow,
I
agree
with
you
dominicus,
but
the
point
I've
been
trying
that
I've
been
planning
to
make
anyway
was
bradley
that,
when
you're
building
a
feature
in
node
that
only
like
enterprise
customers
or
people
that
are
doing
instrumentation
or
something
you
know
like
sort
of
niche
use
cases
that
are
still
really
important.
K
It's
fine
right.
You
can
just
build
it
because
people
who
don't
need
it
just
won't
care,
and
I
feel,
like
that's
policies,
has
been
developed
in
that
vein.
However,
if
it's
gonna
require
adoption
from
package
authors
in
the
ecosystem,
it
is
going
to
require
that
the
feature
be
widely
accessible,
otherwise
nobody's
going
to
care
about
serving
it.
K
For
example,
ibm
has
this
some
arc
some
architecture,
some
aix
thing
that
some
node
mtm
packages
broke
on
and
now
I
it
seems
like
they've,
been
using
the
mechanical
turk
or
something
to
hire
random
people
to
add
the
aix
architecture,
to
the
travis
config
in
a
ton
of
random
open
source
packages
and
the
response
that
I've,
given
everyone
on
all
when
it's
all
been
my
packages
has
been.
K
This
doesn't
behave
differently
on
different
architectures.
Why
would
I
care
about
testing
on
making
my
testing
slower
and
adding
this
and
there's?
You
know
they
have
not
done
a
compelling
job
of
convincing
me
why
I
should
care
so.
Similarly,
if
I
think
that
policies
has
to
be
something
in
order
for
package
authors
to
want
to
add
a
permissions
manifest
package,
authors
are
going
to
have
to
be
motivated
to
support
using
policies
and
they're
only
going
to
do
that.
K
So
I
think
it
is
important
to
keep
that
in
mind
when
designing
all
of
these
things,
to
make
sure
that
it
is
capable
of
receiving
adoption
eventually,
even
though,
as
dominicus
says
like
we
can
there's
lots
of
ways
to
develop
things
out
and
flesh
out
proofs
of
concept
or
whatever
that
don't
require
shipping
things
in
node
or
npm,
yet
or
at
least
in
npm.
I
think
that
it's
it's
going
to
be
pretty
important,
that
it
be
widely
marketable.
L
K
L
So
the
goal
of
policies
is
exactly
like
you're
stating
we've
added,
roughly
the
equivalent
of
allow,
read
and
allow
right
through
scoping
mechanisms
and
stuff
like
that,
you
can
hand
write
a
policy
file,
it's
not
too
difficult.
If
the
claim
is
that
it
was
built
as
enterprise
and
there
we,
therefore
we
shouldn't
approach
it.
L
Just
like
it
sounds
like
your
response
to
the
aix
architecture,
then
it
seems
like
I
can
just
go
a
different
direction,
which
seems
fine,
but
if
the
claim
is
that
we
need
to
find
a
way
for
users
to
use
it,
it
would
be
good
to
get
feedback
on
why
it's
not
usable
before
making
those
claims.
K
K
Yes,
that
doesn't
necessarily
make
it
unusable
and
it
is
policy
seems
to
have
like,
as
you
said,
your
company
cares
about
it.
K
I
think
there
are
companies
that
do,
but
I
I
it
has
not
seemed
from
my
point
of
view
that
policies
was
widely
workshopped
or
and
widely
like
to
the
non-enterprise
community,
nor,
like
the
it
seemed
like
it,
sort
of
has
shipped
in
versions
of
node
relatively
quietly,
and
I'm
sure
you
that
I'm
not
trying
to
you
know
I'm
sure
you've
gotten
lots
of
feedback,
I'm
not
trying
to
suggest
it's
inappropriate
to
be
there
or
anything
like
that.
K
It's
just,
it
seems
to
me,
like
a
feature
built
with
your
use
cases
in
mind
and.
K
Right
so
so
I
think
it.
Let
me
restate,
then
I
think
that
the
goal
ideally
should
be
that
the
ecosystem
wants
to
use
policies,
because
it
makes
everything
more
secure,
meaning
that
they
want
to
that
user.
That
npm
users
want
to
in
their
applications,
define
these
permissions
and
use
the
mechanisms
that
you
that
you've
begun
to
build
to
prevent
all
of
the
security
issues
you've
referenced,
and
in
order
to
do
that,
it
requires
adoption
from
package
authors.
L
So
not
necessarily
so
if
we
look
at
a
variety
of
things
like
how
dino
does
permissions
and
how
headless
browsers
do
permissions,
instead,
they
take
the
opposite
approach
of
denying
permissions
by
default,
and
so,
if
your
default
is
denial
and
the
package
author
does
need
to
whitelist
it,
just
like
you
mentioned
for
aix
to
run
in
restrict
mode
whatever
we
want
to
call
it
right,
there's
there's
two
driving
forces.
L
I
don't
think
package
authors
ever
want
to
write
extra
metadata,
that's
not
appealing,
and
I
don't
think
they
want
to
try
to
iterate
the
permissions
that
they
have.
That's
not
appealing
either,
and
so
I
don't
think
it'll
ever
be
appealing
honestly.
That's
not
what
this
feature
is
for
it's
for
the
people
who
are
running
your
command
line,
it's
not
for
the
package.
Authors.
A
So
I
I
think,
we're
running
out
of
time,
there's
a
few
other
people
with
their
hands
up.
But
I
don't
know
wes
owen.
E
Well,
I
I
yeah
my
my
points,
I
think
I
would
say
if
we
are
going
to
go
down
this
route,
we
need
to
really
strongly
consider
the
points
jordan
made
first,
so
that
is
probably
the
more
important
conversation
to
have
and
bradley.
As
you
were
saying,
it
might
not
ever
be
appealing,
and
if
that
is
the
case,
that's
fine.
E
That
means
again,
I
think
it
comes
back
to
this
group
providing
feedback
and
waiting
until
there
is
something
actionable
for
this
group
specifically
because
I
I
think,
as
this
conversat
it
reinforced
what
I
was
trying
to
say
earlier,
which
is
as
this
conversation
has
gone
on,
we've
gone
in
a
bit
of
circles
and
we
don't.
E
I
don't
think
we
have
enough
meat
here
to
make
a
what
is
an
actionable
next
step
from
like
the
technical
standpoint,
I
think
we
can
make
a
recommendation
and
say
you
know
going
to
npm
with
a
rfc
going
to
you
know,
have
it
building
out
a
more
robust
proof
of
concept.
I
think
would
be
great
next
steps
for
me
personally
to
understand
the
impact,
because
I
don't
think
it
has
answered
the
very
important
question
that
jordan
was
posing,
which
is.
E
Why
should
I,
as
a
package
maintainer,
do
this
right,
which
is
the
question
that
needs
to
be
answered
before
this
group
can
really
have
any
help,
because
we
would
then
come
up
with
a
spec
that
is
appealing
to
package
authors
right.
But
if
we,
if
we
don't
think
that
the
fundamental
feature
is
appealing
just
yet
we.
I
think
we
need
that
before
we
can
do
the
next
steps
that
this
group
is
specifically
chartered
and
capable
of
of
discussing.
M
I
would
owen
last
year
just
because
I
wanted
to
key
in
on
that,
and
I
think
what
bradley,
just
like
the
last
thing
that
he
said
about
who
this
is.
I
think
there
is
a
great
question
to
be
asked
about.
Who
is
this
proposal
for?
Is
it
for
application,
slash,
package,
consumers
or
package
authors?
M
I
was
under
the
impression
that
this
was,
and
maybe
that's
what
node
policy
is,
and
so
I
was
mistaken,
but
I
was
under
the
impression
that
what
this
was
being
proposing
is
like,
like
in
adino,
you
can
lock
down
your
app
at
runtime
and
maybe
potentially
npm
time
to
say,
I'm
only
going
to
allow
fs,
that's
it,
and
I
put
that
my
package
json
or
policy
config,
and
then,
if
I
want
to
go
that
strict
in
that
packages,
you
could
go
to
the
so
you
could
to
find
that
at
your
app
and
then,
depending
on
how
strict
the
policy
goes,
packages
could
effectively
whitelist
their
way
in
through
their
own,
manifest
to
your
application.
M
So,
and
so
I
don't
know,
if
that's
what
known
policy
was
for,
but
I
think
I
see
the
value
here
in
applications
being
able
to
say,
I
only
want
my
application
to
access
these
particular
features
of
node
and
maybe
like
by
default.
Warn
me
if
a
package
is
exceeding
its
scope
or
deny
if
it's
exceeding
its
scope
and
then
it
sound.
I
thought
that
maybe
the
conversation
was
like.
So
how
do
we
meet
the
more
stricter
threshold
of
enterprise?
M
A
So
we
are,
we
are
at
time.
It
sounds
like
we
still
got
lots
more
to
discuss,
so
you
know,
I
think
we
can
keep
it
on
the
agenda
for
the
next
time.
If
you've
tagged
it
for
the
agenda,
it
will
automatically
show
up.
L
E
L
K
K
Bradley
all
I've
been
saying
is
that
I
think
that
if
your
goal
is
that
you
want
package
authors
to
be
able
to
document
things
in
their
own
packages,
for
the
sake
of
policies
to
consume
them,
then
like
it
needs
to
be
the
the
value
prop
needs
to
be
clear
and
that
I
think,
would
be
appropriate
for
this
group.
If
that
is
not
a
direction
you
want
to
go
in,
then
there's
definitely.
L
That's
what
this
group
wants
just
from
what
I've
been
hearing,
so
I'm
not
really
eager
to
like
slug
through
many
meetings
of
trying
to
convince
myself
that
this
is
the
right
place.
A
Yeah
I
was
going
to
try
and
add
that
I
mean
personally,
I
don't
think
we
have
to
the
the
main
thing
that
people
wanted
to
understand
a
bit
better
was
the
use
cases.
I
didn't
think
that
necessarily
needed
to
be
like
implemented
in
a
tool
but
just
written
down
but
yeah.
I
guess
it's.
That's
maybe
back
to
my
other
comment
too.
Is
it?
Is
it
like?
You
know
this
particular
focus
area,
or
is
it
something
more
like
you
know?
L
Yeah,
that's
that's
basically
it!
I
originally
went
to
the
npm
rfc
and
I
got
redirected
here,
but
it
seems
like
this
should
go
through
a
different
thing,
like
a
cli
for
a
tool
that
would
manage.
F
Yeah
this
apologize
bradley.
That
was
me
that
I
think
said
to
bring
us
here
based
on
the
scope
of
this
work,
so
we
we
can
take
it
back
and
and
maybe
flush
out
an
rfc
together
for
what
this
looks
like
and
I'd
love
to
to
talk
more
about
it
offline.
Maybe
so.
G
Yeah,
I
think
just
probably
worth
noting
that
the
reason
why
we
recommended
to
come
here
is
to
have
a
more
neutral
ground
to
discuss
it.
So
we
also
have
the
possibility
of
the
other
package
managers
jumping
in
and
participating
in
the
conversation
if
they
are
not
like
comfortable
doing
so
in
the
npm
operating
calls.
A
And
that's
kind
of
where
I
was
wondering
like
is
the
collaboration
space
appropriate
like
if
we
had
a
generic
collaboration
space,
which
was
like
what
do
we?
What
do
we
agree
is
the
content
of
the
package
jason.
Then
it
would
have
been
a
natural,
hey,
let's
go
discuss
it
there
and
anybody
who's
interested
from
the
different
package
managers
or
other
you
know.
The
representatives
from
this
team
or
from
other
teams
could
actually
join
as
well.
So
I
it
does
seem
to
me
it's
a
gap
that
we
have
in
terms
of
like.
A
L
A
A
Again,
it's
probably
not,
you
know
the
more
you
the
more
you
get
people
involved,
the
more
comments
and
discussion
will
take
place.
So
if
it's
just
like
hey,
let's
get
some
trying
to
to
get
quick
feedback
on
whether
something
looks
good
or
not.
That'll
make
things
perhaps
take
longer
than
rather
than
shorter,
sure.
A
Okay,
well,
we
we
are
out
of
time,
and
I
guess
you
know
we
we,
if
there's
interest
we
could.
We
could
pick
up
next
year
in
the
next
meeting.
If
not
you
know,
and
then
not,
but
I
guess
we
ended
up
using
the
whole
time
and
more
I
I
know
I
need
to
drop
off.
So
I
think
at
this
point
we'll
say
thanks
for
everybody
for
their
work
this
year
and
we'll
see
in
the
new
year
thanks
bye.