►
A
B
A
C
A
B
A
C
B
A
B
B
C
C
B
A
I
I
misleadingly
made
the
first
word
of
this
action
item
someone
else's
name,
but
we've
been
spending
a
bunch
of
time
in
the
past
couple
of
weeks.
Couple
months.
Talking
about
this,
this
threat
of
domain
resurrection,
attacks
quote
unquote
and
so
that
the
sort
of
classic
example
is
I
sign
up
for
my
rubygems
account
with
a
vanity
email
domain,
and
then
I
go.
I
don't
know,
stop
programming,
stop
renewing
my
domain.
A
My
registration
lapses.
Someone
else
snaps
up
that
domain.
They
run
the
password
reset
flow
on
rubygems
and
the
password
recovery.
Email
gets
sent
to
a
new
person
who
is
not
me
and
should
not
be
publishing
packages
under
under
my
name,
and
so
we've
been
discussing
a
lot
of
potential
mitigations
potential
ways
to
detect
this,
but
we
were
realizing.
We
don't
really
understand
very
well
how
widespread
this
problem
is.
A
That
would
give
us
some
some
insight
into
this,
and
and
so
that
that
I
suppose,
is
yeah.
So
that'll
that'll
come
in
the
next
couple
of
days
and
it'll
be
done
in
a
way
where
you
can
run
it
yourself.
You
don't
have
to
you
know,
share
any
any
information
which
might
might
be
sensitive,
but
we
can
get
some
interesting
act
or
get
statistics
to
really
within
this
group
understand
the
problem
so
expect
that,
in
the
in
the
slack
and
and
maybe
in
in
the
email
group.
B
Yeah,
that
was
one
of
the
questions
I
remember
when
we
discussed
this
last
time
was
how
prevalent
is
it
actually
very
high
profile
when
it
happens,
but
next
one
I
see
is
jason
has
a
java
specific
doc.
I
don't
see
jason
here
today,
so
I
think
we'll
have
to
skip
over
that
one.
It
might
be
the
same
with
alex
and
patrick
and
brandon.
So
I
think,
unfortunately,
we've
burned
through
the
action
items
unless
anyone
could
speak
up
for
one
of
those
folks.
E
Sorry,
I'm
having
some
internet
issues
right
now.
I
don't
really
know
what
the
json
doc
is,
so
we
so
we
just
as
an
update.
We
did
sort
of
come
to
resolution
on
the
multi-artifact
thing
we're
going
forward
with
with
signing
like
every
artifact,
because
we've
sort
of
established
that
that's
not
really
a
problem
on
the
recourse
side
and
simpler
for
us
to
to
go
that
way.
Right
now.
E
What
we're
looking
at
is
trying
to
come
up
with
a
kind
of
something
that
makes
sense
for
java
as
like
a
format
for
making
sure
that
we
store
all
the
bits
that
we
need
to
do
offline
verification,
because
that
might
be
a
concern
in
the
long
run,
and
we
also
want
to
share
that
doc
with
the
other
package
manager
so
that
we
can
might
like.
We
might
consider
sort
of
doing
the
same
thing
across
the
different
languages.
B
C
A
Yeah,
I
I
can
speak
to
jason's
document
it
it's
very
complementary
to
the
existing
domain
resurrection,
doc
that
I
wrote
just
with
some
java
specific
flavor.
So
I
I
think
we
can
just
go
ahead
and
give
jason
swank
is
the
one
responsible
for
that.
So
I'll
give
him
another
ping,
and
hopefully
he'll
share
it
out
with
the
group.
F
A
F
A
B
Cool
before
I
announce
again
that
the
first
item
is
mine,
is
there
anything
else
that
folks
had
from
the
action
items
that
they
could
bring
up
or
cover
or
wanted
to
ask
a
question
about
that?
Maybe
we
could
answer
I'll.
Take
that
as
a
no
all
right,
so
the
first
one
here
it
says
asking
for
help
with
domain
monitoring.
I
wish
jacques
had
had
left
more
detail
than
detailed
notes
about
what
he
meant,
but
if
I
had
to
take
a
guess,
this
is
probably
a
question
about
domain
experiences
with
domain
monitoring
services.
B
B
So
the
classic
example
is
multi-factor
authentication.
I
love
it,
you
love
it,
everyone
loves
it
and
then
they
lose
their
phone
and
they
don't
love
it
anymore
and
they
want
their
stuff
to
be
reset
and
so
there's
a
support
burden
to
fix
it,
but
also
to
ensure
that
you're
not
being
so
like.
What's
it
called
socially
engineered
as
a
support
person,
because
bad
people
can
be
very
persuasive,
I
think
miles
was
looking
for
other
experiences.
I
don't
see
I
mean
apart
from
joel
and
patrick.
B
A
A
A
lot
of
the
other
repositories
are
volunteer,
run
for
the
most
part,
and
so
we
just
wanted
to
float
the
idea
of
perhaps
the
open,
ssf
being
the
vehicle
through
which
these
volunteer
run
repositories
get
you
know,
perhaps
support
staff
and
common
practices
there
and
and
sort
of
perhaps
some
economies
of
scale
when
it
comes
to
when
it
comes
to.
You
know,
identity,
verification
and
so
on.
D
Yeah-
and
the
only
thing
I
was
going
to
say
is
like
our
our
little
corner
of
the
world
is
very
small
and
we
have
like
a
person
a
week
who
spends
not
even
half
time
dealing
with
with
requests
that
come
in
and
and
but
we
also
also
offload
like
a
lot
of
stuff
onto
like
github,
logins
and
stuff.
So
we
don't
even
have
2fa
really
stuff
to
worry
about
right
now,
even
though
we
should
but
yeah
another
problem.
B
B
One
question
they
had
for
the
group
was:
what,
if
anything,
do
you
expect
has
to
be
done,
like
from
the
perspective
of
a
repo
maintainer
who's
relying
on
sex
store
like
what?
What
do
you
feel
is
like
a
non-negotiable
minimum
that
folks
need
to
achieve,
and
there
was
there
was
some
discussion
around
like
what
slos
should
be
targeted
for
these.
For
these
services,
like
what
slos
are
required
to
be
effective,
I
think
that
we're
targeting
maybe
zach.
You
remember
this.
I
think
I'm
targeting
like
three
nines
or
four
nines.
A
B
Okay,
yeah,
that's
not
too
bad.
I
mean
it'll
it'll
break
a
few
builds
from
time
to
time,
but
you
know
we
can
aspire
to
higher
nines
as
time
goes
on,
but
also
I
guess
the
question
was
like:
was
there
anything
else
people
can
think
of
off
the
top
of
their
head?
Where
they've
been
saying,
oh
we've
been
waiting
for
x
or
you
know
I'd
be
surprised.
B
G
G
G
G
Do
we
are
we
comfortable,
saying
yeah
like
take
this
on
use
it
in
you
know,
there's
a
foul
closed
dependency
in
in
critical
flows,
or
you
know
some
bar
in
between,
because
we
have.
You
know
it's
possible
that
things
go
wrong
leading
up
to
ga,
and
you
know
we
have
significant
outages
in
in
the
meantime.
C
Do
we
have
a
strategy
for
sort
of
like
dark
rollouts
for
six
door,
support
and
package
managers,
or
something
along
those
lines
where
it's
sort
of
soft
and
not
it's,
it
fails
open.
First,
will
the
dead
bake
for
a
quarter
see
how
that
goes
and
then
sort
of
and
make
it
fail
close
after
that,
once
we
sort
of
ironed
out
all
the
issues?
B
For
for
ruby,
at
least
when
we
wrote
the
rfc,
that's
that's
still
open.
The
plan
we
had
was
to
roll
it
out.
First
of
all,
as
an
optional
thing,
you
could
do
you
didn't
you
weren't,
forced
to
sign
you
weren't
first
forced
to
verify
you
could
choose
to
do
either
of
those
things,
and
probably
I
would
have
used
my
super
secret
handshake
powers
to
get
the
folks
who
work
on
rails
to
exercise
it,
because
that's
a
nice
high
profile,
high
traffic
sort
of
thing
to
to
try
it
out
on.
B
A
Can
I
ask
a
related
question
so
for
the
folks
who
are
running
repositories
here?
Do
you
offer
any
kind
of
slo
or
and
whether
or
not
you
are
do
you
have
an
understanding
of
what
kind
of
uptime
your
repository
has?
Because
you
know,
for
instance,
if
there's
no
slo-
and
you
know
I
don't
want
to
pick
on
anyone,
but
you
know,
programming
language
x,
repository
is
down,
for
you
know
four
hours
a
day
like
like
six
store,
isn't
really
the
blocker
there.
F
But
the
download
side's
always
up
thanks
to
facts,
we've
gotten
a
lot
better
on
the
published
side.
Now
we've
got
more
scale,
but
you
know
we
also
have
people
right.
You
know
the
advantage
of
having
staff
that
we
dedicate
to
keeping
the
lights
on,
but
certainly
a
number
communicating
to
people.
I
mean
if
you
look
at
status.name.org
you'll
see
some
of
the
numbers
we
track,
but
there's
non-macroeconomic
number
associated
with
that,
but
we
at
least
share
the
graph.
F
Let
me
just
log
in
right
now,
so
we
the
numbers.
Well,
let
me
just
share
what
what
the
numbers
are,
and
so
we
have
a
roll-up
across
to
the
two
main
publishing
hosts
of
uptime
for
the
hosts
themselves,
and
then
we
put
this,
you
know
line
for
the
cdn,
so
fastly
and
then
searches,
uptime
and
so
everything's
been
been
green.
F
So,
let's
see
it
looks
like
I
can
share,
can
folks
see
sabotageman.org,
and
so
you
know
fastly
everybody
remembers
when
they
went
down,
but
this
thing
should
always
be
at
100
and
I'm
amazed
at
oss.
It's
99.99,
that's
been
a
long
time
since
we've
been
that
green
and
then
we
we
share
this,
which
is
actually
some
stuff
that
drives
our
own
internal
monitors.
F
So
the
team
has
slos
that
you
use
amongst
ourselves
that
are,
in
fact
driven
by
published
latency
how
much
time
between
when
it's
released
and
when
it
shows
up
on
repo
one
and
then
staging
operation
duration,
which
is
essentially
from
when
you
trigger
a
staging
release
to
you
know
when
it
completes,
which
there's
a
hard
time
out
by
default
in
the
nexus
station
they
didn't
plug
in
over
300
seconds.
So
anytime,
we
are
in
the
double
digit.
F
The
time
which
means
that
we've
got
a
little
bit
of
pestilence
practice
that
we
got
to
get
into,
but
this
is
status
on
maven.org,
so
they're
actually
welcome.
Please
to
have
a
look,
and
you
know,
provide
feedback.
You
know
this.
We
drive
this
by
sad
page.io
account
that
insights
actually
has
for
our
other
products,
and
we
use
carve
out
a
piece
of
it
for
nathan,
central
and
the
supporting
services.
B
B
One
of
the
things
I
joked
about
recently
was
that
it's
sort
of
like
easy
to
get
a
large
technology
or
technology
using
firm
to
assign
developers
to
work
on
these
things,
but
it's
hard
to
get
them
to
assign
operational
or
devops
folks,
I'm
I'm
hoping
to
spread
that
thought
so
that
it
creates
a
vibe,
or
you
know,
a
wave
of
thinking
across
the
industry
that
oh
yeah.
We
also
need
operational
help
for
these
organizations.
I
know
I've
been
looking
at
that
at
my
end
as
well.
C
But,
but
to
come
back
to
original
sort
of
question
about
six
toys,
so
I
I
do.
We
really
want
to
sort
of
measure
it
against
sort
of
package
managers
and
and
instead
sort
of
have
our
own
slo
for
six
stores,
so
that
we
can,
you
know.
So
we
give
less
sort
of
reasons
for
folks
to
sort
of
drop,
using
six
toy
and
other
things,
because
it's
not
available.
For
example,
right.
G
Yeah,
I
mean,
I
think
we
I
think
sigstor
needs
to
have
target
slos
just
because
it's
critical
security
infrastructure
and
an
outage
is
really
blocking.
It
might
be
interesting
for
package
managers
to
separate
the
concerns
around
publishing
from
and
download
publishing.
You
know
the
the
I
imagine
qps
is
considerably
lower
than
than
download
and
the
impact
of
an
outage.
There
is
okay.
Well,
we
can't
publish
a
package
for
a
bit.
G
E
G
G
E
It
just
uses
the
it
just
looks
at
the
at
the
bundle
in
the
signature
in
the
container
registry
and
does
a
verification
using
that
bundle,
and
I
think
we've
come
to
a
conclusion.
That's
what
we
should
be
doing
by
default
and
for
all
the
languages,
because
otherwise
you'd
be
sending
quite
a
lot
of
load
to
to
recore.
E
G
G
B
B
So
in
that
respect
you
know,
assuming,
of
course
you
know,
you
trust
your
your
cdn
to
not
mark
it
up.
You
know
it's
sort
of
interesting
I
feel
like.
We
should
all
send
a
bouquet
to
fastly,
given
that
maven's
using
it
ruby
gems,
is
using
it.
I
know
pipeyi
uses
parsley
as
well
and
I
send
them
a
cake
or
something
like
I
think,
they're
in
new
york.
B
B
Yeah
okay
package
as
well,
that
makes
sense.
Okay,
so
is
there
more
that
we
want
to
talk
about
in
terms
of
like?
What's
coming
up
for
six
star
or
requests
that
we
might
have
questions
about
slos?
I
think
this
has
actually
been
a
productive
topic
of
conversation,
especially
the
spin-off
about
slos,
for
package
managers
themselves.
C
B
So
we've
got
a
request
here
from
brandon
who's,
not
here
today.
He
wants
us
to
have
a
look
at
a
survey
form,
so
you
may
recall
a
spreadsheet
that
was
circulated
earlier,
which
had
a
series
of
question
and
answer
sections
about
features
of
the
package
manager.
You
know
particular
experiences,
I
think
at
some
point.
We
also
added
some
some
questions
about.
B
D
So
if
you
need
access,
just
let
me
know
and
I'll
click
the
button.
What
I
can
do
is
maybe
send
this
out
to
the
mailing
list,
so
the
people
who
are
here
can
weigh
in
on
it
so
yeah.
I
I
see
that
there's
a
there
was
an
email
earlier
earlier
from
brandon
lum.
Is
that,
like
the
good
list
to
send
it,
send
it
to.
F
D
Yeah
so
yeah,
that's
what
I'll
do
I'll
send
it
out
to
the
mailing
list
and
see
if
we
can
get
other
ecosystems
to
fill
in
fill
in
some
terms
and
yeah?
My
idea
was
that
once
we
had
kind
of
a
few
different
ecosystems,
we
could
sort
of
distill
that
into
this
is
what
we
mean
when
we
we
talk
about
that.
If
there
is
a
common
common
definition
for
anything.
D
Yeah
the
way
the
document
is
set
up
right
now
is
just
like
each
word
has
a
section
for,
or
I
was
envisioning
having
a
section
for
each
ecosystem,
and
so
that's
like,
if,
like
your
ecosystem,
didn't
use
that
word,
you
would
just
say
this
is
what
we
call
the
same
thing
assuming
you
could
figure
out
what
that
is
from
looking
at
the
other,
the
other
ecosystem
definitions,
or
you
would
just
say
we
don't
have
that
you
know
in
in
our
ecosystem.
As
this
I
was
I
was
thinking,
it
was
going
to
work.
B
B
C
B
B
So
some
of
the
data
can
be
shared
publicly,
so
some
of
that
some
of
the
questions
are
not
sensitive.
Some
of
the
some
of
the
questions
are
very
sensitive
or
could
be
seen
as
sensitive.
So,
for
example,
asking
has
your
main
application
server
been
penetration
tested
with
most
like
a
lot
of
cases.
I
think
people
will
say
no
and
they
would
rather
not
publish
that
fact
right,
they'd,
rather
not
advertise
their
current
security
posture.
B
So
some
of
those
questions,
I
think,
will
not
be
published
or
will
only
be
shared
with.
You
know,
presumably
something
like
academics
or
other
trusted
individuals
and
groups,
but
then
there's
stuff,
like
you
know,
do
you
have
signing
implemented
and
most
or
many
package
ecosystems
have
some
sort
of
signing,
even
if
it's
not
widely
used
at
the
moment,
and
so
I
don't
think
that's
seen
as
a
sensitive
question.
A
Yeah
and
and
to
follow
up
on
how
the
data
will
be
used.
I
think
a
lot
of
it
is
just
for
our
understanding
in
this
group
of
of
what
what
sort
of
the
state
of
the
art
is
to
to
see.
You
know.
Are
there
particularly
popular
package
managers
that
don't
do
a
whole
lot
in
this
space
that
maybe
we
should
get
coming
to
these
meetings
or
yeah
and
just
again
more
to
like
monitor?
A
You
know
this
this
universe
than
anything
else
and
as
as
jacques
mentions,
I
think,
there's
also
potentially
some
interesting
stuff
that
we
could
be
could
be
published
and
shared
with
the
wider
world
to
raise.
You
know,
sort
of
awareness
of
efforts
in
the
space
and
so
on,
but,
but
mostly
just
I
find
at
least
when
I'm
thinking
about
problems
cutting
across
ecosystems.
A
It
would
be
really
really
nice
for
me
to
know
you
know:
hey
like
this
rep,
you
know,
x,
percent
of
these
top
repositories
have
this
thing
implemented,
so
maybe
it
is
worth
adding
at
you
know
an
effort
to
harden
that
up
or
whatever
yeah.
So
I
think
largely
in
this
group,
it's
very
useful
to
to
have
a
lot
of
those
answers.
B
Sorry,
I
didn't
mean
to
cut
you
off
yeah,
the
other.
The
other
use
you
can
see
being
a
possibility.
Is
that
as
we
develop,
that
that
sort
of
insight
into
the
ecosystem
of
ecosystems
that
provides
data
that
we
can
use
to
talk
to
the
tank
or
the
governing
board
to
claw
out
funding
for
like
one-off
projects,
to
implement
certain
capabilities.
B
So
while,
for
example,
you
know
many
ecosystems
have
a
mix
of
mostly
volunteers,
or
sometimes
they
have
like
a
patron
organization,
it's
going
to
be
all
over
the
place.
Sometimes,
you've
you've
got
a
an
uncle,
a
daddy
warbucks
sort
of
situation,
sometimes
there's
an
obscure
cut,
and
sometimes
sometimes
you
don't.