►
A
A
I
assume
that's
on
the
cards
at
some
point.
I
I
haven't
heard
anything
about
it,
though
yeah.
A
So
I've
just
popped.
The
notes
Link
in
the
chat-
please
add
yourself
as
you
can
so
that
we
know
who
can.
D
B
A
All
right,
so
you
can
I'll
post
it
a
few
more
times
as
we
as
we
get
set
up.
C
Have
the
Stig
meeting
call
on
the
calendar,
even
if
it's
not
yeah
I'm,
just
gonna
sit
in
the
Sig
meeting
call
on
my
other
screen
just
to
like
in
case
things
in
case
people
join.
A
All
right,
one
last
posting
of
the
link
to
the
notes
and
I
think
we
can
kick
off.
Welcome
everybody
to
the
Emir
friendly
meeting
feels
like
it's
been
a
month.
That's
a
lame
joke.
The
first
thing
sort
of
auto
businesses
who
would
like
to
keep
the
notes.
A
For
your
contribution,
Lori,
which
takes
us
elegantly
to
new
faces,
is
there
anybody
who
would
like
to
introduce
themselves
who
might
not
have
been
here
before
or
hasn't
been
here
for
a
while.
H
J
Hey
Niels
I
work
at
packages
and
helped
maintain
composer
in
the
PHP
world
and
yeah.
It's
been
a
few
months
since
I
was
last
on
a
meeting.
I
was
interested
in
the
security
audit
for
repos,
who
spoke
to
Jonathan
the
other
day
and
figured
I
should
maybe
join
another
call
once
in
a
while
anyway,.
H
G
Hey
everyone
I'm
Jenny
I,
haven't
been
in
one
of
these
meetings
in
a
while,
but
yeah
I'm
at
Shopify
and
I
work
in
the
ruby
gems.
A
Yay
nice
to
see
you
Jenny,
okay,
all
right,
I,
think
that's
all
the
new
faces
unless
I've
missed
anybody,
which
means
we
move
on
to
the
next
item.
The
agenda,
which
is
I
just
wanted
to
bring
people's
attention.
You
might
probably
have
already
seen
this,
but
I
thought
it
was
really
exciting.
My
API
have
announced
that
they're
going
to
require
MFA
for
all
accounts.
A
Yeah.
It's
it's
great
news.
You
know:
we've
all
sort
of
been
standing
at
the
water's
edge
with
the
toe
in
the
water,
but
opio
looks
like
they're
going
to
dive
in
so
Bravo
I,
say:
I'll,
be
very
interested.
A
I,
don't
see
anybody
from
IPA
today,
I,
don't
think
you
could
talk
about
it,
but
I'm
very
much
looking
forward
to
the
sort
of
reporting
back
about
their
experience
and
what
went
well
and
what
didn't
and
what
was
hard
and
what
was
easy,
because
we
sort
of
hypothesized
in
the
past
about
what
that
would
look
like,
but
no
we've
done
it
yet
so
I'm
looking
forward
to
learning
more
from
pipei
about
how
it
goes.
A
Which
is
also
really
exciting,
like
that,
that
kind
of
like
to
me
that
raises
the
water
line.
It's
almost
all
of
Open
Source,
like
almost
everybody,
you
know,
or
at
least
half
of
the
universe
of
Open
Source,
will
now
have
familiarity
with
MFA
and
have
some
sort
of
a
setup
for
it.
So
I
think
it
will
make
it
much
easier
for,
like
the
increment,
for
a
package
repository
to
ask
for
MFA
to
be
applied
across
the
board
will
be
much
smaller
yeah
it's
a
smaller
Delta
than
it
was
previously.
F
We
had
previously
discussed
this
idea
of
like
a
of
a
shared
help,
desk
and
and
one
of
the
driving
forces
behind
that
was
as
websites
enable
MFA.
They
often
see
an
increase
in
support
requests
around
account,
recovery,
I,
didn't
I,
didn't
know
if
there
was
a
thread
there
to
to
pick
up
about
ways
that
this
group
could
help
enable
more
Registries
to
enable
MFA
for
all
users.
A
Yeah
I
was
hoping:
I
was
hoping
to
quit
some
pipe
bi
folks
about
that
today,
sort
of
got
the
sense
like
one
thing
that
gets
mentioned
in
that
blog
post
is
they
were
talking
about
the
support
burden
of
dealing
with
malicious
packages
and
account
takeovers,
so
it
might
be
that
their
Reckoning
is
that
the
net
account
but
like
the
in
that
support
burden
is
reduced
and
definitely
I
want
to
see
if
their
experience
bears
that
out.
C
A
Yeah,
when
I
was
when
I
was
working
on
the
documentation
for
the
MFA
rollout
on
ruby
gems,
that
was
at
least
a
strong
recommendation.
We
basically
pointed
out,
like
you,
ought
to
have
two
devices
if
you're
using
in
case
one
gets
lost,
or
you
know,
breaks
for
whatever
reason.
F
Or
any
of
the
other
platforms
represented
on
this
call
interested
in
enabling
MFA
for
all
their
users
or
or
have
roadblocks
or
or
questions
or
things
that
we
could
do
to
support
them
in
that
endeavor.
J
I'm
happy
to
share
what
that
looks
like
for
us,
but
I
mean
interested
sure.
Obviously
it
will
be
a
good
move.
I
think
the
the
roadblock
bear
is
kind
of
a
workflows
and
requirements
so
that
organizations
can
properly
manage
multiple
accounts
to
share
ownership
and
I
think
that's
kind
of
well.
J
We
have
a
insufficient
amount
of
support
for
right
now,
so
that
there
are
a
number
of
organizations
that
prefer
to
use
a
shared
email
address
that
they
can
use
like
account,
recovery
on
Etc,
so
that
multi-factor
authentication
just
doesn't
work
well
if
a
single
account
is
shared
which
obviously
not
a
great
practice
anyway,
but
requires
quite
a
bit
of
worked.
A
J
Yes,
commercial,
very
tiny,
and
yes,
it's
still
kind
of
somewhat
community
supported
lots
of
community
contributions
to
actually
maintain
it.
So
I
guess
a
mix
of
both.
G
A
I
think
I
think
one
thing
to
learn
from
Pi,
Pi
and,
to
some
extent,
from
ruby
gems
has
been
that
you
sort
of
like
aim
to
introduce
some
sort
of
MFA
support.
First
and
then,
ideally,
you
set
up
what
a
pipei
called
trusted
Publishers
and
in
ruby
gems
I'm,
not
sure
what
it's
going
to
be
called,
but
basically
accepting
you
know
IDC
token
and
returning
a
push
token.
That's
got
about
15
minutes
on
it,
so
that
that
handles
the
automated
case
with
the
same
sort
of
level
of
assurance.
J
J
Off
again,
no,
it
doesn't
really
matter
for
packages,
because
you
can't
push
code
to
packages
so
that
works
a
bit
differently
than
all
the
other
ecosystems.
You
don't
actually
push
code
to
the
registry.
The
registry
pulls
the
code
from
your
prospective
code
repository
because.
H
C
B
I
would
I
would
add
just
from
npm
a
couple
things
like
we
do
have
all
sorts
of
build
processes
that
people
can
have
and
the
publish
process
involves
putting
that
into
a
tarball
and
then
publishing
that
to
our
registry,
so
that
you
know
more,
like
any
of
the
other
registries,
not
like
what's
being
talked
about
from
python
from
PHP,
the
other
one
I'll
add
really
quickly
is
like.
We
have
not
had
the
ability
to
prioritize,
oidc
or
kind
of
like
you
know,
short-lived
tokens
and
how
we
solve
that
is
by
having
what
we
call.
B
We
have
two
different
token
types.
We
have
a
automation,
token
and
a
granular
access
token.
Those
token
types
allow
you
to
publish
without
2fa.
They
work
somewhat
like,
like
a
service
account,
essentially
with
the
granular
access
token.
You
can
scope
that
token
to
specific
packages,
so
that
will
only
have
access
to
the
limited
resources
that
that
are
defined
there
and
then
on
the
packages
configuration
itself.
You
can
specify
that,
like
you
know,
you
allow
this
type
of
token
or
you
disallow
this
type
of
token,
to
only
allow
publish
without
2fa.
B
If
it
is
from
this
kind
of
token
type,
you
know
longer
term
I
think
there's
a
desire
to
move
towards
oidc.
But
it's
been
a
little
bit
complicated
to
to
prioritize
that
and
regarding
the
MFA
I
guess
the
one
thing
that
I'd
call
out,
because
you
were
talking
more
about
like
org
management
and
that
kind
of
stuff.
B
We
have
Work
Management
on
npm,
the
biggest
problem
that
we've
had
with
rolling
out
enforcement
and
why
we're
not
right
now,
looking
at
doing
anything
more
than
we
did
of
kind
of
like
the
highest
subset
of
our
customers
is
just
the
amount
of
support
traffic
that
we
get
for
account
recovery
and
the
amount
of
edge
cases
there
are,
and
we
even
now
are
still
having
to
adapt
our
process
because
we
don't
want
to
make
like
carve
outs
or
exceptions.
B
But
the
reality
is
that
people
are
losing
their
password
and
their
MFA,
which,
in
my
opinion,
puts
their
accounts
in
like
an
unrecoverable
State.
And
then
that
makes
for
unhappy
people
and
in
the
case
of
businesses
yeah,
you
could
have
all
of
the
org
management
controls
you
want.
People
are
still
going
to
keep
it
on
their
personal
accounts,
they're
still
not
going
to
manage
it
properly,
they're
still
going
to
lose
the
keys
to
the
castle
and
then
you're
going
to
be
managing
all
of
these
exceptions
through
support
tickets.
B
I'd
have
to
look
at
our
dashboard,
but
it's
measured
in
hundreds
of
tickets
a
week
for
population.
So
it's
a
pretty
significant
undertaking.
We
have
four
full-time
support
agents
that
a
good
majority
of
their
time
is
spent
just
doing
account.
Recoveries.
C
Really
so,
okay,
one
of
the
ones
that
I
saw
that
was
really
interesting,
was
when
I
signed
up
for
a
burp
Suite
account
right
when
you,
when
you
create
your
birth
food
account
birdsweet
does
something
that
I've
never
seen
in
the
industry
other
than
this
they
say
here.
Is
your
password
store
it
in
your?
C
Like
you,
don't
give
them
a
password,
you
don't
set
a
password,
they
say
here's
your
password
put
it
in
your
password
vault
and
then
like
it's,
not
a
password
that
you
could
reasonably
remember
and
that
just
it's
a
it's
a
forcing
function
on
like
you
know,
you
should
have
a
two.
You
should
have
a
password
manager
for
your
for
your
password.
B
C
I
Do
you
have
a
analysis
of
how
many
of
them
you
stop
password
requests
and
how
much
or
that
we've
been
trying
to
his
credentials,
because
it's
very
interesting
to
to
still
credentials.
E
He
was
wondering
if
people
were
trying
to
steal
credentials
or
are
they
legitimate.
B
Majority
of
them
are
legitimate
account
recoveries.
We
have
a
pretty
intensive
process
that
involves
multiple
factors
of
identity,
verification
in
order
to
validate
and
recover
the
account.
We
have
had
some
cases
of
people
trying
to
do
like
social
engineering.
B
Unfortunately,
some
that
also
were
successful
and
were
very
creative.
Those
were
like
creative
red
teams,
but
for
the
for
the
most
part
it
they
they
I
would
I
would
argue.
This
is
not
scientific
I'd
have
to
look
at
actual
numbers,
but
I
would
say.
99
of
them
are
legitimate
recoveries,
and
it's
more
often
that
we're
not
able
to
recover
someone
who
is
obviously
the
legitimate
account
holder,
because
we
can't
verify
their
identity.
C
Like
the
actual
attempts
to
social
engineer
you
because
I
know
that
back
when
Adam
Baldwin
was
was
running
npm.
There
was
a
lot
of
blog
posts
about
like
security
incidents
from
npm.
Did
you
guys,
publish
those
for
the
social
engineering
attempts
that
have
succeeded,
or
is
that
public
in
any
way,
I'm
just
curious.
B
I'd
have
to
double
check,
I'm,
not
sure
what
we
made
public
or
didn't
make
public
there.
Yeah.
G
C
A
B
What
you
usually
don't
want
to
get
into
the
specifics,
but
what
I?
What
I
could
say
is
that
part
of
us
having
an
explicit
process
with
clear
steps,
including
the
fact
that
knowledge
of
password
is
now
like
mandatory
to
begin
account.
Recovery
has
significantly
raised
the
bar
and
minimized
the
circumstances
where
social
engineering
was
happening
and
I
would
say
like
truthfully.
The
like
and
I
will
share
this
because
I
don't
think
that
it's
like
too
much
of
an
issue.
B
G
B
Was
very
hard
to
like
to
notice
and
we
have
things
in
place
now
that
we
don't
really
talk
about
too
extensively,
because
then
people
could
you
know,
get
around
it,
but
we
have
things
in
place
to
identify
like
the
domain
exploration
attack
and
yeah.
D
B
Notes
on
accounts
and
Force
additional
measures
of
identity,
verification
for
accounts
that
we
think
fall
into
that
category,
but
the
off
the
top
I
had
the
only
successful
social
engineering
one
that
I
can
think
of
was
one
where
someone
did
the
the
domain
exploration
attack.
A
Oh,
that
was
an
interesting
conversation
exactly
the
sort
of
conversation
we
sort
of
envisaged
when
we
set
it
up
really
cool
Jonathan
you're.
Next,
you
wanted
to
talk
about
the
great
audit
yeah.
C
And
Zach,
this
ties
into
your
meta
point
of
what
would
people
like
to
get
out
of
this
working
group?
This
is
what
I'd
like
to
get
out
of
this
working
group.
Is
this
this
Initiative
off
the
ground
and
into
the
into
the
into
the
skies,
so
I
sent
out
an
email
to
I?
Think
I.
C
Of
my
Call
to
Arms
of
sorts
I
sent
out
emails
to
all
of
the
security
at
email
addresses
for,
let's
see,
I
think
I
did
Gradle
Conan
Center,
Maven,
Central,
ruby,
gems,
Pi,
Pi,
golang,
cargo,
Docker,
nougat
and
packages.
C
I
didn't
do
Drupal
or
Hilary
like
I,
don't
know
the
email
for
Larry
and
I,
don't
know
that
they
are
used
enough
and
then
Drupal
I
had
a
chat
with
Nils
about
whether
or
not
that's
relevant
or
not,
but
I
sent
out
an
email
to
all
of
the
different
packaging
ecosystems.
Saying
hey:
this
is
an
initiative.
C
Here's
the
document
would
love
to
see
you
all
involved.
What
does
this
interest
you?
It
seems
like
generally
I've
gotten
a
lot
of
positive
feedback
and
interest
in
this
in
this
proposal.
High
level.
Has
anybody
not
read
through
this
proposal.
E
D
C
Be
correct,
yeah,
perfect,
any
okay!
Let
me
just
give
you
the
high
level
sort
of
you
know
high
level
I'm,
basing
my
presumption
on
the
concept,
the
the
the
basis
that,
because
major
architect
servers
right
like
Central
repository
servers
right,
like
maybe
Central
npm,
you
know
all
the
ones
that
we
represent
here
are
usually
a
cost
center,
and
you
know
not
not
something
that
a
company
sells.
C
It's
likely
that
this
service
has
never
had
a
pen
test
done
to
it
because
of
a
forcing
function
for
requiring
you
know,
a
security
audit
is
usually
a
purchasing
agreement
that
that
other
firmist
has.
It
says
we're
not
going
to
purchase
this
unless
you,
you
know,
have
had
an
audit
and
because
that
that
that
forcing
function
that
Market
Force
has
never
existed,
it's
likely
that
a
lot
of
them
have
not
also
for
community-run
artifact
servers.
You
know
rubygems
Pi,
Pi
stuff,
like
that.
C
This
probably
not
been
enough
money
in
the
industry
to
actually
pay
for
an
audit,
and
so
I
would
like
to
change
that
I'd
like
to
actually
you
know,
I
know
as
as
the
open
SF
we're
talking
about
like
six
store
and
we're
talking
about
all
these
other.
Like
you
know,
solutions
for
securing
open
source,
but
I'd
like
can
we
deal
with
the
like
the
basics?
Can
we
start
at
the
beginning?
And
so
the
proposal
here
is:
let's
like
get
a
pen
test
done
and
also
while
we're
at
it.
C
Let's
also
hire
a
red
team
to
engage
in
in
actual
social
engineering,
potentially
against
each
one
of
these
artifact
servers
and
then
talk
about
it
right.
C
Let's,
like
you
know,
let's,
let's
talk
about
the
vulnerabilities
uncovered
and
and
and
include
that,
not
necessarily
the
red
team
stuff,
because
that's
a
little
more
sensitive
I
think
that
we
should
disclose
like
the
act
and
that
the
that
you
know
what
what
impact
they
were
able
to
achieve
and
and
that
the
test
happened
for
the
red
team,
but
not
necessarily
the
full
details,
but
for
the
technical
ones,
because
those
are
vulnerabilities
that
have
been
found
and
fixed
next
I'd
love
to
see.
Most
of
those
reports
published
the
the
high
level
is.
C
High
Pi,
ruby,
gems,
the
the
initiative
we
would
pay
for
both
the
pen
test
and
the
red
team
engagement
and
also
contractor
or
someone
who
spent
you
know
to
spend
time
fixing
this
vulnerability
either.
You
know
the
organization.
C
Is
the
person
we
want
you
to
fund?
Can
you
fund
them
or
we
would
offer
them
a
contractor
for
corporate
run
ones
that
it'll
be
a
little
different?
We
would
either
say:
hey
we'd
love
to
see
a
a
red
team
engagement
test
and
also
a
retest
result
with
the
fixes,
if
you
want
to
pay
for
it,
use
a
corporation
want
to
pay
for
it.
We'll
give
you
180
days
to
do
that.
C
If
you'd
like
us
to
pay
for
it,
then
we
will
the
disclosures
that
come
with
that
will
follow
the
90-day
disclosure
deadline,
timeline
that
the
open
SF
has
for
for
disclosure.
The
one
thing
that's
a
little
different,
just
as
a
carve
out
I,
don't
know
if
any.
If
all
of
you
have
read
the
policy
for
vulnerability
disclosures
with
open
SF,
the
one
thing
that's
slightly
different
is
there's
a
caviar.
C
Here,
for
the
caveat
bonding
caveat,
all
vulnerabilities
is
closed
during
the
test.
The
course
of
the
technology
audit
will
be
bound
by
the
open,
ssf
outbound
vulnerability
disclosure
policy
with
one
change,
while.
C
Discovery
of
the
to
the
Target,
the
open,
ssf,
outbound,
vulnerability,
disclosure
policy
notice
date,
which
is
the
start
of
the
disclosure
deadline,
will
be
one
business
day
after
the
schedule
of
pen
test
includes
not
including
the
retest.
So
that
lets
the
report.
You
know
you
start
getting
reports
earlier
and
then
from
there
the
90
days
will
occur
so
yeah
at
a
high
level.
We're
looking
for
funding
this
I've
spoken.
You
know
nobody's
committed
to
anything.
C
Michael
scovetta
from
Alpha
Omega
I
work
for
Alpha
Omega
by
the
way
has
said
that
we,
he
could
probably
put
in
like
half
of
the
proposed
amount
from
Alpha
Omega,
but
we're
looking
for
potentially
other
other
organizations
to
step
in
and
help
fund.
This
proposal
either
open
source
security,
Foundation
or
you
know,
other
entities
to
come
in
and
assist
we're
also
going
to
be
working
with
ostiff
on
this
as
well.
F
Yes,
well,
we've
talked
about
this
topic
before
but
like
I,
I
love,
I
love.
What's
at
the
core
of
this
proposal,
which
is
like
how
do
we
turn
openness
to
seven
dollars
into
meaningful
security
improvements
for
package
ecosystems,
I'm
not
sold
on
the
chain
of
reasoning
by
which
we
get
to
that
point.
For
example,
you
know
the
python
software
Foundation
put
together
this
list
of
fundable
package
improvements
years
ago.
This
is
how
MFA
was
implemented
in
Pi
Pi
via
and
Grant
from
an
external
party.
F
F
If
security
risk
assessments
have
happened
on
package
managers,
because
that
type
of
information
isn't,
you
know,
typically
disclosed
publicly
and
so
we're
saying
well,
we
have
to
do
the
risk
assessment
in
order
to
you
know
kind
of
construct,
the
fundable
improvements,
I,
don't
I,
don't
think
that's
the
case,
though
I
think
we
could
work
with
different
package
management,
ecosystems
and
say
Hey.
You
know
in
the
event
that
you
haven't
done
a
risk
assessment.
We
can
help
you
with
that.
F
Surely,
but
I
I
would
be
more
interested
in
in
working
with
teams
who
manage
factual
repositories,
who
often
already
know
where
the
security
skeletons
lie
and
putting
together
sort
of
high
level
project
descriptions
of
like
what
could
be
done
in
their
ecosystem,
their
proof
security.
You
know
once
discover
those
projects
approximately
cost
Etc.
So.
C
You're
saying
like,
instead
of
doing
the
security
pen
test,
go
to
them
and
say:
where
would
where
do
you
need
funding
to
improve
your
security
overall
and
go
where
their
skeletons
are
buried,
instead
of,
instead
of
asking
an
external
firm
to
perform
the
audit
to
figure
out
where
the
skeletons
are?
Yes,.
F
Like
I,
wouldn't
I
wouldn't
say,
don't
do
a
risk
assessment
in
any
case
like
there
may
be
a
case
where
a
package
manager
says
like
Yes.
Actually,
that
is
what
we
need
is
a
risk
assessment.
However,
I
think
that
in
many
cases
these
platforms
already
have
an
idea
of
where
this
security
shortcomings
are,
and
we
could.
F
We
could
just
write
that
list
down
and
then
take
that
to
the
open,
ssf
or
take
it
to
sisa,
or
you
know
other
other
bodies
that
might
be
interested
in
writing,
checks
and
use
that
to
deliver
those
security
improvements.
J
I
think
personally,
as
somebody
who's
kind
of
interested
in
this
audit
for
their
package
registry
is
I,
think
those
are
two
separate
problems
and
I
think
both
of
those
need
funding.
Yes,
like
yes,
I'm,
absolutely
aware
of
issues
where,
like
overall
you
know,
we
could
build
new
features
to
improve
security.
We
could,
you
know,
build
certain
things
like
make
changes
that
would
improve
security,
but
at
the
same
time,
I'm
also
entirely
aware
that
you
know
we
may
not
actually
know
of
all
the
issues
that
exist
and
we're
specifically
I
mean
the
point
of
pen.
C
I
I
mean,
for
example,
one
of
the
things
that
I'm
thinking
about
is
like
we
as
security
practitioners
right
are.
We
can
understand
the
scope
of
the
attack
Vector
for
our
artifact
servers,
but
there
are
is
a
bunch
of
research.
C
That's
come
out
of
like
portsmaker,
and
you
know
discussed
it
at
black
hat
and
stuff
like
that
around
like
HP
request
splitting
right
and
the
impact
of
that
is
that
you
can,
you
know,
poison,
a
request
that
comes
back
and
hijack
the
response
and
then,
like
inject
your
own
data
into
the
response,
that's
going
to
somebody
else's
request,
like
of
somebody
else's
request
for
potentially
an
artifact,
usually
that's
against
web
server,
or
something
like
that
right.
C
That's
something
that
we
as
security
practitioners
may
be
aware
of,
but
may
not
know
how
to
test
for,
and
it's
only
somebody,
that's
that
has
the
knowledge
of
how
to
go
after
that
sort
of
vulnerability
and
test.
For
that
sort
of
thing,
that's
going
to
unveil
that!
Actually,
you
are
vulnerable
to
this
and
you
need
to
you
know
you
need
to
consider
fixing
this
sort
of
thing.
I!
Think
there's
a
bunch
of
other
sort
of
classes
of
vulnerabilities
that
exist
in
the
web
sphere
and
not
in
the
web
sphere.
C
B
B
Many
of
these
things
being
things
that
would
not
show
up
in
an
external
red
team
audit
and
would
only
come
from
like
analyzing
the
architecture
and
seeing
the
way
in
which
you
know
things
are
built
I'm
trying
not
to
share
too
many
details
about
the
specifics
here,
but
I
think
you.
You
have
an
idea
of
where
I'm,
where
I'm
leaning
here.
C
At
clarification
of
a
question
on
this
point,
are
you
saying,
was
this
audit?
So
was
this
audit
performed
by
internal
entities
that
understood
the
architecture,
or
was
this
an
external
firm
that
was
given
all
of
the
information
about?
This
is
how
our
architecture
is.
Here's
the
source
code.
All
of
that
that
that
allowed
that
to
happen.
B
I
think
that
that's
a
loaded
question
to
be
honest
and
the
reason
why
I'll
say
that
is
GitHub
is
big
enough.
That
npm
was
acquired
that
even
an
internal
team,
it's
kind
of
the
same
thing
in
my
personal
opinion,
I
understand
like
structurally.
It
isn't.
So
these
were
all
internal
folks,
but
the
folks
who
did
the
audit
were
people
who
did
not
have
familiarity
or
hands-on
experience
with
npm
our
Security
Experts,
who
are
given
full
access
to
the
npm
source
code
and
paired
directly
with
the
npm
engineers
to
come
up
with
this
solution.
B
So
it
was
entirely
internal,
but
I
think
in
many
ways
it
looks
like
the
way
an
external
audit
would
but
I
recognize
that,
for
the
sake
of
like
you
know
a
stamp
or
approval
or
compliance
it
may
it
may
not
reach
that
bar.
But
that
was
what
we
were
okay
with
and
we
actually
felt
because
of
that
structure.
We
could
actually
have
something
that
was
even
more
like
Hands-On.
B
The
reason
why
I
mentioned
this
is
not
just
to
talk
about
the
fact
that
we
did
this
audit,
but,
like
the
result
of
this,
this
audit
is
like
a
multi-quarter
effort
that
is
still
ongoing
to
completely
revamp
like
pretty
much
everything
and
is
taking
almost
the
majority
of
our
effort
and
Engineering
power
beyond
like
a
handful
of
feature.
Things
like
when
I
said,
like
we
don't
have
the
capacity
to
do
something
like
oidc
after
we've
done
this
whole
huge
Sprint
around
like
MFA
and
a
lot
of
stuff.
B
B
The
reason
why
I
mentioned
this
and
in
the
context
is
I,
think
that
you
know
it's
great
for
the
open
ssf
to
be
pushing
corn
and
wanting
to
make
improvements.
But
I
do
think
that,
like
it
is
making
some
assumptions
about
like
what
would
be
the
best
type
of
improvements
for
an
organization
what
they
have,
especially
for
the
corporate
entities
like
what
capacity
they
have
to
respond
to
something
so
like.
B
Like
concerted
effort
that
we're
already
doing
and
from
you
know
where
I'm
sitting,
it's
like
the
the
options
that
I'm
being
presented
in
my
opinion
are,
like
you
know,
play
ball
and
get
involved
or
you're
like
a
bad
Steward
right
like
and
I'm,
not
saying
that
that's
the
intent,
but
like
that's
what
I
feel
like
the
result
could
look
like,
and
meanwhile
I'm
saying
like
no
like,
we
already
are
so
invested
in,
like
our
security
that
we've
made
like
a
multi-year
roadmap
based
on
other
findings
that
we've
already
done,
that
we
don't
have
the
capacity
to
participate
in
this
program
today.
B
B
I
think
that's
table
stakes
and
it
really
shouldn't
be
considered
otherwise,
but
I
do
think
that,
like
there,
there's
I
think
there's
kind
of
like
a
larger
conversation
to
be
had
and
I
think
it's
kind
of
akin
to
what
what
Zach
was
saying
around
like
what
are
the
organization's
road
maps
right
now,
and
is
this
type
of
Engagement
the
top
thing
that
they
would
prioritize
I
would
say
going
back
to
your
thesis,
I
think
your
original
thesis
that
basically
because
they're
cost
centers
corporations
are
not
going
to
invest
in
security,
I
I
actually
think
that's
flawed
and
I'm
not
trying
like
our
entire
roadmap.
B
Our
entire
funding
is
entirely
about
security
for
npm,
because
we
take
it
so
seriously.
It's
just
this
particular
type
of
Engagement
is
not
what
we've
prioritized
based
on.
What
we
know
internally
and
so
I
think
that
there's
a
mismatch
there
that
could
result
in
you
know,
like
kind
of
like
a
conflict
I
I
would
be
I
would
be
very
disappointed.
E
All
right
so
I
think,
based
on
what
you're
saying
miles,
what
what
seems
to
make
the
most
sense
to
me
is
to
have
the
conversations
with
the
package
types
first
like
to
get
like.
So
there's
like
a
checklist
like
a
verified
checklist
that
says.
Okay
here
are
the
requirements
and
here's
what
we're
looking
at,
and
this
is
what
we
need
for
you
to
participate
in
this
program.
E
If
you
check
off
all
of
these
things
already,
because
it's
within
your
roadmap,
you've
already
done
it
and
you're
making
the
steps
necessary
to
be
secure,
you
get
the
stamp
of
approval,
saying
you've
reached
our
level
of
whatever
I
and
I.
Think
that
way,
it
shows
that
the
organization
has
actually
talked
to
you
to
make
sure
that
you're
involved
in
this,
that
you've
agreed
that
this
is
a
good
process
and
that
you've
shown
that
you're
already
making
the
steps
to
fulfill
the
requirements
of
what
this
whole
process
is
about.
E
So
you
wouldn't
look
like
a
bad
Steward.
You
would
actually,
you
know
be
like
thank
you,
but
no
because
here
we
are,
and
you
get
the
stamp
that
says.
Yes,
you've
passed
our
checklist
of
verification
that
you're
going
to
whatever
I
think
that
that's
something
that
definitely
should
be
taken
into
account
based
on
both
what
miles
and
Zach
said,
because
these
are
assumptions
that
we're
making
I
think
they're
good
assumptions
and
could
be
holding
true
for
the
majority
of
some
package
types.
E
But
when
individual
packages
already
taken
care
of
things,
then
there
needs
to
be
a
a
pass
through
like
like
a
credly
badge
or
something
you
know
that
says:
yeah
you're
done.
You
know
something
that
shows
up
on
the
GitHub
account
that
says
you
know
open
ssf,
whatever
artifact
repository
check.
You
know
something
like
that.
Just
an
idea
that.
C
Was
that
that's
that
the
rationale
behind
the
puzzle
on
the
side
of
if
you're,
if
you
have
done
the
work
right,
if
you
have
spent
the
time
to
get
that
audit
done,
then
great,
that's
wonderful,
like
we,
we
don't
need
to
spend
money
on
you,
that's
spectacular,
but
can
you
I
mean
we
don't
need
to
send
us
the
full
thing
you
can
redact
some
of
it,
but
can
you
present
to
us
and
and
publish
is
it
you
know,
publish
your
your
pen
test
report
that
that
that
came
out
of
the
work
that
you.
A
A
I
should
I
should
note.
This
is
in
the
discussions
we've
had
in
the
Sig
about
the
great
artifact
repository
ordered
the
one
of
the
sort
of
the
issues
that
I
raised
was
the
concern
about
husband
being
the
limited
pool
of
Goodwill.
The
open
ssf
has
we've
already
got
folks
who
look
at
us
as
Interlopers?
A
C
I
agree:
I,
just
you
know,
yeah,
that's
not.
A
A
J
I'm
trying
to
kind
of
ask
something
honestly
like
this
I
mean
my
first
impression
of
this
is
like
derailing
something
good
for
the
benefit
of
I.
Don't
know
having
like
a
a
nice
stamp
of
approval,
I
think
as
it
was
just
called
and
I,
think
it's,
it's
absolutely
good
to
offer
this
option
to
Registries
that
need
it
and
want
it
and
I
think
that's
all.
J
This
should
be
it's
an
offer
to
anyone
who
doesn't
otherwise
have
the
the
a
way
to
pen
test
or
for
whatever
reason,
can't
do
this
and
whoever
it
doesn't
need.
It
has
like
things:
they've
done
enough
internally,
doesn't
need
to
make
use
of
this
program
and
I
I,
don't
think
like
if
you're
just
trying
to
you
know
improve
some
of
these
situations,
you
have
to
put
your
focus
on
the
ones
who
don't
need
it.
I
think
just
you
know,
build
a
program
speak
to
individual
people.
J
F
And
say:
let's:
let's:
let's
walk
before
we
run
before
we
say
we're
mandating
this
for
every
package
registry
I've
read
of
I,
don't
know
some
whatever
threshold
we
determine,
let's
just
say
hey.
This
is
something
that
open
SF
is
offering
who's
interested.
Let's
run
this
with
a
few
Registries
see
what
happens
and
then
from
there
determine
how
we
want
to
increase
the
scope
of
the
project.
B
I
was
just
saying
that
I
muted
I'm,
going
to
pile
on
really
quickly
with
I
I,
guess
hearing
this
resonates
with
me
and
I
think
what's
happening
and
you
can
push
back.
If
you
disagree,
it
feels
like
a
conflation
of
two
things,
possibly
and
and
one
as
notes
put.
It
is
a
program.
B
That's
about
improving
the
security
of
individual
Registries
and
the
other
is
about
like
a
compliance
or
security
mandate
for
ensuring
that
that
Registries
are
at
a
certain
level
or
net
a
certain
level,
and
it
seems
like
the
first
program,
is
kind
of
in
service
of
the
second
program.
Because
if
we're
going
to
start
enforcing
these
things,
then
we
need
to
do
something
to
level
the
playing
field
or
to
allow
folks
to
like
meet
that
bar.
B
So
I
I
do
think
that
the
first
program
seems
like
a
no-brainer
win
and
should
just
start
running
if
we're
able
to
fund
it.
And
the
second
program
is
something
that,
if
it's
split
out
and
thought
about
separately,
I
would
personally
like
to
purchase
dissipate
more
in
conversations
to
see
what
that
means
and
I
think
that,
if
it's
split
from
like
how
are
these
things
funded,
how
is
it
done,
and
that's
mostly
just
about
like
hey?
B
What's
the
security
Min
bar
that
we
expect
these
kinds
of
things
to
meet
almost
like,
if
we
think
about
like
Aria
or
accessibility,
compliance
like
we
have
accessibility
scores
and,
like
you
do
these
things,
you
get
the
score
if
it's
I
think
like
even
having
it
as
a
binary
honestly
is
probably
setting
up
for
for
a
problem.
But
there's
a
lot
I
think
a
lot
of
conversations
to
be
had
there
about
like
what
should
those
levels
of
compliance
be
for
Registries?
How
could
they
meet
them?
What
are
the
expectations?
B
What
are
the
ongoing
expectations,
and
it
would
be
a
shame
to
allow
like
kind
of
that
design
to
get
in
the
way
of
like
starting
to
do
something.
That
seems
like
it's
already
going
to
have
like
an
ecosystem
win
which
is
like
go
out
and
do
these
pen
tests
against
Registries
that
are
ready
for
them.
And
if
that
undermines
like
the
goal
like
the
ultimate
goal,
then
probably
is
worth
more
conversation.
C
So
part
of
the
vision
behind
this
was,
you
know,
coming
up
with
a
set
of
things
that
we
want
to
see,
tested
right
and
like
a
common
set
of
things.
So
I
think
that's
what
you
might
be
saying
like.
Let's
come
up
with
a
common
set
of
things
we
want
to
see
tested
by
any
of
these
audits
and
for
corporations.
I
said:
we've
already
tested
this
stuff.
C
They
can,
you
know,
sell
the
test
or
show
us
a
pen
test
report
and
say
like
this
is
the
stuff
that
got
covered
stuff
like
that
something
like
that
right,
but
we
we
want.
We
want
to
try
to
come
to
a
common
understanding
and
if
they
haven't,
if
a
firm
organization
does
not
have
this
audit
of
the
same
tear
done
talk
to
them
about
you
know,
then
it's
a
corporation.
How
can
we
get
you
to
this
point
where
you
can
also
include
this
in
in
your
test?
C
The
other
thing
that
I
you
know
recognize
is
I
spoke
to
some
organizations
and,
like
you.
C
We're
kind
of
writing
like
150
000,
for
our
technology,
like
pen,
pen
test
right
just
for
the
pen
test.
That's
a
number
that
came
from
speaking
to
Austin
as
how
much
they've
paid
for
audits
now
I
know.
There's
a
lot
of
organizations
out.
There
corporations
out
there
that
may
not
be
able
to
front
that
amount
of
money
for
an
audit,
even
if
they
are
corporations
right
to
pay
for
so
because
that's
just
a
pretty
chunk
of
money
and
I've
spoken
to
some
and
they're.
C
Like
you
know,
yes,
we
can
get
a
pen
test
done,
but
not
for
that
much
money
right
like
that.
That's
level
of
depth
that
we
we
can't
invest
in,
so
that
trying
trying
to
come
up
with
a
list
of
items
that
we
want
and
then
also
you
know
saying.
Well,
we
need
this.
We
need
more
than
what
you've
given
us
is
is
is
is,
is
potentially
a
part
of
this
conversation
that
we're
thinking
about
that
we
may
need
to
have
too.
B
But
it
I
guess
I'll
come
back
to
that
compliance
part
like
to
me.
It
sounds
like
a
mismatch
between
like
like
engagements
and
trying
to
do
work
in
compliance.
The
exam
one
example
I'll
throw
out
there
is
like
accessibility
like
and
we're
talking
about
levels
of
accessibility,
compliance
of
our
product.
We
have
internal
Council
that
review
it
in
internal
accessibility
teams
that
sign
off
and
then
assign
it
a
grade.
We
don't
have
a
necessarily
like
a
third
party
like
audit
us
or
someone
that
we
need
to
show
receipts
to
in
in
the
same
way.
B
To
be
honest,
I'd
have
to
go
in
and
look
more
at
like
how
that
works,
but
these
are
the
kind
of
things
I
would
love
to
like
poke
at
and
understand
and
think
like.
How
do
we
make
something
that
isn't
just
even
an
open,
ssf
thing
that
could
become
like
an
industry
standard
for
services
like
how
do
we
scale
this
really
big
and
I?
Think
we
would
have
to
look
at
the
way
in
which,
like
you
know,
current
things
work
there.
There
are
other
things
around
compliance
that
do
have.
B
You
know,
like
third-party
audits,
but
I,
think
that
that's
a
little
bit
different
than
like
you
know,
show
me
that
you
got
this
thing
done
again:
I
guess
and
I
don't
want
to
belabor
the
point
I
personally
feel
like
hey.
We
want
to
go.
Do
pen
tests
we
want
to
go,
engage
with
you.
C
A
So
that
we
can,
we
can
discuss
this
further
I'm
just
keeping
an
eye
on
time,
and
we
have
a
few
more
issues
to
get
through
one,
that's
quite
open-ended,
which
is
Zach.
You
were
asking
about.
What
do
we?
What
would
you
say
you
do
here.
F
Yeah-
and
none
of
these
are
particularly
urgent
or
timely,
maybe
other
than
the
the
docker
FYI,
but
the
the
primary
goal
at
that
point
was
there's.
F
Options
for
for
what
this
group
could
be,
it
could
be
a
forum
by
which
different
Registries
talk
about
best
practices,
learn
from
each
other.
You
know
request
a
documentation
be
provided
from
other
parties
so
that
they
can
more
effectively
Implement
capabilities,
Etc
or
or
maybe
more
to
Jonathan's
point.
F
It
could
be
a
way
to
try
to
establish
common
criteria,
be
that
you
know
secure
your
accessibility
and
you
know,
figure
out
ways
to
Drive
the
ecosystem
towards
those
common
capabilities
and
I,
know
I
know,
there's
a
lot
of
different
systems
represented
here
today
on
this
call,
and
so
I
was
sort
of
wondering,
maybe
sort
of
between
those
two
extremes.
F
If
they're,
if
people
are
leaning
more
towards,
oh,
we
just
want
a
forum
by
which
to
talk
to
other
people
who
have
similar
jobs,
that
we
do
at
different
places
or
or
if,
if
people
are
more
interested
in
sort
of
like
picking
specific
specific
capabilities
and
driving
those
forwards
or
both
or
something
else
entirely,
and
that
might
be
hard
to
answer
in
10
minutes,
but
but
generally
speaking,
that
was
what
I
was
hoping
to
understand.
Better.
C
In
what
I
have
observed
over
the
past
several
months
from
this
working
group
is,
is
it
a
level
of
it
seems
like
a
level
of
die
off
in
in
in
in
the
attendance
of
the
the
working
group?
It
seems
like
it's.
You
know
a
couple
of
core
people
and
chain
guard
right,
like
you
know
a
couple
of
couple
packages
of
chain
guard,
and
so
I
would
like
to
see
this.
This
working
group
revitalized
in
a
certain
level
because
it
seems
like
there's,
there's.
C
C
The
thing
is
that
a
lot
of
attackers
don't
cross
language
boundaries,
I,
don't
I,
don't
think
I
mean
it
could
be
completely
wrong,
but
that
kind
of
information
is
is
really
valuable,
but
I
think
that
there
does
need
to
be
a
sort
of
a
mission
to
encourage
people
to
to
or
or
a
set
of
things
we're
trying
to
deliver
on,
to
encourage
people
to
keep
showing
up
and
commenting
these
meetings.
And
it's
not
just
like
you
know,
same
old,
same
old.
D
A
I
felt
like
the
the
conversation
we
had
earlier,
that
was
triggered
by
the
Pi
Pi
MFA
change
was
was
interesting.
It
was
a
good
example
of
cross-pollination,
which
is
the
top
most
objective,
although
they're,
not
not
in
order
in
the
repo
one
that
I
wanted
to
highlight,
was
that
at
the
start,
we
we
established
the
principle
that
nothing
the
group
does
is
binding.
It's
not
a
governing
group.
A
It
can't
announce
a
standard
and
require
everybody
to
live
up
to
it
like
we
can
publish
what
we
we
said:
non-normative,
non-binding
recommendations
on
common
schemas
and
descriptive
documentation
of
experiences
and
best
practices
and
I
still
think.
That's
the
case.
The
thing
that's
really
tricky
is
that
anything
past
the
sort
of
the
Casual
engagement
that
the
the
free
wheeling
open-ended
conversations
that
we
have
is
difficult,
because
everybody's
busy
this
this
is
the
universal
problem
of
the
open
ssf
everybody's
got
to
do
so.
A
A
The
great
artifact
repository
audit
is
that
it
proposes
to
assign
full-time
people
to
to
work
on
this,
to
to
take
the
burden
off
the
shoulders
of
maintainers,
who
have
so
much
to
do
already,
especially
the
part
where
we're
tying
together
remediation
with
with
inspection,
all
of
which
is
to
say
it
has
gotten
quieter.
I
think,
basically,
a
lot
of
conversations
that
we
had
earlier
on
sort
of
like
came
to
a
natural
conclusion
like
folks
share
their
experiences,
and
there
wasn't
much
update
I.
A
Think
the
repository
order
has
a
great
opportunity
to
revitalize
discussion.
Certainly
around
that
area,
especially
as
we
discover
commonalities,
we
may
discover
particularly
architectural
questions,
are
in
common
if
I'm
not
sort
of
super
worried
at
the
moment
about
the
mix
of
discussion
and
topics,
I
think
we're
more
or
less
in
line
with
what
we
wanted
to
do.
I
do
wish
more
people
to
end
up
more
regularly
but
short
of
having
you
know,
like
a
cabaret
show
to
entice
the
punters
I'm,
not
sure
what
I
would
recommend
there
so
this.
F
I,
like
I
like
documenting
things,
and
so
if
there
are
things
that
people
want
to
see
documented
from
GitHub
npm
or
other
package
managers.
That's
another!
That's
another
topic
I'd
be
interested
in.
It's
the
right
sort
of
bite,
size
too,
where
it's
not
like
delivering
a
net
new
security
capability.
F
But
you
know
it's
something
that
that
can
be
done
in
a
week
or
two
I
don't
want
to
call
on
folks,
but
but
we
we
do
have
a
lot
of
package
managers
represented
here
today
and
especially
if
we
haven't
heard
from
you
yet
on
this
call.
I
would
I
would
love
to
hear
if
there's
something
particular
that
you
want
to
see
more
of
less
love,
Etc.
B
I'll,
be
really
quick
so
that
we
can
adhere
to
your
ask
of
people
you
haven't
heard
from
yet,
but
one
of
the
things
that
I've
really
enjoyed
about
this
group
and
I'll
admit
my
personal
attendance
has
waned
as
of
late.
B
That
is
having
a
group
of
folks
who
are
working
on
the
same
problem,
set
that
we
can
have
like
very
honest
dialogue
and
the
occasional
back
Channel
I
can
see
a
couple
of
people
on
the
call
right
now
without
like
calling
people
out
who
I've
had
private
calls.
With
from
these
calls,
where
we,
you
know,
discuss
in-depth,
like
you
know,
some
of
the
things
that
just
you
can't
talk
about
publicly
generally
and
you
can't
necessarily
share
at
GitHub.
B
So
I
think
that
that
there
is
a
lot
of
value
there
in
just
creating
the
connections
and
and
making.
You
know
those
channels
for
discussion.
Even
if
it's
not
like
you
know,
by
some
sort
of
means
of
authority,.
C
I
C
Incident,
we
don't
have
the
resources
for
this
help,
like
you
know,
and
then
I've
had
people
show
up
from
GitHub
and
jump
on
calls
and
be
like
here's.
How
to
deal
with
this
incident
that
you're
actively
going
through
as
a
package
maintainer
so
having
those
people
that
you
can
reach
out
to
privately
in
this
space
is,
is
you
know,
I
found
those
connections
privately
before
this
group
existed,
but
please
I
mean
you
know
within
the
bounds
of
what
your
corporate
life
lets.
C
You
tell
like
tell
other
people
these
people
can
help
you
with
you
know
my
world's
on
fire.
I
need
help,
sort
of
you
know,
connections.
B
A
Want
to
make
sure
we
don't
miss
Zach's
call
to
action,
which
was
to
yes
from
some
folks
we
haven't
heard
from
since
we
have
about
four
minutes
left.
C
What
about
this
working
group
entices
you
all
to
to
you,
know
three
people
dedicate
from
a
single
company
dedicated
to
a
single.
This
calls
there's
a
lot
of
resources.
What
what
is
enticing
you
guys
to
be
a
part
of
this.
This
conversation
here.
D
E
Yeah
so
I
think
for
us,
because
we
do
touch
everything
we
need
to
know.
What's
going
on
and
I
think
you
know,
part
of
the
issue
that
we
all
have
is
when
we
have
an
update,
is
getting
to
the
right
people
to
make
sure
that
they
know
what's
going
on,
and
we
had.
You
know
some
issues
when
we
deprecated
J
Center
or
not:
J,
Center,
I'm,
sorry,
Ben
Trey,
and
basically
we
don't
want
to
lose
anybody.
E
We
don't
want
to
get
anybody
lost
and
we
want
to
make
sure
that
we're
in
the
conversation
to
make
sure
we
can
make
things
work
right
on
our
end,
if
something
were
to
happen
to
make
sure
that
we're
on
the
right
track
in
terms
of
policies,
compliance
all
of
that
kind
of
stuff
and
just
get
to
know
the
maintainers.
So
if
there's
something
happening
within
a
package
type,
we
can
make
sure
we
address
it
head
on.
I.
E
Think
the
big
thing
that
I've
realized
across
the
board
in
Tech
is
communication
is
the
hardest
thing
and
it's
the
most
important
thing.
So
if
there's
an
update
to
npm-
and
we
don't
know
about
it
and
all
of
a
sudden
artifacts
are
gone
missing
or
something
it's
because
we
weren't
aware
and
miles's
team
might
have
sent
an
email
to
the
wrong
person
that
doesn't
work
here
anymore
or
something
like
that.
E
So
I
think
that's
our
main
goal
of
getting
more
involved
in
community
working
groups
and
sigs
like
this
is
to
make
sure
that
we're
able
to
handle
anything
that
happens
down
the
pipeline
and
then
lead
our
recommendations
as
well.
That
we
think
you
know
based
on
our
experience.
What
could
help
move
things
forward?
E
I
don't
mean
to
speak
for
you
so
hard
for
Adam,
but
that's
just
kind
of
why
I
think
that
we're
here
in
big
numbers,
you're.
I
A
All
right
we're
just
coming
up
on
the
hour
now,
unfortunately,
we
didn't
get
to
discuss
the
fundable
question,
though
yeah
look
at
the
attestations,
but
we
can
pick
those
up
next
week.
I
think
they're
also
useful
reading
as
well
I,
really
like
the
Pi
Pi
fundables
idea,
it's
great.
A
So
the
next
meeting
will
be
at
the
APAC
time,
which
is
for
those
of
us
on
the
east
coast
of
the
US
or
North.
America
really
will
be
at
2
at
6
p.m.
I
think
yeah,
oh
I'm,
not
sure.
A
Anyway,
it's
on
the
calendar,
you
get
the
idea,
there's
also,
as
I
noted,
the
Sig,
which
is
looking
at
the
artifact
audit
I,
think
it's
definitely
something
that
spurred
a
lot
of
discussion
today,
so
I
hope
to
see
you
all
again
at
the
the
next
Sig
call,
which
I
believe
is
next
week
at
this
time,
but
I
would
have
to
check
the
calendar
to
be
sure.
Yes,.
C
B
Quick
call
out
before
we
break
I,
don't
know
if
we've
recently
done
a
survey
to
like
reevaluate
the
times,
but
the
current
time
is
just
like
do
not
work
for
me,
which
is
part
of
the
reason
why
I
haven't
been
able
to
come
and
I'm,
not
saying
like
hey
change
the
times.
B
A
Was
about
to
say
you
should
bring
that
up
at
the
next
meeting,
but
that
that's
kind
of
like
a
circular
problem.
There
is
a
mailing
list.
Can
you
bring
that
issue
up
on
the
mailing
list
for
us
and
we
can
I
can
find
out
how
you
create
one
of
the
doodle
polls
and
we
can
try
to
figure
that
out.