►
From YouTube: Supply Chain Integrity WG (May 25, 2022)
A
A
A
A
Looks
like
this
is
chant:
okay,
well,
jan,
if
you're
not
on
the
call-
and
I
don't
know
if
you
can
all
look
at
this
quickly
over
the
zoom
call,
but
it
seems
reasonable,
but
maybe
just
take
a
look,
we'll
take
a
look
after
the
after
the
meeting
and
figure
out
what
to
do
with
this.
I
think
yeah.
So
john
speed,
we've
talked
about
like
having
another
repo
for
attacks,
has
have
you
all
discussed
like
having
a
broader
threat
model
and
the
same
sort
of
thing.
B
B
I
I'm
not
sure
if
threat
model
is
the
exact
same
here,
but
there's
there's
a
recent
paper
published
the
by
the
lead
authors
named
pierre,
giorgio
ladisa
and
he's
a
french
or
excuse
me
he's
a
european
phd
student
and
they
have
a
pretty
cool
taxonomy
of
open
source
software
supplier
chain
attacks,
and
so
we've
been
thinking
of
borrowing
that,
as
we
build,
that
data
set,
brandon
should
feel
free
to
jump
in.
But
we
haven't
settled
on
that.
F
B
A
G
G
A
B
B
B
And,
like
I
said
I,
you
know,
I
think
it's
a
little
tedious
to
go
through
the
questions
and
how
I
work
with
it.
It'd
be
a
little
cognitively
overwhelming
right
now
and
I
don't
think
productive,
but
I'm
glad
to
meet
with
anyone
on
discuss
it
via
slack.
You
can
find
me
in
openssf,
slack
or
via
email,
so.
B
Yeah,
so
nothing
is
written
in
stone.
Originally,
when
I
was
thinking
of
doing
this
independently,
I
was
hoping
to
send
it
out
in
mid-june,
though
mid-july
could
be
fine
too,
I
would
have.
I
would
want
to
avoid
august,
and
then
I'd
probably
try
to
keep
it
open
for
at
least
a
month
would
be
my
plan
and
then
write.
B
The
ultimate
idea
is
to
collect
the
data,
make
the
data
public
and
open,
and
at
least
all
parts
that
aren't
sensitive,
we
might
collect
email
addresses
as
a
way
to
boost
participation.
We
wouldn't
wouldn't
release
that
and
then
also
write
a
white
paper
that
describes
the
results
and
interpretations.
B
I
attend
these
meetings
occasionally
and
work
at
chain
guard
and
I'm
glad
to
have
this
be
a
cross
organization
effort
if
others
aren't
interested,
or
at
least
cross-person,
but
I
don't
mean
this
to
be
formally
chartered
by
open
ssf,
but
I
I
thought
this
salsa.
This
is
like
a
community
person
salsa.
So
that's
why
I
thought
it
was
appropriate.
C
A
A
A
E
H
I
think
this
is
there's
there's
one
of
the
big
issues
at
the
moment
is
around
like
project
donation
and
and
purpose,
and
what
does
that
look
like?
Should
the
tact
take
all
projects
should
attack,
be
selective?
What
like,
how
do
the
working
groups
fit
into
all
this,
and,
and
we
don't
have
any
answers,
it's
an
ongoing
discussion.
H
I
think
it
is
because
I
think
one
of
the
one
of
the
one
of
the
goals
of
the
tack
seems
to
be
to
very
much
try
to
delegate
to
the
working
groups
where
the
working
groups
get
to
determine
their
scope
and
their
purpose
themselves,
and
then
it's
up
to
the
tac,
to,
I
guess,
make
sure
it's
not
causing
any
trouble
anywhere
in
the
industry
or
with
other
working
groups,
or
anything
like
that.
So
I
think
it's
up
to
this
group
to
figure
out
this
group
scope
and
purpose.
Okay,.
A
H
C
I
got
it
up
here,
yeah,
you
have
it
up
so,
but
I
can
talk
through
some
of
it.
So
yeah,
one
of
the
things
that
was
brought
up
a
few
weeks
ago,
a
camera
exactly
when
maybe
a
month
ago,
was
hey,
there's
some
confusion
about
where
supply
chain
integrity,
working
group
starts
and
ends,
and
and
especially
when
kind
of
considering
open
ssf's
charter
just
for
general
sort
of
open
source
or
general
open
source
security.
C
But
just
you
know,
security,
helping,
secure
the
tech
industry
in
in
general,
and
so
there
is
a
lot
of
discussion
on
you
know.
What
are
the
goals
of
this
group?
What
should
the
scope
of
the
group
be,
especially
when
kind
of
considering
you
know,
there's
a
lot
of
working
groups
underneath
the
open
ssf
that,
depending
on
how
you
view
your
definition
of
supply
chain,
integrity
would
potentially
fall
under
here
and
so
to
kind
of
make
it
clearer
about.
C
You
know
what
we
might
be
responsible
for
versus
what
another
group,
or
rather,
what
is
outside
of
our
responsibility.
Yeah
should
be.
That
was
the
point
of
of
writing
up
this
document
and
so
generally
there's
a
bunch
of
different
bullet
points.
There
there's
already
some
feedback
on
it.
You
know
the
stuff
that
I
put
in
there
generally
was
you
know
the
working
group.
C
Its
goal
is
to
help
secure
both
internal
and
external
supply
chains,
so
that
means
helping
provide
individuals
for
their
own
specific
project
or
organization
things
to
do
to
to
secure
their
supply
chain
right.
So
the
code
on
that
they
write
the
software.
They
write
the
systems
they
build
and
then
separately.
How
do
we
secure?
You
know?
How
do
you
sort
of
view
external
supply
chains
so
like
your
dependencies,
and
how
do
you
help
secure
your
dependencies
as
well?
As
you
know,
how
do
you
sort
of
view?
C
Actually,
I
should
change
that.
It's
now
fresca,
you
know
any
sort
of
framework,
so
this
is
stuff
like
salsa
in
the
previous
discussion
like
collecting
data
on
supply,
chain,
attacks
and
vulnerabilities.
That's
definitely
within
the
purview
of
this
group,
then
the
other
one
which
I
think
is
maybe
good
for
discussion
here,
is
how
do
we
coordinate
with
other
groups,
because
it
does
sound
like
a
lot
of
other
group
like
we
are
consuming?
C
C
Security
context,
but
I
think
that's
kind
of
I
think
one
of
the
big
open
questions
and
then
I
also
sort
of
listed
some
anti-goals
of
just
you
know:
hey,
even
though
you
know
a
misconfigured
firewall
rule
might
lead
to
a
supply
chain
security
attack.
We're
not
gonna.
Tell
you
how
to
secure
your
firewall.
J
C
So
I
this
is
where
there
are
a
lot
of
working
groups
and
it
and
every
few
weeks
there's
a
new
one
pops
up.
So
that's
kind
of
where
I
was
gonna.
You
know
this
is
also
a
call
to
the
rest
of
the
community
to
say
hey
for
those
who
are
in
a
lot
of
these
other
working
groups.
Where
do
you
view
that
collaboration
happening?
Where
do
you
view
like?
What's
your
scope
and
and
so
on,
because
I
think
that
will
help
out.
C
I
Yeah,
I
think
part
of
the
difficulty
is
start
with
a
relatively
constrained
mission
around
identity
and
and
grew
sideways
from
that,
and
also
that
it's
it's
a
very
vague
and
fuzzy
thing
to
get
get
your
head
around.
I
I
I
took
a
crack
at
this
document
at
one
point
as
well
and
really
struggled
to
nail
anything
down
firmly.
I
A
I
just
had
one
I
one
idea
for
an
addition,
curious.
What
folks
think
about
this
is
we
hear
a
lot
of
people
looking
at
things
like
salsa
and
fresca
and
how
to
best
apply
it
and
what
their
experience
has
been.
I
wonder
if
something
like
kind
of
case
studies
or
or
path
to
a
supply
chain,
secure,
supply,
chain,
integrity,
type
things
should
be
in
scope,
so
people
can
sort
of
share
their
learnings
and
where
they
got
stuck,
and
things
like
that.
I
A
I
That's
a
good
question
I
I
have
been
lacks
in
keeping
up
with
the
white
paper
stream.
It's
been
a
very
productive
couple
of
groups,
I'd
also
sort
of
place,
an
asterisk,
which
is
to
what
degree
are
we
saying
the
path
to
supply
chain,
integrity
generally
versus
the
path
to
salsa,
which
is
our
concrete
guidance
on
the
components
of
security.
A
Yeah
I
mean
I,
I
like
the
path
to
salsa,
since
that
is
part
of
this.
If
this
working
group
but
realize
that
you
know
this,
may
this
working
group
may
have
other
frameworks
that
live
under
it
in
the
future,
but
path
to
salsa
is
obviously
would
be
a
good,
a
good
place
to
start.
In
my
opinion,
I
know
like
the
kubernetes
project
itself
is
doing
some
work
here,
but
I'm
not
sure
if
there's
anything
that
that
team
is
is
writing
down
whether
that
lives
in
cncf
or
open
ssf.
C
C
There's
a
proposal
out
there
that
I
made
to
sort
of
have
some
of
these
case
studies
be
built
for
some
cncf
projects,
in
particular
one
of
the
things
that
was
discussed
at
kubecon
europe.
I
wasn't
there
so
so
I
don't
know
all
the
details,
but
one
of
the
things
was
specifically
that
was
to
actually
have
to
do
supply
chain
security
for
kubernetes
and
have
the
security
tag
take
on
a
role
there
up
playing
the
applying
the
reference
architecture
to
to
something
kubernetes.
C
So
the
once
again
the
reference
architecture,
the
cncf
reference
architecture,
which
what
fresca
is
based
on,
was
a
was
officially
released
on
at
kubecon
or
sorry
cloud
native
security
con
one
of
the
co-located
events
that
sorry
one
of
the
co-located
events
that
was
happening
at
that
time,
and
so
there
is
stuff
happening
on
that
end,
and
actually
that's
going
to
be
also.
My
next
question,
which
was
you
know?
C
The
big
thing
is
the
cncf
is
saying
hey
when
we
are
looking
at
supply
chain
security,
we're
thinking
of
supply,
chain
security
purely
within
a
cloud
native
context,
so
how
it
applies
to
stuff
like
kubernetes
and
see
other
cncf
related
projects
and
folks
who
are
doing
cloud
native
things
not
so
much
for
you
know
general
supply
chain
security.
You
know
how
do
you
sort
of
do
it
against
legacy
against?
You
know
general
software,
or
something
like
that.
C
G
You
know
software
supply
chain
group,
because
my
concern
about
doing
that
part
is
that
you
know
we
do
end
up
pulling
in
these
other
groups
or
pointing
to
them,
and
whilst
I
think
it's
beneficial,
I
think
perhaps
missing
in
that
you
know
if
you
were
an
enterprise
or
someone
coming
to
supply
chain.
This
is
what
you'd
have
to
do.
G
This
is
everything
you'd
need
to
think
about.
This
is
everything
upstream:
you
need
to
bring
in
scorecards
at
the
stations
validating
software
before
you
bring
it
in
huge
amount
of
ingestion
and
friska
yeah
and
all
the
attestations
I
mean
it
comes
into
like
the
super
group
of
everything
we've
got
within
the
ossf
right,
but
it's
trying
to
find
that
balance
where
we
provide
that
detail
and
I
think
the
the
benefit
or
the
focus
so
far
has
been
on
the
the
integrity
piece
over
and
above
that,
more
generic.
G
That
what
do
you
do
with
supply
chain
piece?
Maybe
that's
a
different
group
or
a
different
body
of
work,
and
I
think
jack
you're,
pointing
out
that
you
know
there's
some
good
stuff
at
the
cncf,
but
I
do
also
think
that's
missing
the
just.
How
do
I
get
up
through
the
different
levels
of
salsa
or
how,
as
an
end
user,
you'd
use
this
stuff
and
I
think,
there's
different
bodies
of
work
that
are
being
done
at
the
moment
to
try
and
provide
that
capability?
A
Yeah,
I
I
agree
with
scoping.
This
more
narrowly
is
a
better
place
to
start,
I'm
not
sure
if
we
can
add
more
wording
to
make
that
more
clear.
In
this
document,
my
yeah,
even
even
just
very
early
on
some
of
you,
were
in
our
very
early
meetings
like
we
just
spent
time
getting
presentations
from
different
projects
about
challenges.
A
They
were
up
against
and
where
they're
struggling,
and
I
I
just
think
if
we
could
bring
some
of
that
back
into
this
working
group
like
hey,
I'm
a
project
and
I'm
trying
to
trying
to
harden
my
integrity
of
my
supply
chain
like
here's.
What
I'm
trying
to
do
and-
and
I
think
that
would
be
super
super
valuable.
C
So
I
think,
like
one
of
the
one
of
the
big
things
that
I
think
we
still
need
to
answer
is
in
is
one
is:
what
is
the
scope
of
supply
chain
security
in
just
in
general,
and
then
how
does
it
apply
to
this
group?
Because
you
know
john
also
brought
up
some
good
points.
We
don't
want
to
boil
the
ocean
here.
At
the
same
time,
there's
probably
a
lot
of
different.
C
G
C
So
I
I
am
still
curious,
like
you
know,
this
is
kind
of
where
we
have
been
deferring
on
a
lot
of
stuff
like
because
there
are
so
many
other
open,
ssf
working
groups
like
if
I
just
kind
of
look
through
that
are
doing
things
that
are
supply
chain
related,
but
not
what
we're
doing
right,
which
is
you
know,
securing
critical
projects
securing
software
repos
identifying
threats.
You
know
best
practices
for
just
open
source
dev.
C
I
C
Cool
but
yeah,
I
think
like
inevitably
we
we
are
consumers
like
when
I
think
about
it,
and
I
think
about
like,
for
example,
salsa
like
some
of
the
stuff
that
salsa
fresca
that
are
doing
is
they're
kind
of
going
out
there
and
saying
great
oss
scorecard.
How
do
we
now
integrate
that
into
what
we're
doing
and
use
that,
as
like
a
data
point
for
generating
you
know,
information
for
salsa?
How
to
take
you
know?
How
do
we
take
the
rules
for
securing
software
repos
and
say
great?
C
How
should
salsa
then
look
at
that
thing
right,
because
now
that
should
be
what
a
secure
repo
looks
like
saul
should
now
have
guidance
around
that
or
whatever
I
think
inevitably
we're
gonna
have
that
I
just
I.
I
think
it's
just
there's
some
big
open
questions
on
once
again
right
like
we
also,
even
just
if
we're
coordinating
with
the
others,
there's
so
much
work
getting
done.
What
is
the
prioritization
around
it.
B
Aaron,
so
it
sounds
like
kind
of
what
you're
describing
is
like
this
organization,
or
this
group
would
be
the
hub
right,
whereas
the
other
pieces
around
are
creating
some
of
that
guidance.
I
mean.
Maybe
this
popped
in
my
head,
like
kind
of
consuming
that
guidance
and
just
having
that
as
the
agenda
for
meetings
right
and
just
kind
of
digging
into
each
piece,
I'm
not
sure
if
it'd
be
a
priority
or
not
like
for
ranking,
maybe
it
would,
but
maybe
that
could
be
some
of
the
the
scope
of
this
group
kind
of
like
kim.
B
A
A
I
think
that's
where,
like
the
securing
critical
projects
is
you
know,
maybe
I
mean
scorecards
is
kind
of
touching
on
a
little
bit
of
the
quality
like
make
sure
there's
a
fuzzer
make
sure
it's
being
scanned,
but
that's
kind
of
how
I've
been
separating
like
some
of
the
concepts
in
my
head
yeah.
I
agree.
There's
there's
definitely
going
to
be
overlappingping
diagrams
and
a
lot
of
this
stuff.
C
I
I
think
to
what
jonathan
brought
up,
which
I
think
is,
is
maybe
just
a
way
to
to
help
constrain.
It
is
we
think
about
it
more
from
the
perspective
of
providence,
integrity
and
attestations
right.
So
the
idea
there
being
hey
openness,
you
know
scorecard,
is
doing
all
this
great
cool.
Maybe
we
focus
on
how
does
that
turn
into
an
attestation,
and
how
does
that
attestation
get
consumed.
A
F
G
And
there's
going
to
be
many,
many
other
like
data
inputs,
and
there
are
many
many
other
data
inputs
into
the
supply
chain
and
it'll
be
different
depending
on
different
people
anyway,
and
I'm
sure
there's
going
to
be
multiple
different
working
groups
that
are
stood
up
to
do
that.
But
if
we
perhaps
look
at
a
generic
capability
of
providing
those
attestations
in
a
mechanism
that
you
could
really
trust,
you
know.
F
G
A
K
Almost
I
mean
kind
of
artifacts
at
rest
is
the
wrong
term,
but
kind
of
like
isolated
portions
of
the
of
the
supply
chain,
like
kind
of
how
we
think
about
dependency
management,
which
is
a
particular
part
of
the
life
cycle.
How
we
think
about
build
and
provenance
is
another
part
how
we
think
about
release
management
and
so
on,
and
maybe
the
supply
chain
working
group
is,
is
more
focused
on
the
interaction
between
these
things
and
so
there's
a
there's,
a
diagram
that
I
just
pasted
in
the
dark.
It's
someone
with
a
screen
sharing.
K
A
F
A
K
Right-
and
I
really
like
there
were
some
comments
in
in
the
dark
under
goals
and
folks
had
put
some
bullets
about
trust,
which
I've
added
some
some
some
comments
to
as
well,
but
I
think
you
know
the
overall
trust
architecture
in
the
supply
chain.
What
what
are
the
routes
of
trust,
what
are
their?
How
is
trust
conferred
from
one
entity
to
another?
And
how
does
trust
you
know?
How
is
how
does
trust
move
transiently
through
this
diagram
and
particularly
where
upstream
supply
may
be?
K
You
know
a
large
untrusted
area
and
your
build
your
core.
Maybe
your
highly
trusted
environment,
and
so
I
I
don't
see
that
work
overlapping
with
with
other
stuff
in
open
ssf
at
the
moment,
just
establishing
the
overall
trust
of
our
architecture,
the
roots
of
trust,
how
trust
is
established
and
maintained
over
time
and
how
trust
flows
through
this
diagram?
K
It's
it.
It
seems
to
me
that
that's
a
that's
a
gap
and
looking
closely
at
salsa
and
trying
to
figure
out
what
entities
in
the
supply
chain
could
make
credible
statements
about
salsa
compliance.
You
know
we
have
a
trusted
builder
and
it's
our
trust
in
the
builder
which
allows
us
to
believe
assigned
provenance
well.
What
entity
can
can
make
an
attestation
about
source
management
control,
and
you
know,
source
history
retention
practices.
That's
not
the
builder
that
can
make
that
claim
in
a
in
a
trustworthy
fashion.
So
what
is
that?
K
What's
the
entity
that
we
trust
to
make
those
statements
and
so
on?
And
I
I
see
I
guess-
I
see
a
gap
here
which
supply
chain
could
feel
around
the
overall
trust
architecture
and
I'm
going
to
stop
because
I
see
a
whole
bunch
of
hands
up,
which
is
a
red
flag.
But
maybe
I'm
going
way
off
the
reservation.
G
G
I
do
think
there
is
a
missing
working
group
on
how
a
user
would
use
this
stuff
all
together
right,
so
maybe
not
dig
into
it
necessarily,
but
you
know
how
how
you
would
pull
all
these
different
elements
together
to
actually
supply
secure
your
supply
chain
and
it
I
don't
think
it's
this
working
group,
but
I
think
that
focused
on
that
end
user
perspective
is
probably
the
one
that
I
think
is
missing.
I
don't
think
it
really
exists
at
the
cncf,
because
it's
more
cloud
native
focused
it's
more
just.
G
C
Yeah,
no,
I
I
I
there.
I
think,
there's
also
a
lot
we
can
leverage.
I
just
posted
in
chat.
You
know
the
cncf
had
both
their
best
practices
paper
and
their
reference
architecture
around
some
of
it.
Obviously,
a
lot
of
it
is
focused
more
on
cloud
native
pieces,
but
a
lot
of
it
does
go
into
specifically.
You
know
how
do
you
you
know?
Who
should
you
well
sorry?
It
talks
about
trust
and
how
that
trust
is
moved
around
it
talks
about
also
potentially
like
where
you
might
consider
rooting
your
trust.
C
You
know
within
your
particular
risk
appetite
and
that
sort
of
thing,
so
I
I
think
it
might
be
worthwhile
to
you
know
I
don't
know
like.
I
don't
think,
given
that
you
know
there's.
I
think,
like
total
something
like
50
pages
or
60
pages
between
the
two
documents.
We
might
not
necessarily
want
to
sort
of
redo
all
of
it,
but
it
might
be
worthwhile
sort
of
writing
up
like
addendums
around
like
hey
here's,
how
you
would
do
it,
maybe
just
more
generically
or
or
more
conceptually.
I
Doc,
yes,
so
sort
of
noodling.
Like
a
question
of
trust,
as
one
potential
unifying
theme,
I
read
a
tremendously
boring
book
recently
I
mean
this
is
the
nicest
way
possible
for
the
author.
I
know
they
worked
really
hard
on.
It
called
trust
inc.
It's
in
the
cloud
I'm
supposed
to
link
there.
There
were
two
things
about
it,
though
that
were
really
useful
insights.
I
I
C
Does
it
does
it
do
all
the
things
that
I
expect
it
to
do,
and
none
of
the
things
I
don't
expect
it
to
do,
and
then
how
do
I
apply?
You
know
rules
against
that
to
sort
of
then
establish
trust
like
establish
trust
as
in
yes,
I
trust
you
know
that
if
I
download
software
from
google
it'll
be
safe
or
whatever.
A
K
I
think
there's
a
there's
a
useful.
There
is
a
useful
common
thread
here
and
trust
which
I
think
is
is
worth
exploring
and
how
trust
flows
in
the
supply
chain
and
what
are
the
the
core
entities
that
that
need
to
convert,
trust
or
or
kind
of
you
know,
form
a
a
network
of
trust
and
what
are
the
roots
of
that
network?
K
D
D
H
A
C
C
I
C
Yeah,
and,
and
just
just
to
be
clear
here
like
this-
includes
everything,
including
transitive,
build
in
transit,
build
dependencies
and
stuff-
that's
not
actually
included
at
rhyme.
So
but
the
idea
here,
just
kind
of
showing
like
when
you
actually
think
about
everything.
What
does
that
mean?
And
and
this
is
sort
of
what
that
means?
Okay,
whoops.
C
So
just
to
kind
of
talk
through
this
a
little
bit
right.
So
this
is
the
unix
hello
program
which
is
prince
hello
world
and
what
is
all
the
things
that
it
relies
on
in
a
full,
complete
system
right
and
just
anything
that
ends
in
drv.
In
this
context,
just
pretty
much
means
hey,
hello
relies
on
the
build
that
provides
hello
and
then
so.
The
build
that
provides
hello
relies
on
well
the
the
actual
output
of
of
the
the
build.
C
It
also
relies
on
this
builder,
so
the
the
output
of
the
actual
sort
of
build
also
relies
on
like.
Where
do
I
pull
in
the
oh
sorry,
this
is
actually
the
the
source
here.
Where
do
I
pull
in
the
source
right?
Well,
I
can
pull
in
the
source
from
a
mirrors
list,
and
what
does
the
mirror's
list
rely
on?
Okay?
Well,
the
mirrors
list
relies
on
these
things
and
so
on,
and
then
you
know
even
just
to
build
anything
right
this
once
again,
this
is
the
unix
hello
world
program.
C
Well,
I'm
going
to
need
http
libraries
to
have
curl
installed
so
that
I
can
actually
download
the
source
right,
and
you
know
I
also
need
a
standard,
unix
environment,
linux,
environment
with
awk
and
some
of
the
other
stuff
and
gzip
and
so
on,
to
sort
of
to
to
unpack
the
the
tarball
of
the
source
and
so
on
and
so
forth
and
somewhere
in
here.
Actually,
that
I
found
very
interesting
was,
if
you
wanted
to
compromise
the
supply
chain,
compromise
pearl,
compatible,
regular
expressions.
C
Obviously,
this
is
like
a
50
meg
thing:
I'm
not
going
gonna
go
through
all
of
it
here,
but
if
folks
are
interested,
I
can
send
this
send
this
over
and
once
again,
this
was
also
made
using
like
doing
sort
of
a
build
of
all
of
this
sort
of
stuff
in
the
knicks
universe
and
taking
literally
all
the
output
from
the
nyx
universe,
generating
salsa
attestations,
pushing
all
those
salsa
attestations
into
recore
and
then
writing
a
tool
to
then
go
into
recore
and
recursively
pull
down.
All
those
attestations.
C
Look
for
what
those
attestations
then
cite
and
then
say:
okay,
great,
these
are
the
dependencies
in
the
attestations,
or
this
is
the
s-bomb
in
the
attack
stations
that
refers
to
these
other
things,
see
if
there's
attestations
for
those
and
then
recursively
follow
it
all
the
way
down
and
somewhere
down.
Here
is
what
the
root
the
bottom
turtle
as
far
as
linux
is
sorry.
H
C
Yeah
so
yeah,
so
I
do.
I
am
writing
the
pitch
for
kubecon
this
weekend
and
also
this
was
recorded
in
last
week's
salsa
meeting,
but
yeah.
If,
if
folks
are
also
interested,
you
know
just
to
chat
over
how
some
of
this
sort
of
stuff
is
set
up
and
and
some
of
the
tools
I
I
wrote
to
to
create
it
down
to
have
that
chat
at
another
time
as
well.