►
From YouTube: ClusterAPI Self Assessment Working Group 20220202
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
A
B
A
Okay
cool,
so
let
me
start
sharing
my
screen.
We
are
somewhat
in
a
slight
split
brain
scenario.
Right
now,
because
we
have
two
docs
one
is
the
hack
md,
which
will
get
converted
into
a
pr,
and
there
is
another
one
which
is
the
original
google
doc
that
we
have
been
working
on.
A
So
first
thing
is:
we
have
to
fill
mostly
most
of
the
stuff
in
google.
Doc
is
in
hack,
md
only
thing,
I
wasn't
sure
roberts
if
you
were
following
slack
or
not,
and
if
the
tables
that
you
were
working
on
for,
I
think
attack
trees.
If
I'm
not
wrong,
were
they
already
moved
to
the
hackmd,
or
should
we
do
that
quickly?.
C
It's
in
progress,
no,
it's
not
done.
I
moved
it
out
of
the
google
doc.
It's
just
working
progress,
though.
A
A
A
B
I've
done
a
big
chunk
of
them.
I
am
I
consolidated
the
data
flows
into
more
or
less
one
diagram,
because
it
was
just
so
much
overlap
so
and
so
try
to
create
like
break
out.
What
are
the
common
features
of
it
like
there's
some
things
that
always
happen
so
just
working
out
like
it's.
This
flow
refer
back
to
that,
instead
of
just
copy
pasting,
so
I've
up
I've
made
sure
the
language
is
correct
for
the
flows
as
well,
that
they're
accurately
describing
everything.
B
Okay-
and
I
I
was
literally
just
going
through
their
identified
gaps
pieces,
the
ones
that
we
had
and
was.
A
Okay
sounds
good,
so
I
think
for
folks
who
join,
maybe
for
the
first
time
might
be
good
to
give
a
quick
background
of
this
program
thing
that
we've
been
doing
for
a
while
and
where
it's
headed.
A
A
What,
after
discussing
it
with
tax
security
with
seek
security,
general
consensus
was
the
the
third
party
audit
for
kubernetes,
which
would
finish
or
start
this
year
would
be
scoped
very
tightly.
So
there
was
a
very
unlikely
chance
that
we
will
be
able
to
add
into
scope
for
the
whole
of
cluster
api
sub
project
so
because
of
that,
what
we
ended
up
deciding
is
let's
break
new
ground
and
essentially
create
some
sort
of
a
self-assessment
review
process
for
any
sub
project,
offer
kubernetes
scenes
or
a
cncf
graduated
project
like
kubernetes.
A
So
that's
where
we
started
so
for
some
folks
from
six
security.
Like
me,
robert
and
some
folks,
mostly
nadir
and
kita
lubumir
and
some
others
started
working
together
and
we
decided
okay,
let's
use
a
self-assessment
template
that
tag.
Security
has
and
using
that
start
assessing
what
we
need
to
do
for
cluster
api.
A
So
we
went
through
a
couple
of
data
flow
diagram
working
sessions
where
we
drew
a
few
diagrams
on
excali,
draw
very
manual
diagram,
nothing
yaml
or
anything
that
we
can
version
control
and
then
that
led
to
going
through
the
flows
and
trying
to
identify
what
are
my
vulnerable
data
flows?
What
are
the
threats
that
we
can
identify
and
based
on
that?
This
document
exists.
Now
we
are
here
now
the
goal
after
this
is
now
that
we
have
identified
all
the
threats.
A
The
final
goal
would
be,
we
know
the
possessible
mitigations
for
them,
so
each
threat
and
its
mitigation
will
get
converted
into
a
github
issue
on
cluster
api,
repo
or
any
relevant
other
repo,
like
cluster
api
aws,
for
example,
and
then
we
will
start
working
on
them
as
like
a
feature,
if
is
if
it
needs
a
design
proposal,
we
may
end
up
doing
that
as
well,
and
if
it's
a
small
changes
or
some
doc
changes,
which
we
also
realize
like
sometimes
we
might
have
to
tell
the
end
user,
like
if
you're
worried
about
security.
A
A
D
Yes,
I'm
here
david
just
stepped
away
for
one
second,
I
think
from
his
workstation,
but
he
is
also
here
in
a
few
minutes.
Yes,
how
is.
A
D
I
think
it's
it's
fine,
I
think
we'll
stay
for
the
entirety
of
the
meeting
and
we
can
take
the
fussing
a
little
later.
That
sounds
perfect
to
me.
A
Okay
sounds
good,
so
we'll
leave
maybe
20
minutes
at
the
end
of
the
meeting
for
fuzzing
discussion.
B
A
B
A
B
E
A
A
Yeah
well,
but
that's
a
good
call,
I
think.
As
long
as
the
folks
who
are
working
actively
are
there?
Oh
yeah,
I
see
david
is
back
so
david.
We
have
some
folks
from
sick
cluster
life
cycle
who
would
be
able
to
give
more
background
on
fuzzing
from
their
side
and
they
have
to
leave
in
like
20
minutes
or
so
so.
We
thought
we'll
discuss
that
first
and
then
cover
our
usual
stuff
later.
A
So
maybe,
if
maybe
for
everyone
to
kind
of
know
what
we
are,
maybe
hoping
to
do-
robert
adam
or
david,
if
you
have
some
context
on
like
what
kind
of
fuzzing
work
was
done
before
with
other
projects
and
what
was
the
outcome
of
it,
how
it
kind
of
benefited
the
project?
I
think
that
will
be
something
very
useful
for
everyone
to
know.
F
Yeah,
I
can,
I
can
introduce
that.
So
if
you
see
this
link
here,
there's
a
github
repository
on
the
cncf
project,
which
helps,
which
essentially
is
only
about
cncf
fusing
and
it's
fascinating
various
projects
and
there's
been
a
bunch
of
work
done
the
last
two
years
or
so
on
getting
fasting
integrated
into
various
ctf
projects
and
in
particular,
in
the
last
year,
there
has
been
a
lot
of
focus
on
getting
the
fasting
integrated
such
that
it
will
run
by
way
of
oss
first
and
oss.
F
So
the
goal
of
doing
fussing
of
a
cncf
project
is
often
integrate
a
set
of
fusses,
which
are
just
kind
of
like
test
cases,
type
of
style
and
integrate
it
also
such
that
it
can
run
with
the
recess
first
and
then
box
will
just
like
be
reported
whenever
they
are
found,
and
it
has
been.
This
has
been
done
for
quite
a
few
of
the
cncf
projects.
F
What
is
this
first?
So,
for
example,
if
you
see
this
link
here,
which
is
all
of
the
bugs
found
by
all
this
first
in
the
envoy
project,
you
can
see
that
there
should
be
about
so
so
this
is
actually
so.
This
is
the
open
issues.
I
should
probably
send
another
link,
so
in
the
second
link
here
in
the
second
link.
That's
all
of
the
issues
found
by
fostering
was
this
first
in
in
in
envoy,
and
you
can
see
that
there's
just
about
a
thousand
bucks
found
within
an
envoy.
F
F
F
For
example,
you
will
see
a
lot
of
fusses
within
that
folder
and
these
because
there's
a
lot
so
like
it's
faster
to
iterate
over
developing
new
fusses.
If
we
just
keep
it
on
the
cncf
repo,
I
don't
know
if
you
see
the
latest
link
with
the
prop
yeah
and
then,
if
you
go
into
the
projects
folder
on
the
github
repository.
F
So
we
are
very
accustomed
to
that
and
the
only
thing
we
actually
need
in
order
to
get
this
started
is
just
a
set
of
emails
to
the
developers
that
will
be
receiving
the
bug
reports.
So
whenever
osos
finds
a
bug,
it
will
send
out
an
email,
and
this
email
will
have
a
link
to
some
detailed
reports.
Such
a
that
will
include
stack
traces
that
will
so
like
have
the
test
case
triggering
and
stuff
like
that.
So
it's
just
like
how
to
reproduce,
debug
and
stuff
like
that.
F
So
that's
essentially
the
only
thing
we
need
in
order
to
get
started
and
so
yeah.
If,
if
we
get
a
set
of
emails
and
then
we
will
essentially
start
doing
the
work
and
follow
the
the
steps
I
have
done
here
and
then
we
can
always
just
join
one
of
the
next
meetings
and
so
on,
where
we
can
and
obviously
a
set
of
of,
we
can
also
just
communicate
over
email
or
slack
or
whatever.
A
E
So
what
I'm
wondering
is,
why
is
it
in
a
separate
repository?
So
usually
our
tests
are
just
inside
of
a
possibly
run
on
hpr,
et
cetera
such
as
that
I
don't
know
they
have
to
run
continuously
to
find
more
things,
or
is
it
just
that?
I
don't
know
it's
in.
G
F
That
infrastructure
statistics
it's
logistics,
some
of
the
projects
have
a
very
long
time
of
merging
in
so,
for
example,
kubernetes
it
can
take.
I
don't
know
many
months
just
to
get
a
single
thruster
in
and
because
and
that's
kind
of
like.
That's,
that's
the
that's
the
scenario
there.
There
is
also
the
other
aspect.
For
example,
we
need
is,
they
want
to
show
all
dependencies
are
within
the
project
and
so
on,
and
sometimes
it's
not
just
nice
to
keep
them
separate,
because
then
we
don't
have
to
deal
with
those
types
of
issues.
F
So
the
recommendation,
so
it's
to
speed
up
the
process
to
speed
up
the
process
of
reaching
a
state
of
mature
forces
and
then
once
that
is
done,
the
recommendation
is
to
get
it
all
upstream.
So
it's
just
to
make
make
rapid
development
quicker,
because
there
can
be
a
bit
of
a
burden
in
terms
of
reviewing
prs
with
fusses,
that's
kind
of
the
scenario.
F
So,
for
example,
we
have
just
integrated
the
arco
project
into
a
zest
first
and
we
we
have
developed
32
fusses
for
this
project,
and
some
of
them
are
difficult
to
understand
to
take
several
iterations
on
and
we
had
to
do
this
within
kind
of
like
a
span
of
30
days.
Basically,
so
there
can
be
a
lot
of
overhead
from
a
review
process
for
the
maintainers,
and
this
is
sometimes
an
annoyance
and
so
on.
F
So
it's
it's
to
keep
things
easy
to
develop,
but
we
do
recommend
once
it
has
reached
a
a
stable
state
to
get
upstream
and
and
essentially
do.
However,
you
guys
like
it
so
that
that
is
the
recommendation
if
you
would
prefer
to
have
the
fusses
in
your
own
repository,
do
that
if
you
prefer
to
have
them
in
a
different
repository,
but
under
your
own
account
do
that
and
all
this
kind
of
stuff,
that's
probably
fine,.
E
Okay
sounds
reasonably
reasonable
to
me
to
to
start
that
way
and
yeah
figure
out
where
we
placed
in
long
term.
How
do
you
identify
which
parts
of
the
code
base
you
would
fast?
I
mean
cluster.
Bayer
has
a
bunch
of
public
stuff.
I
don't
know.
Is
it
like
looking
at
especially
critical
areas
and
picking
them
and
then
fussing
doors.
F
It's
a
mix
of
things,
so
I
think
that
there
are
certain
several
heuristics
we
use.
One
of
them
is
what
you
tell
us.
If
you
tell
us
hey
this,
this
particular
code
is
very
important.
Could
you
focus
on
that?
That's
one
one
way
we
write
them.
Another
way
is
we
we
write
what
we
think
where
the
fossils
will
perform.
Well.
So
if
there
is,
for
example,
some
passing
code,
that's
traditionally
really
easy,
like
that's.
F
A
fossa
is
good
to
analyze
that
so,
if
there's
passes,
we
will
write
fossils
for
them
so
like
instantaneously
and
then
obviously
the
third
one
is
identify
where
our
untrusted
inputs
coming
from
and
then
writing
forces
that
simulate
untrusted
input
into
the
code.
So
it's
a
wide
range
of
things.
Some
of
the
fossils
are
more
like
integration,
end-to-end
type
of
testing,
whereas
others
are
very
niche
targeting
a
specific
piece
of
the
code
and
so
on.
F
F
Yeah,
so
that's
that's
something
where
you
have
to
be
super
important
like
where
you
have
to
be
involved.
So
what
you
will
get
is
you'll
get
a
stack
trace,
so
you
can
very
quickly
see
what
part
of
the
code
is
it
that
there's
a
bargain
you'll
get
a
full
stack
trace
with
it
input
the
triggers
it
and
you
can
reboot
reproduce
very
easily
and
that
element
of
then
assessing.
How
important
is
this
for
the
secure
security
of
the
project
is
something
you
will
have
to
do.
We
don't
really
do
that.
F
We
can't
give
give
help
and
so
on,
but
that's
not
the
main
focus
of
us
when
we
write
the
fusses
and
also
because
some
of
them
are
very
like
it
can
be
on
the
it's
like
rarely
very
difficult
to
assess
what
are
the
implications
of
a
certain
bug
and
most
important
like
most
often,
our
focus
is
on
writing
the
verses,
helping
with
mitigations
so
like
fixes
and
so
on,
and
and
that's
kind
of
it.
The
assessment
of
the
security
criticality
of
each
bug
is
not
something
we
usually
go
too
much
into
yeah.
C
A
F
So
the
the
process
generally
follows
the
oss
process,
and
that
process
is
essentially
the
fusses
are
run
on
google's
machines.
They
find
a
bug,
they
will
send
out
an
email
and
that
email
will
have
and
with
with
details
and
so
on,
and
then
there
will
be
a
90-day
disclosure
deadline.
That
means
about
the
details.
Some
of
the
details,
not
all
of
the
details.
F
In
fact,
only
a
small
amount
of
the
details
will
be
made
public
after
90
days,
even
if
it's
not
fixed,
and
you
will
then
have
the
time
to
so,
like
you
know
fix
it,
you
can
ask
for
extensions
on
on
the
deadline
if
that
sort
of
thing-
and
that's
essentially
that's
kind
of
what
it
stops
now,
if
you
determine
that
something
is
a
security
vulnerability,
it's
kind
of
handled
on
a
project
by
project
basis,
how
you
tell
your
customers
that
and
some
projects
you
know,
follow
various
processes,
but
that's
kind
of
like
we
usually
don't
reach
that
like
go
to
that
part
of
the
stage
we
go
to
report
in
the
box
and
and
developing
tools
that
find
the
box
and
then
the
rest
of
the
face
is
kind
of
like
where
you
you
guys,
will
proceed
and
that's
also
how
the
other
projects
are
doing
it.
F
A
F
Most
likely
they
are
similar,
they
are
related
those
teams
and
they
probably
collaborate
in
the
back
end.
But
but
no
it's
it's
a
different
team
and
this
is
more
an
open
source
security
team
that
runs
this
oss.
First.
A
Right,
nice,
okay,
that's
good
to
know
so
looks
like
at
best.
We
should
triage
everything
in
90
days,
so
that
nothing
goes
public
before
that,
or
at
least
the
at
least.
The
triage
should
involve
the
severity
rating
identification
like
at
least
if
we
have
found
something
critical
or
high.
Let's
get
those
fixed
and
the
other
ones,
maybe
even
if
they're
public,
we
can
track
them
through
github
issues
or
something
like
that.
That
seems
yeah.
F
That's
what
some
people
do
and
some
people
like,
I
think
when
it
starts
to
get
really
integrated
into
it.
It
just
becomes
the
way
this
fussing
is
used
is
really
just
find
the
issue
and
report
details
about
the
issue
and
then
all
the
rest
is
handled.
Some
people
do
get
up.
Some
people
just
use
the
like
monorail
dashboard
so
offered
by
or
says.
First
some
don't
report
the
vulnerabilities
or
obviously
we
don't
recommend
that.
F
But
it's
it's
more
about
getting
to
the
stage
of
finding
and
giving
enough
details
to
do
easy
root,
cause
analysis
about
the
bug,
and
then
you
have
to
kind
of
like
decide
that
that's
the
end
of
this
standardization
in
a
sense
right
right,
makes
sense.
There
are
some
other.
F
Obviously
there
are
some
other
projects
that
it's
like
promote
some
ways
of
doing
this,
and
that's
we
can
help
with
that
as
well,
but
it's
kind
of
a
different
procedure
so,
for
example,
there's
this
open
source
security
foundation,
which
is
promoting
a
lot
of
how
do
you
report
the
vulnerabilities
and
security
issues
in
a
manner
that
can
easily
be
digested
and
all
these
kind
of
things?
But
that's
different,
like
that's
a
separate
issue
to
the
first
one.
A
E
I
think
one
obvious
question
is
next
steps,
but
I'm
not
sure
what
what
the
plan
was.
I'm
just
joined
this
meeting.
I.
F
Think
I
think
if
you
guys
are
happy,
then
I
will
just
reach
out
to
the,
because
we
work
mainly
with
the
linux
foundation
and
they
are
the
ones
that
so
like
sponsoring
all
of
this,
and
we
have
various
arrangements
with
with
them.
So
I
could
just
shoot
an
email
to
the
relevant
person
and
yeah
just
essentially
handle
it
from
there,
sometimes
yeah.
So
the
way
we
handle
each
project
depends,
but
let's
assume,
because
they
were
already-
they
already
said.
F
Yes,
let's
go
so,
let's
just
assume,
that's
we
will
go
and
then,
from
our
point
of
view,
it's
just
let's,
let's
if
we
can
get
an
email,
a
cert,
if
we
can
get
a
list
of
emails
that
are
to
receive
books,
then
we
will
simply
start
doing
all
of
the
work
and
then
it
will
also
become
very
clear.
What's
actually
going
on
once
we
do
that
we
will
update
you
either
through
email
or
by
slack
tell
us
in
the
email.
F
When
you
send
the
list
of
emails,
we
can
update
you
wherever
you
prefer
in
terms
of
of
the
progress
and
state
and
so
on,
and
then
what
will
happen
is
I
haven't
looked
at
the
code
itself
yet
so
I
can't
really
determine
the
scope,
but
usually
we'll
we
would.
We
aim
to
to
finish
it
or
at
least
come
to
a
very
mature
state
in
a
month
or
so
so
it
can
go
fairly
fast.
A
B
B
B
A
All
right,
I
think
this
was
very
helpful
thanks
a
lot.
Oh
sorry,
you
you're
saying
something
david.
F
So
yeah
I
was
just
gonna
clarify
the
next
step,
so
the
next
step
is
for
me
now
to
receive
an
email
from
you.
If
you're
happy
with
this
and
the
list
of
emails,
then-
and
if
you
are,
then
I
will
make
make
things
happen
in
the
back
end
and
we'll
start
doing
it.
Is
that
correct,
understood.
F
A
Sorry,
yes,
and
we
also
have
an
action
item
of
the
self-assessment
where
we
wanted
to
revisit
how
we
are
managing
vulnerabilities
and
disclosing
it.
How
do
how
does
src
from
kubernetes
connect
to
us
so
as
part
of
that,
I
think
one
thing
seems
like
would
be
reasonable,
is
creating
a
private
google
group
under
kubernetes
dot
io,
where
maintainers
and
relevant
folks
can
be,
and
we
can
give
that
email
address
to
you
so
that
you
have.
F
Yes,
but
I'm
not
sure
that's
the
right
move,
mainly
because
so
you're
you're
about
setting
up
an
email
to
like
a
group's
email
address
that
will
receive
the
emails
that
won't
really
work
because
you
need
to
so
what
happens?
Is
you
get
an
email
that
will
have
links
to
details
and
these
links
you
have
to
access,
but
in
order
to
access
those
links
you
need
to
have
a
google
affiliated
account
to
see
the
details.
So
if.
F
Still
need
to
have
the
the
list
of
emails,
but
just
to
clarify
this
list
of
emails
is
very
so
like
it's
very
simple
to
edit.
So
on.
There
is
this
first
repository,
there's
a
project
jammel
for
each
for
each
project
and
you
can
just
send
a
pull
request,
add
an
email
or
remove
email,
and
they
will
sort
of
be
discarded
from
that.
So
it
is
generally
recommended
to
have
a
list
of
personal
emails
for
for
for
the
maintainers
and
also
just
to
clarify
the
first
will
not
just
find
security
vulnerabilities.
F
In
fact,
most
of
them
will
be
reliability
issues
as
well.
So
just
just
to
to
be
aware
of
that
that
there
will
be
a
bunch
of
issues
and-
and
certainly
not
all
of
them
will
be
securely
related.
A
Yeah
yeah,
I
think
that's
that's
a
good
point.
I
know
some
folks
have
to
drop
off
so
thanks
so
much
stefan
and
killian,
and
everyone
else
who
joined.
E
F
Very
nice,
being
you
all,
I
think
I
think
we
will
jump
off
now,
but
I
will
be
awaiting
your
email
and
then
to
get
them
there.
A
B
A
Yeah,
I
think
yes,
more
fuzzing
the
better
and
if
somebody
is
going
to
pay
professionals
to
do
it
probably
will
always
be
useful
yeah.
So
that's
good
okay,
so
I
think
we
I'm
sharing
the
doc.
Let
me
know
if
the
font
and
the
size
is
okay,
I
probably
switch
to
view
and
well
what
does
everyone
want
to
discuss?
I
have
some
thoughts
but
want
to
hear
from
you
any
pending
or
burning
questions
that
we
should
tackle.
First.
G
A
B
A
A
B
A
Not
that
bad,
to
be
honest,
I
mean
I'm
remembering
the
first
ever
diagram.
We
looked
at
right.
That
was
my
spaghetti
bowl
yeah.
Compared
to
that
this
looks
much
better
so
anyway,
I
think
this
is
good.
Is
there
a
some?
What
what
does
mermaid
like
use
as
the
raw
data?
Is
it
a
yaml
file
or
something
else?
No
it.
If
you
click
on
edit,
you.
B
A
B
B
Yeah
and
I've
sort
of
made
sure
I've
like
going
great
yeah.
I
I
just
sort
of
the
clean
I
put
the
status
of
each
oh,
I
need
to
clean
up
three,
but
if
you
look
at
the
one
above,
for
instance,
there
was
a
bunch
of
recommendations.
Each
of
those
are
in
a
different,
have
a
different
state
rather
than
one
global
state.
So.
A
We
can
potentially
create
an
issue
and
close
it
saying
it's
implemented,
and
this
is
the
relevant
pr
or
we
can
just
keep
it
as
part
of
the
document.
B
I
haven't
opened
an
issue
for
those,
so
I
think
yes,
I
think
to
do,
is
to
link
these
all
up.
So
there's
one
thing.
A
Yeah,
okay,
that
works,
I
yeah,
so
I
I
the
way.
I'm
thinking
is
one
thread
one
issue
and
then
it
can
have
multiple
pr's.
If
there
are
multiple
mitigations
yeah,
that
would
be
fine
and
I'm
also
hoping
I
can
join
one
of
the
cluster
api
meetings.
I
think
it's
at
10
today,
every
week,
so
I'll
join
that
and
sort
of
review
it
with
everyone
who
is
around
if
that's
okay,
not
today,
but
some
other
day.
A
Okay
cool
what
else
so
this
is
to
do
so
I'll,
wait
another
for
your
thumbs
up
when
you're
done
with
these
I'll
start,
the
pr
work
until
then
I'll
wait
is
that
okay.
B
Yeah
yeah,
I
should
be
done
next
day
or
two
actually,
okay,.
A
A
A
A
There
was
something
written
down
with,
I
don't
know
who
wrote
it,
but
they
mentioned
that
we
don't
have
a
process
to.
I
write
that
yeah.
Okay,
we
don't
have
a
process
to
consume
anything
that
src
is
getting
as
like
a
from
hacker
hacker
hacker
rank.
No,
what's
it
called
some
some
tool,
third
party
tool
that
they
use
for
getting
public
findings
from
researchers.
A
So
we,
if
I
remember,
we
don't
have
a
way
to
consume
it
from
src,
because
we
don't
have
a
single
point
of
contact
or,
like
a
google
group,
that
I
was
mentioning,
so
we
can
discuss
that
a
bit
more
now,
if
folks
are
interested
like
how
to
go
about
that
as
because.
A
It
skipped
it
in
the
past
meetings
also
any
thoughts
or
robert.
Maybe
you
have
some
precedent
or
from
other
projects.
A
Yeah,
so
I
think
my
understanding
is
src
has
something
like
that,
something
like
security
at
kubernetes,
dot,
io,
and
then
it
has
a
list
of
members
who
are
part
of
src
who
receive
it
and
then
they
can
privately
discuss
it
and
once
they
find
that
something
is
relevant.
C
C
I
think
it's
the
same
question
as
right
on
the
last
discussion
about
fuzzing,
because
I
mean
I've
honestly,
I've
been
I've
trolled,
some
of
those
groups
that
are
either
public
or
had
been
invited
to,
and
you
know
you
see
things
in
there
where
researchers,
post
questions
and
then
two
years
go
by
nobody's,
read
it
so
and
even
some
of
the
researchers
you
know
are
diligently
asking
every
you
know
every
couple
of
months:
hey
guys
have
you
seen
this?
Have
you
seen
that
series?
And
then
you
know
yeah.
A
A
I
think
this
is
very
valid
point
and
I
think
most
open
source
projects
that
are
less
well-funded
or
like
have
lesser
contributors.
Definitely
this
happens.
A
I
I
also
saw
a
somewhat
similar
thing
in
container
d,
where
they
have
a
role
dedicated
called
security
liaison,
who
is
not
a
maintainer
or
doesn't
have
to
be,
but
they
are
responsible
for
active
communication
and
making
moving
things
forward
in
terms
of
if
researcher
has
sent
something
you
have
to
you
are
you
have
the
ball
and
then
you
take
care
of
all
the
communication
with
the
maintainers
you
keep
following
up
with
them.
Ask
more
questions
with
the
security
researcher
and
then
make
sure
that
it
sort
of
has
a
logical
end.
A
So
it's
somewhat
like
a
project
manager
or
program
manager
role,
but
that's
something
we
could
consider
since
I
would
imagine
at
least
in
the
beginning.
The
maintainers
would
want
to
be
part
of
that
list
and
then
maybe
hopefully,
when
there
are
a
lot
of
security,
focused
individuals
in
cluster
api
and
future,
they
can
take
over
from
maintainers.
C
Again,
if
they're
just
you
know,
I
mean
this
in
a
positive
way.
If
they're
a
proxy
to
the
maintainers,
you
know
the
maintainers
are
going
to
be
busy
fixing
bugs
adding
features
and
if
someone
essentially
doesn't
have
the
time
to
commit
to
being
a
maintainer
but
wants
to
be
involved
at
a
security
level
and
they're
attending
the
cappy
meetings.
So
that
might
be
an
opportunity
for
someone
who's.
You
know
maybe
at
one
of
the
larger
cloud
providers
interested
in
security
kind
of
sitting
in
the
security
meetings,
but
not
yet
actively
engaged.
A
Yeah
yeah,
probably
I
can
bring
it
up
in
our
next
security
meeting,
maybe
cluster.
If
the
lifecycle
folks
can
do
the
same
for
their
meeting
in
couple
of
weeks
or
so.
G
Even
I
have
not
been
attending
cluster
api
meeting
because
of
the
time.
Oh
it's
the
time.
B
G
B
All
right
I'll
take
an
action.
I
am
to
find
someone
who
is
either.
I
I
guess
it's
going
to
have
to
be
emea
or
us.
I
suppose.
A
And
I
think,
ideally,
if
the
liaison
are
not
just
one
person
but
two,
they
can
go
on
vacations
when
somebody
is
around
for
them
to
take
over,
instead
of
it
falling
back
on
a
maintainer.
So.
F
A
C
Be
great
if
you
can
find
two,
I
just
want
you
know
realistically
you're
gonna
be
lucky
to
find
one
and-
and
you
know,
there's
there's
not
gonna
be
a
case
where
it's
not
like
a
corporate
security
response
where
you're
gonna
get
an
immediate.
You
know
24-hour
response
time.
It's
you
know.
If
somebody's
on
vacation
for
a
couple
weeks,
then
that's
not
a
problem
now.
If
someone
just
drops
off
and
doesn't
participate
anymore
doesn't
tell
anyone
gets
a
new
job
in
a
different
industry
and
you
never
hear
from
them
again.
C
That's
a
that's,
maybe
a
more
concerning
edge
case
yeah.
As
long
as
we
find
someone
who's
at
least
willing
to
commit
to
kind
of
a
handshake
protocol
where,
if
they
they
take
the
responsibility
they
check
in
when
they
you
know
they
attend
the
meetings
as
best
they
can.
They
try
to
find
coverage.
If
they're
going
to
be
out
for
an
extended
period,
and
then
you
know
if
they
decide
it's
no
longer
a
good
fit
for
their
schedule
or
for
their
situation.
They
they
officially,
you
know,
notify
the
project
that
hey.
C
A
Yeah
container
id
actually
has
a
good
list
of
roles
and
responsibilities,
including
this
role
so
I'll
link
it
somewhere
in
slack
or
other
places.
Another
thing
I'll
take
an
action
item.
I'm
thinking
he
opened.
Two
thoughts
was
sharing
this
sort
of
proposal
for
a
sub
project
to
kubernetes,
src
and
saying:
hey
we
are
thinking
of
doing
this
did
have
has
any
other
sub
project
done
it
do
you
have
any
thoughts
based
on
your
experience
and
then
kind
of
just
get
their
feelings,
thoughts
and
suggestions
that
we
they
may
have.
B
Yeah
yeah,
if
another
sub
project
has
already
done
something
good,
let's
not
reinvent
it,
we'll
like
make
it
make
it
standard
across
the
sub
projects.
Yeah.
A
Yeah
yeah
agree
so
in
in
that
case
like
today,
if
I
am
a
researcher
I
have
to,
I
found
a
vulnerability
in
cluster
api.
What's
my
way
of
reaching
out
to
the
maintainer.
B
Security.Md
is
supposed
to
be
valid,
but
it
obviously
isn't.
I
see
I
thought
I
thought
there
was
some
discussion
in.
I
don't.
Is
there
there's
a
sig
for
the
chairs
right
for
the
sake,
for
the
sake
chairs,
yes
or
something,
and
I
think
there
was
some
discussion
about
getting
all
that
updated.
It
looks
like.
A
It
hasn't
been
done
yeah
if
I,
if
you're
talking
about
like
the
meeting
that
happened
maybe
couple
of
weeks
ago,
where
the
six
security
folks
joined
the
chairs
and
tech
leads
meeting.
A
Okay,
so
I
think
it
was
mostly
about
like
hey
what
what's
the
difference
between
six
security
and
src.
When
should
you
reach
out
to
src?
When
should
you
reach
out
to
six
security
if
src
is
reaching
out
to
your
sake,
this
is
it's
probably
more
important
than
security
reaching
out
to
your
sick?
So
those
were,
I
think,
the
discussion
topics
that
they
did.
I
don't
think
I
mean
the
q
a
wasn't
recorded
and
I
just
watched
the
recording,
so
maybe
one
of
the
action
items
of
the
q
a
was
what
you
were
talking
about.
B
B
A
A
If
you
want
you
can
join
this,
I
think
it's
worth
maybe
advertising
that
this
is
a
non-code
role
or
a
contribution
opportunity
where
you
really
don't
have
to
open,
prs
and
write
code
just
as
long
as
you
have
keep
the
train
moving,
you'd,
probably
doing
your
job,
so
that
would
be
worth
it
we'll
do
the
same
for
six
security.
A
E
A
A
Okay,
I'm
getting
a
thumbs
up,
and
quite
nice,
I'm
assuming
for
folks
not
on
camera.
So,
okay,
so
I
guess
yeah.
If
we
don't
meet
again,
we,
but
I
I'm
suspecting
we'll
meet
sometime
when
the
fuzzing
stuff
finishes
and
we
want
to
discuss
more.
I
just
want
to
say
thank
you
to
everyone
who
took
part
in
this
and
gave
their
feedback.
A
We
are
not
done
yet
even
close
to
done
yet,
but
at
least
we
made
some
good
progress.
We
broke
some
new
grounds.
Hopefully
it
will
be
a
useful
thing
for
other
sub
projects
who
want
to
do
it
in
future.
There
is
some
work
related
to
that
for
me
to
document
like
how
this
all
went,
what
things
we
can
do
for
others,
but
thanks
all
for
believing
that
this
could
happen
and
we're
almost
there
yet
and
we'll
see
how
this
goes.
Yeah.
C
A
E
B
I
just
want
to
say
thank
you,
robert,
for
helping
us
out
and
for
leading
us
for
us.
Thank
you.
A
G
Thanks
a
lot
robert
and
pushkar,
this
was
really
helpful
for
me
as
well,
because
even
I
was
new
to
cluster
api
and
this
helped
really
a
lot.
So
I
actually
we
learned
with
you
as
well,
so
it
was
a
good
session
yeah
thanks
a
lot
yeah
same.
A
Same
here
all
right,
so
with
that
we'll
probably
end
the
meeting,
we
everyone
knows
what
needs
to
be
done
as
next
steps.
So
we'll
go
on
to
that
and
then
see
you
somewhere
in
some
other
sig
meeting.