►
Description
Join Pushkar Joglekar, VMware and Adolfo García Veytia, Chainguard to learn about how Kubernetes Community is hard at work to implement image signing for Kubernetes release images using cosign
Session notes: tgik.io/notes-187
A
Hi
everybody
welcome
to
atgik
187,
we,
I
am
pushkar
zograkar.
I
work
at
vmware
and
I'll
be
your
host.
Today
we
are
going
to
talk
about
a
very
with
a
very
dear
friend,
and
also
a
topic
that
is
very
close
to
my
heart,
which
is
gaining
more
trust
into
release.
Images
for
kubernetes
and
the
work
that
has
been
going
on
for
a
few
months
now
is,
is
what
we'll
discuss,
which
is
basically
an
image
signing
kept
that
we
have
been
working
on.
A
So
if
you're,
if
you
joined
us,
just
now,
feel
free
to
say
hi
in
the
chat.
Let
us
know
what
you
want
us
to
talk
about
and
what
you
would
like
to
hear
and
while
we're
doing
that
I'll
welcome
my
friend
from
sig
release,
adolfo
garcia
veda
and
with
that
intro
I
also
want
I.
I
also
want
you
to
tell
us
how
we
should
actually
pronounce
your
name,
because
I
have
probably
messed
it
up,
and
I
should
have
asked
before.
B
B
B
I
let
the
release
notes,
team
for
kubernetes
119
and
then
from
there
some
of
the
changes
that
I
started,
working
with
under
the
guidance
of
sasha
gurunet,
who
has
been
one
of
my
dear
mentors
in
all
of
this
journey.
We
started
working
on
automating
the
release
process
more
and
more,
and
then,
when
we
were
at
the
comfortable
place
where
things
were
already
rewritten
in
go
and
the
level
of
automation
had
been
fully
migrated
from
the
old
bash
scripts
to
go.
B
The
first
effort
was
about
a
year
and
a
half
ago
and
where
we
at
some
meetings,
some
someday
stephen
augusto,
suggested
that
we
should
produce
a
bill
of
materials
for
kubernetes,
and
then
we
started
working
on
that
and
then,
when
project
six
store,
which
we're
going
to
be
talking
about
today,
a
lot
started.
We
started
meeting
with
them.
B
Just
I
think
it
had
been
up
for
a
couple
of
weeks
really
and
then
we
started
meeting
with
some
of
the
founders
there,
and
then
we
decided
that
it
was
the
way
we
wanted
to
start
securing
the
images
signing
them
and
it's
been
a
long
way,
but
we're
almost
there
at
the
point
that
we
can
start
releasing
sand
images
so
we're
going
to
demo.
Some
of
the
efforts
have
been
going
on
into
that
gap
and
yeah,
and
I'm
also
really
happy
to
be
here
with
you.
C
A
Yeah
this
is
this
is
good
enough.
So
for
folks
who
are
wondering
about
the
thumbnail
by
the
way,
both
adolfo
and
I
love
biking-
I
am
a
relatively
no
wise
biker
at
all.
Four
has
done
a
lot
of
I
I
let
him
explain
cross-country
biking
and
he
has
an
actual
bike
behind
him
as
well.
So
that's
where
this
this
came
from,
if
you
like
bikes
and
want
to
talk
about
it,
I'm
happy
to
hear
from
you
in
the
chat
as
well.
A
So,
okay,
so
enough
about
us,
let's
go
back
to
week
in
review,
so
scroll
down
a
bit
more
yeah,
okay,
so
this
week,
something
that
I
think
personally
is
is
very
important
for
us
in
the
community
happened.
So
there
was
an
open
letter
shared
by
some
community
members
to
linux
foundation,
where
people
explained
their
concerns
about
some
of
the
conferences
being
in
texas
and
in
matter
of
fact,
one
or
two
days
linux
foundation
submitted
a
statement
explaining
their
perspective
on
this.
So
please
take
a
look.
A
This
is
something
I
I
deeply
care
about
and
I
hope
it
is
important
for
you
and
hopefully
you
are
able
to
be
learn.
It
and
understand
it
a
bit
more,
so
next,
one
back
to
kubernetes
land,
there
were
patch
releases
which
happened
this
week.
I
think
one
of
our
friends
in
sick
release
did
the
patch
releases
this
week
and
the
main
reason
for
the
batteries,
if
I
remember
right,
is
golang,
was
bumped
for
all
of
our
components
for
kubernetes,
so
those
patches
are
available.
A
So
that's
about
the
news
from
my
side.
If
you
have
anything,
you
want
to
add,
please
go
ahead
and
add
it
we'll
see
who
is
joined
on
the
chat
now
so
hey
eric
nice
to
see
you
here,
namadi
is
excited
about
image.
Signing.
Let
me
know
if
I
how,
if
I
did
not
good
job
or
a
bad
job,
pronouncing
your
name
again
and
john
good
day
from
minnesota
and
alex
from
sunny
north
california
yeah,
it's
actually
quite
a
good
day
today.
I
agree
alex
so.
A
A
If
I
remember
right
and
the
idea
was
hey,
we
have
an
s
bomb
and
we
we
have
a
very
good
tool
like
cosine,
with
a
very
good
user
experience
to
sign
images
now,
and
so
there
is
a
chance
that
we
can
actually
sign
our
images
that
are
shipped
in
every
kubernetes
release,
and
then
there
was
some
discussion
and
for
folks
who
are
unfamiliar
with
how
design
discussions
happen.
Kubernetes
a
cap
was
created.
Cap
is
basically
a
kubernetes
enhancement
proposal
which
has
a
template
and
a
design
discussion.
A
It
is
basically
a
design
dock
to
explain
why
this
is
important.
Why
we
want
to
do
it,
how
we
are
going
to
do
it?
What
different
sigs
are
going
to
work
on
it,
and
then
everyone
gets
a
chance
to
weigh
in
share
their
concerns,
share
their
feedback
and
the
idea
is
through
the
combined
knowledge
of
the
community.
The
total
output
or
the
outcome
of
the
cap
improves
and
the
design
is
stronger
because
of
it.
A
So
that's
what
happened
in
this
cap,
I
I
believe
sasha
and
porco
have
been
leading
that
from
sigrid
lee's
side
and
me
from
seek
security,
always
happy
to
see
somebody
apart
from
security,
doing
great
work
in
security,
so
like
hey,
I
am
here
to,
I
would
love
to
help,
and
so
that's
how
I
joined
and
been
working
on
implementing
it.
What's
what's
been,
what
has
been
your
journey
on
this
skip
of
pureco,
and
what
are
you
really
looking
forward
to
in
terms
of
the
final
outcome
in
the
coming
weeks?.
C
B
B
I
think
it
was
like
two
years
ago
and
the
after
we
started
publishing
the
kubernetes
sales
funnel
we
saw
that
two
things
happened,
so
the
first
one
is
that
the
project
really
whenever
kubernetes,
does
something.
It
really
has
the
ability
to
impact
a
lot
of
practices
in
the
cloud
native
space.
So
when
we
produce
the
s-bomb
and
the
s-phone
tool,
we've
seen
some
we've
seen
some
adoption
of
that
tool
to
start
producing,
s-bombs
and
related
projects.
B
So
when
you
have
an
interactive
flow
in
cosine,
you
will
go
and
and
authorize
the
signature
to
use
your
identity
by
authorizing
an
open
id
flow
right.
But
this
identity
can
also
be
used
by
automated
processes
by
that
can
emit
oidc
tokens.
So
we
are
using
that
feature
of
the
of
the
of
the
of
the
flow
to
authorize
and
and
give
the
the
signed
artifacts
the
identity
that
we
want
from
the
kubernetes
organization.
B
To
see
that
in
some
detail,
so
we
started
working
on
on
the
on
the
well.
The
signing
effort
that
we're
explaining
today
is
part
of
a
larger
effort,
which
is
to
provide
to
make
the
kubernetes
releases
salsa
compliance.
So
salsa
is
a
framework
that
has
some
guidelines
and
suggestions
for
software
releases
that
will
make
them
more
secure.
D
B
Back
in
october,
we
announced
that
we
had
reached
the
first
level
of
salsa,
which
is
basically
providing
the
metadata
necessary
to
inspect
the
release
process
and
as
we
go
up
in
levels,
the
next
ones
start
requiring
that
all
of
the
the
metadata
the
artifacts
cannot
be
falsified
and
that
so
that
means
we
need
to
add
digital
signatures
to
all
of
them,
and
this
is
what
where
we
are
today.
So
there
are
two
three
I'd
say:
signing
efforts
that
should
go
into
the
process.
B
One
is
signing
the
images,
one
is
signing
the
binaries
that
we
release
and
finally
signing
all
of
the
metadata
files
that
we
produce,
like
the
s,
phones
and
the
provenance
at
the
stations
and,
like
you
said,
vijay
during
the
last
months.
This
the
the
first
thing
that
we've
been
working
on
is
signing
the
images
which
are
going
to
be
the
first
ones
to
go
outside
and
we've
been
seeing.
B
It
has
been
open,
I
think,
for
a
month
now-
and
it's
been
always
getting
the
necessary
patches
from
folks
all
over
the
place
that
have
been
adding
the
new
functionality
to
our
libraries
to
to
the
to
the
tooling
that
releases
kubernetes
like
duplicate
yeah,
you
submitted
one
of
the
parts
which
I
I'm
very
very
grateful
for
you
have
been
taking
that
and
and
yeah.
So
this
will
once
we
land
this.
The
signing
mvp,
which
is
the
minimal
file
demo,
that
we're
doing
for
signing
images
will
be
signed.
B
Another
thing
that
we
should
also
mention
is
that
this
effort
goes
hand
in
hand
with
security,
but
also
as
well
with
sikh,
kate,
sinfra.
So
kate
sinfra
are
the
folks
that
volunteer
at
the
time
to
ensure
that
the
infrastructure
that
powers
kubernetes.
So
whenever
you
submit
a
pull
request,
it
runs
on
infrastructure,
then
it's
handled
by
sig,
sinfra
and
all
of
the
google
cloud
infrastructure
that
handles
that
our
processes
is
handled
by
them.
B
A
A
A
few
new
features
are
visible,
but
nothing
will
work
and
nothing
will
matter
if
those
are
the
people
who
don't
con
if
they
stop
working
and
continue
to
help
us
and
continue
to
make
sure
the
infra
for
kubernetes
is
up
and
running
always
so
that
our
pull
requests
get
merged
on
time.
Our
jobs
and
test
grades
are
running
and
green
and
we
get
alerted
if
things
go
wrong,
so
definitely
agree.
B
Another
another
important
part
is
that,
if
you
think
about
it,
when
we
sign
images,
we
are
operating
right
in
the
middle
of
the
border
where
seek
release
and
seek
get
seen
from
it.
Because
right
we
produce
the
releases
and
the
infrastructure
and
the
registries,
and
that
is
part
of
what
they
handle.
So.
A
A
The
mvp.
This
time
is
going
to
be
signing
images
only
that
are
part
of
kubernetes
release
and
there
and
the
tool
behind
that
is
cosine
and
for
folks
were
in
case
unfamiliar
cosine
is,
if
I
remember
or
understand
correctly,
an
acronym
for
container
signing.
So
that's
basically
a
tool
that
depends
on
six
store,
which
is
a
generalized
tool
for
signing
artifacts,
and
it
allows
like
purchase
mentioning
an
ability
to
authenticate
the
signer
so
that
we
not
only
get
integrity,
but
we
get
authenticity
when
a
signature
is
created
for
any
artifact.
A
So
all
of
that
work
is
going
on
right
now
with
everything
in
software
we
are
doing
incremental
updates,
so
we'll
try
and
see
if
we
can
push
the
images,
if
maybe
it's
right
to
say
for
version
124
that
are
signed
and
then
for
all
successive
releases.
There
is
a
chance
that
we'll
continue
to
sign
them
and
maybe
add
more
artifacts
that
are
also
signed
in
future.
D
B
Idea
is
to
secure
all
of
them
so
that
you
can
trust
and
verify
the
the
release
process
from
start
to
end
and
also
make
sure
that
so,
when
we
do
a
kubernetes
release,
we
have
a
staging
process
and
then
a
release
process,
and
then,
on
until
last
year,
you
could
not
attest
the
release.
Process
could
not
attest
as
to
the
to
the
artifacts
that
it's
consuming
from
staging.
A
A
We
have
sevi
from
sunny
amsterdam,
weird
but
true
and
happy
tgik
everyone
and
somebody
with
a
name
called
native
to
the
cloud
is
showing
their
love
for
you
purposeful,
and
maybe
this
is
a
good
time
to
tell
the
story
behind
your
handle.
I
know
the
story,
but
if
you're
comfortable,
maybe
you
can
share
it
with
everyone.
B
D
A
B
Awesome
so
the
first
thing
is:
I
I
prepared
a
little
presentation
just
to
make
sure
that
we,
because
I
I
feel
that
sometimes
the
processes
running
inside
of
the
release
process
are
kind
of
abstract.
So
I
wanted
to
to
give
a
brief
overview
of
what
how
it
works
and
how
we
are
trying
to
to
make
things
work
once
we
finish
the
designing
effort
so
yeah.
Let
me.
B
Okay,
perfect,
so
let
me
just
take
this
out
of
the
way
okay.
So
this
is
the
first
the
introduction.
So
I
wanted
to
start
with
introducing
you
with
some
of
the
tooling
that
we
use
so
the
kubernetes
releases
are
powered
by
a
tool.
That's
called
krell.
They,
which
means
the
kubernetes
release
toolbox.
Krell
does
many
things.
It
creates
release,
notes
it
powers
the
staging
and
release,
and
it
has
like,
I
don't
know,
10
different
functions,
ipro.
B
It
also
handles
the
image
promotion,
pull
requests
which
we're
going
to
be
talking
about
today.
So
many
things-
and
the
key
thing
here-
is
that
krell,
the
main
function
that
we're
going
to
be
inspecting
is
when
it
does
the
staging
of
the
kubernetes
artifacts.
So
as
part
of
our
kubernetes
release,
we
release
many
things.
We
we
do.
We
build
a
bunch
of
tables
the
documentation,
well,
another
documentation,
but
the
release
notes.
We
do
the
container
images
the
s1,
but
we're
going
to
be
focusing
today
on
on
the
image
release
process.
B
B
There's
there's
a
manifest
of
the
files
that
should
live
in
the
registries
and
the
release
registers.
So
the
way
it
works
is
that
you
open
up
a
request
modifying
that
manifest,
and
you
tell
the
image
promoter
to
app
to
release
new
images
and
what
it
will
do
is
go.
Compare
the
the
source
registry
find
all
the
images
that
are
missing
from
the
target
registries
and
copy
them,
and
then
they
get
released.
B
B
A
B
B
A
B
B
A
B
B
So
at
this
point
in
theory,
we
can
ensure
that
we
have
signed
images
right,
but
if
you
think
about
it,
the
way
the
signature
is
coming
from
the
release
engineering
team
and
we
wanted
to
provide
a
way
for
the
whole
community
to
sign
their
their
projects
and
to
do
that,
we
couldn't
simply
just
carry
the
signatures
forward
because
we
wanted
to
to
provide
like
a
like
a
stamp
of
guarantee
of
a
signature
at
the
organized
whole
kubernetes
wide
organization.
So
what
we
did
was
modify
the
process
in
the
following
way.
B
So
once
once
we
have
the
images
promoted,
the
promoter
will
assume
the
identity
of
a
new
of
another
service
account
which
will
provide
the
the
the
identity
for
the
whole
kubernetes
organization
and
push
those
images
and
sign.
One
of
the
images,
so
it
will
actually
go
and
sign
the
image
that
has
already
been
promoted
and
it's
out
there
in
one
of
the
mirrors
and
once
it's
signed
it
will
go.
The
promoter
will
go
and
take
that
signature
and
copy
it
to
the
rest
of
the
registers.
B
The
reason
it's
doing
this
it's
because
if
you
sign
the
registries
many
times
if
you,
if,
if
the
promoter
were
to
go
and
sign
asia,
the
us
and
ua
and
eu
separately,
you
would
end
up
with
different
signatures.
So
we
we
are
working
to
do
the
copying
of
the
first
signature
so
that
we
ensure
that
all
of
the
images
have
get
the
same
signature
and
in
the
end
you
get
an
image
that
is
signed
twice
one
time
by
the
project
which
in
this
case
it's.
B
This
is
a
special
case,
because
it's
kubernetes
itself.
But
if
you
think
about
it,
some
of
the
smaller
projects
say,
for
example,
that
you
were
to
release
ingress
nginx.
They
could
provide
their
own
signature
and
then
and
then
release
it.
So
you
end
up
with
each
of
the
images
in
their
mirrors
signed
by
the
project
and
then
a
second
signature
of
the
kubernetes
wide
organization.
So
at
that
point
you
can
basically
celebrate.
B
B
B
D
B
A
second
signature
that
what
it
tells
you
is
that
someone
somewhere
signed
it,
but
if
you
think
about
it,
you
have
like
a
disconnect
problem
in
there
because
well
you
have.
While
you
have
two
signatures,
you
simply
don't
know
who
the
first
signature
is
right.
You
you
can
verify
that
the
first
signature
was
in
fact
kubernetes,
but
you
cannot
authorize
the
second.
So
we
are
working
currently
in
improving
this
trust
model,
also
working
with
some
of
the
extremely
smart
people,
and
that
are
six
star
contributors,
so
enter
tough.
B
If
you're
familiar
with
tough
for
those
of
you
who
are
not,
I'm
not
a
tough
expert
and
explaining
tough
could
take
a
whole
or
a
series
of
shows
all
by
itself
explaining
toughest
stuff,
exactly
yeah.
That
could
be
the
motto,
but
we
are
working
to
ensure
that
that
we
have
a
proper
delegation
of
trust,
and
I
can
briefly
explain
how
it's
going
to
work.
The
way.
B
Like
like
as
follows,
so
the
first
thing
is,
we
have
a
kubernetes.
Well,
this
is
the
idea
of
how
it's
going
to
work.
It's
the
some
of
the
code
tooling,
and
the
final
specification
is
not
there
yet,
but
we're
actively
working
on
it.
The
way
it's
going
to
work
is
as
follows.
So
we
we're
going
to
have
a
kubernetes
delegation
that
gets
its
identity.
B
That
gets
its
its
trust
root
from
the
full
sear
roots,
that
that
is
the
source
that
derives
from
the
root
key
from
six
or
so
sixth
or
hada
has
a
topmost
root
certificate
that
is
itself
generated
from
what's
generated
in
a
signing
ceremony
last
year
and
the
next
one
is
going
to
be
shortly
and
I'm
not
sure
of
the
date.
But
it's
it's.
B
So
it's
about
to
to
get
a
rotation,
because
the
way
the
roots
are
generated
is
that
you
have
several
signers
that
take
parts
into
the
into
the
key
ceremony
and
they
sign
using
tough.
They
all
sign
the
the
the
the
necessary
metadata
to
generate
the
the
full
seal
roots.
So
the
idea
is
that
no
one
person
can
generate
new
routes
for
the
six-four
project
you
have
to
have
at
least
I
think.
B
If
I
remember
correctly,
there
are
five
key
holders
and
from
those
I
think
you
have
to
have
at
least
three
to
generate
a
new
route,
and
once
you
have
it,
you
have
you
get
the
new.
The
new
system
rules
then
kubernetes
as
an
organization
and
by
the
way,
this
is
also
in
the
works
for
other
types
of
open
source
organization,
not
just
kubernetes.
B
For
example,
there
is
a
current
effort,
a
really
interesting
one,
to
to
build
this
same
sort
of
selection,
the
ruby
gems
community,
for
example.
So
they
didn't
want
to
work.
Is
we
have
a
delegation
from
fusio
and
then
kubernetes
is
going
to
to
be
able
to
delegate
identity
and
trust
to
its
let's
say
smaller
projects
or
yeah
baby
projects?
I
don't
know
how
to
call
them.
I
don't
know
if
it's
offensive
to
call
them
baby
projects,
but
the
smaller
projects,
not
the.
A
B
B
Okay,
so
projects
and
then
so,
let's
take,
for
example,
cluster
api,
so
kubernetes
is
going
to
be
able
to
delegate
to
cluster
apa
the
the
the
means
to
it
for
them
to
to
generate
their
own
keys.
That
can
be
traced
back
from
cluster
apa
to
kubernetes
to
the
full
series.
So
you
can
verify
the
whole
chain
and
then
cluster
apa
can
determine
how
their
signing
at
the
project
level
works.
B
If
you
think
about
it,
we
are
trying
to
to
plug
some
of
the
identity
gaps
wherever
we
can,
and
I
think
the
efforts
are
going
really
well.
Some
of
the
tooling,
as
I
said
before,
doesn't
exist
yet,
but
as
as
we,
so
we
are
trying
to
to
to
to
move
this
as
fast
as
we
can
and
and
to
provide
the
the
necessary
guarantees
for
the
sand.
Architectures.
A
A
B
Exactly
well,
there
are
two
parts,
so
one
is
like
in
in
all
things:
identity,
there's
identity,
but
so,
and
authorization
and
so
right
now.
The
way
it's
going
to
work
is,
if
you
sign
an
image
right
now,
when
we
take
it
as
a
candidate
for
promotion,
we're
going
to
verify
that
signature
right,
but
we
do
not
have
any
any
means
of
making
sure
that
the
identity
is
someone
allowed
to
to
sign
it.
B
So
we're
just
going
to
verify
and
use
the
signature
for
integrity
of
the
image
and
let
it
true
if
it
if
it
matches
once
we
have
the
the
kubernetes
delegation
in
place,
we
are
going
to
be
able
to
ensure
that
whoever
is
sending
that
image
is
in
fact
authorized
to
release
for
that
project.
Correct
yeah.
That
makes.
D
A
Yeah
this
is
similar
to
like
the
pki
model,
where,
if
I
am
a
self-signed
ca,
I
am
able
to
establish
tls
handshake,
but
I
don't
know
whether
that
ca
is
someone.
I
can
trust
and
whether
that
ca
is
allowed
to
work
the
way
it
it
needs
to
work
and
the
right
people
are
actually
have
access
to
that
private
key.
B
Get
it
and
if
we
establish
that
in
by
other
means
that
you
push
car
can
release-
and
I
have
your
service
account-
I
can
trust
the
fools.
You
tell
me
okay,
so
this
is
really
comes
from
pushkar.
Okay,
and
I
know
that,
but
using
the
tough
delegation
you
will
be
able
to
cryptographically
verify
the
chain
all
the
way
and
without
prior
interchange
of
of
of
the
identities.
So
you
can
basically
follow
all
of
this.
B
A
Yeah
yeah,
that
makes
sense.
I
I
see
it
like
the
analogy.
I
remember
I
try
to
remember
remem
when
I
have
to
figure
this
out
is.
If
I
have
a
photo
and
a
sign
of
signature
of
myself
below
it,
I
can
say
that
hey.
This
is
my
photo
and
I
can
say
it
again
for
you,
but
I
can't
you,
you
can't
be
sure
that
I
am
actually
pushkar,
because
I
am
just
telling
you
I
am
pushkar
and
I
can
sign
it
the
same
way.
A
You
just
think
that
okay,
this
might
be
pushkar,
but
if
I
have
a
passport
with
the
same
photo
and
my
own
signature,
then
the
person
who
sees
the
passport
knows
that.
Oh,
that
government
has
actually
confirmed
that
this
person
is
actually
pushkar
and
he
can
verify
the
signature
that
it
is.
Actually
he
can
do
the
same
signature
again
so
now.
I
have
a
chain
of
trust
with
a
third
party
that
I
trust
and
push
could
also
trust
and,
and
that
third
party
is
verified.
Pushkar
is
actually
pushkar
exactly.
A
From
the
same
person,
yeah
yeah
exactly
okay,
cool.
That
makes
a
lot
of
sense
and
I'm
glad
like
we're
thinking
through
all
of
these
things
and
also
the
fact
that
we're
using
short-lived
secrets
so
as
a
result
of
that
any
potential
chances
of
that
secret
or
credential
being
leaked
or
misused,
at
least
the
chances
reduce.
We
can't
be
guaranteed
everything
hundred
percent
of
the
time.
B
A
Think
that
sounds
like
a
good
idea.
One
thing
I
always
struggle
explaining
people,
and
so
maybe
we
can
help
demystify
is
how
does
the
signature
actually
look
like
because
sometimes
you
just
say
like
hey
this?
I
have
signed
it,
but
nobody
really
knows
like
what
does
it
really
look
like
and
what
should
I
do
with
that
signature?
So
if
we
go
through
that
demo
and
like
really
dive
deeper
into
the
artifacts
that
are
created
when
we
sign
it
and
when
we
verify,
I
think
that
would
be
a
lot
of
fun.
B
Right
yeah,
so
this
is
one
of
the
things
one
of
the
ongoing
debates
that
we
have
on
the
on
kubernetes.
So
we
want
to
provide
a
link,
a
url,
that
you
can
click
and
see
some
of
the
verification
information,
but
no
one,
there's
there's
no
one!
That
has
there
are
lots
of
ideas
around,
but
we
haven't
finalized.
So
what
would
that
look
like?
What?
What
would
you
expect
to
see
if
you
clicked
on
the
link,
the
signature,
the
metadata
so
nicely,
formatted
page,
so
we're
thinking
thinking
on
that?
B
A
B
A
B
So
I
have
a
project
here
that
already
so
this
is
this:
I'm
going
to
reuse
a
a
demo
project
that
I
built
with
carlos
panato
who's,
not
only
my
personal
hero,
but
also
my
co-technical
lead
in
siege
release.
We
built
this
this.
It's
just
a
project
that
builds
an
image.
Another
image,
nothing,
nothing
less.
So
we
use
a
scope
for
those
not
familiar.
D
B
B
The
image
for
all
architectures
and
push
it
to
my
to
my
registry,
my
personal
registry,
so
one
of
the
nice
things
about
go
ko
is
that
when
it
takes
a
source
code
and
builds
the
image,
it's
going
to
also
create
a
bill
of
materials
for
that
and
and
upload
it
with
the
image.
So
it
the
images
are
built
and
now
the
next
step
in
the
in
the
in
the
build
process.
This
is
trying
to
simulate
what
happens
inside
of
the
of
of
crail
of
the
staging
process.
B
Exactly
yeah,
this
is
the
this
is
the
the
part
where
I
was
going
to
what
I
was
going
to
explain.
So
this
all
of
this
happens
inside
of
the
kubernetes
releases
automatically
and
using
just
work
level
identity
in
here.
Since
I
have
access
to
my
to
my
browser,
I'm
running
this
in
my
in
my
desktop
computer.
B
B
So
I
can
me
hide
this
thing
here
if
I
I
can
use
so
this
is
a
pack
that
I
just
signed
and
it's
already
published.
The
tag
is
version
002
right
and
I'm
going
to
use
cosine
here
to
verify
the
newly
signed
image
and
I'm
passing
the
output
to
jq,
because
that's
part
of
that.
So
what
would
people
expect
to
see
when
verifying
the
image
or
at
least
machine
readable
data,
mostly
right-
and
this
is
this-
is
what
what
the?
What
the
the
verification
looks
like.
After
signing
the
image.
B
Some
information
that
is
in
there
is
the
docker
reference
which
I
signed,
which
is
the
the
the
the
actual
thing
that
gets
signed
and
in
this
case,
is
the
the
badges
of
the
manifest.
So
if
you
remember
the
previous
run
here,
we
built
an
image,
for
I
don't
know
like
seven
six
platforms
and
what
we're
assigning
here
is
just
the
digest
of
the
of
the
manifest
that
manifest,
of
course
ties
to
all
the
images
behind
it
behind
it,
and
so
I'm
stamping
that
one
and
then
some
of
the
some
of
the
metadata.
B
So
I
have
a
log
index
because
when
I
sign
my
image,
all
of
this
information
gets
pushed
to
the
sixth
or
transparency
log,
so
that
anyone
can
verify
the
signature
in
the
future
and
the
other
part.
The
important
important
part
here
is
that
so
these
are
just
annotations
that
we
added
you
can
add
any
number
of
annotations
to
the
to
the
station
that
you're
signing
and
then
here's
the
identity.
D
A
And
so
couple
of
questions
here
before
before
we
go
back
to
the
browser.
Now
we
you
mentioned
that
some
record
was
created
in
the
transparency
log
so
that
it
is
easier
to
verify.
Does
that
mean
now
so
typically,
my
understanding
is
cryptographic.
Signing
verification
works
where
you
have
a
public
key
and
you
have
a
private
key.
Private
key
is
used
to
sign
public
key
is
used
to
verify.
So
is
the
transparency
log
actually
storing
the
public
key
that
I
can
use
to
verify,
or
is
it
storing
something
else.
B
Exactly
yeah,
so
when
we,
when
we
are
using
here,
what's
called
in
in
the
sixth
order
jargon,
keyless
signing
so
the
way
killer,
signing
works
is
that
cosine
will
generate,
or
I
think
it's
fulsy
rather
generate
a
keeper
that
it's
ephemeral
and
it's
tied
to
an
expiration
date
and
it
lasts.
I
think,
like
five
minutes,
or
so
it
uses
that
to
sign
and
stores
the
private
key
in
the
transparency
log.
So
when
I,
so,
if
you
show.
B
Just
a
just
just
a
public
key,
publicly,
okay,
yeah,
and
so,
if
you
saw
here
there
were
no
keys
interchanged.
They
were
just
generated
in
memory
and
used
to
sign
and
then
the
the
private
key
is
now
gone.
But
the
public
key
got
recorded
into
the
transparency
login.
So
I
can
come
and
verify
without
having
it.
The
the
image.
B
A
A
B
A
B
A
B
A
D
B
B
If
you
see
that,
if
you
see
the
the
digest
of
the
manifest
that
we
signed
this
one
here,
beginning
with
ccac,
what
cosine
will
do
is
create
another
image
we
could
say
that
is
named
the
with
the
same
base
on
the
hash
that
we
just
sent.
So
this,
if
you
see
the
tag
of
the
signature,
it
starts
with
chat
to
56
and
then,
instead
of
having
the
colon
substitutes
that
with
the
dash
and
then
the
the
the
digest
in
adult
seed.
At
the
end.
Right
and.
A
A
Yeah,
okay,
so
hopefully
this
is
better
for
everyone
watching
and
just
to
repeat
what
you
said.
The
hash
in
the
second
row
is
actually
showed
shows
up
in
the
tag
if
you
notice
in
the
first
row,
and
typically,
if
you,
if
you
have
worked
with
docker,
the
sha
256,
is
followed
by
a
colon,
but
in
this
case
it's
a
dash
and
I'm
guessing
that's
how
this
image
knows
where
to
find
its
signature.
B
Right
this
is
the
way
it
works.
So
the
important
thing
to
keep
in
mind
is
that
this
is
a
tag,
so
the
the
shot
to
56
is
attack.
It's
not
the
it's,
not
the
digest
of
that
image.
The
digest
is
this
one
here
that
starts
with
one
three
zero
of
for
that
for
the
signature,
but
it's
stacked
with
with
a
string
that
can
be
used
to
match
the
the
signature
layer
back
to
the
digest.
That
is
that
to
the
index
that
design
it.
B
B
Oh,
I'm
going
to
use
the
bond
tool
that
we
created
for
the
kubernetes
bones
to
generate
a
bill
of
materials
for
the
image
that
I
just
created.
So
I'm
going
to
pass
generate
the
generator
command
point
it
to
the
image
that
we
just
created.
I'm
pointing
it
to
the
tag
that
points
to
the
to
the
manifest.
D
B
B
Since
I
I
push
them-
and
I
don't
have
local
copies
here,
yet
it's
going
to
go
and
download
all
of
the
images
and
then
scan
their
layers
to
generate
the
the
songs,
because,
if
you
want
to
to
to
have
like
a
complete
dependency
information
for
your
images,
ko
gave
you
the
the
language
dependencies
of
the
go
project,
and
then
I
need
another
one.
That
gives
me
the
dependencies
of
the
os
layer
of
the
system,
packages
and
layers,
and
this
is
what
what
what
we
just
did
here.
B
So
if
we,
let
me
explore
a
little
bit
this
one
here,
so
this
is
the
es1
information
that
I
just
generated.
It
lists
one
package,
which
is
the
the
tag
that
we
of
the
images.
So
that's
the
first
one.
If
you
see
here
that
package
has
eight
relationships,
because
it
contains
eight
things
which,
if
you
can
you
guess
what
it
is.
B
A
Next
yeah
hang
on
so
for
all
of
this,
like
tying
all
of
this
together
we
have
we
did.
We
signed
an
a
package
which
composed
all
of
multiple
different
images
of
different
architecture,
and
that
is
the
one
called
supply
chain.
Demo
version:
zero,
zero,
two
yeah,
and
that
package
was
pointing
to
multiple
other
images
which
are
which
we
are
seeing
now.
So
when
we
signed
it,
we
signed
the
package,
but
not
the
individual
images,
correct.
B
B
A
I'll
try
to
answer
one
question
until
then,
so
moz
is
asking
to
deploy
the
images
to
kubernetes,
which
tag
should
be
used,
sig
or
version
tag.
I
think
I
know
the
answer.
So
if
you
have
to
actually
use
the
kubernetes
image
itself,
you
would
use
the
tag
of
the
kubernetes
image
because
the
signature
doesn't
actually
exist
doesn't
actually
contain
the
image
right.
So
if
you
have
to
use
the
image
you
pull
the
image
tag
instead
of
the
signature
tag,
yeah.
B
B
B
A
Okay,
I
I
think
this
is
related
to
jim's
question
on
the
chat
he's
asking
any
way
to
check
the
source
of
the
contains
package
that
is
built
from
binary
versus
debra
po.
So,
if
jim,
if
I
understand
your
question
correctly
you're
asking,
can
I
figure
out
what
what
was
the
source
of
the
binary
that
was
being
built
and
what
were
what
were
the
dependencies
for
that
binary?
So
that
would
be
the
example
just
above
this
logo,
which
had
the
list
of
go
mod
dependencies.
B
B
Yeah
so
in
this
case,
the
the
source,
the
source
information
comes
from
since
co
is
actually
building
my
project,
which
I
so
this
is
I'm
actually
right
now
in
the
in
the
go
project
and
go
go,
builds
this
project
and
compiles
for
all
of
the
architectures.
So
it
has
first-hand
information
into
what
we're
looking
at
here.
B
We
are
currently
working
to
add
to
the
bond
tool
the
ability
to
take
a
binary
and
using
the
new
go
dependency
information
flux
that
you
can.
You
can
pass
to
it
extracted
the
dependencies,
but
in
the
in
the
in
the
end,
what
you
want
is
that
the
s-bombs
originate
as
close
from
the
source
of
information
as
possible.
So
if
co
is
building,
then
you
should
trust
the
s1
that
co-produces
and
not
try
to
generate
it
later.
A
Yeah
yeah,
I
agree.
One
thing
this
reminded
me
of
discussion
in
six
security,
just
maybe
it's
a
little
bit
tangent
but
I'll
try
to
be
brief.
One
of
the
things
we
were
discussing
a
couple
of
weeks
back
was
in
this
image
in
this
application,
for
example,
right
the
app
was
it
let's.
Maybe
we
can
give
you
as
an
example.
What's
the
name
of
the
application
that
we're
looking
at
supply
chain
demo.
A
Okay
yeah,
so
in
this
case
let's
say
this
is
the
name
of
our
application.
One
of
the
things
we
were
trying
to
figure
out
is:
if
supply
chain
demo
version
zero,
zero
one
ends
up
having
a
cve
that
gets
fixed
in
version
zero,
zero.
Two,
the
s-bomb,
doesn't
have
that
information
for
the
version.
If
I'm
not
wrong
or
does
it,
it
does.
B
B
A
A
B
A
Change
it
right
right,
makes
sense,
looks
like
jim
has
come
up
with
more
context,
so
make
sense
for
the
ones
that
have
collage
dependencies
with
links
to
mods.
I
was
thinking
more
about
binaries
that
were
listed
in
the
image
like
contains
package
label
open
ssl.
Oh,
I
see
what
you
mean,
okay
and
then,
but
I
think
the
point
is
you
trust
the
image
to
begin
with
versus
picking
apart
the
image?
A
I
I
see
what
you
mean,
so
you
you're
wondering
if
I
end
up
having
a
package
that
is
or
a
binary
that
is
in
the
image,
but
it's
not
installed
by
debian
or
yum
or
apt,
and
it's
also
not
my
application
binary.
So
in
that
case
up
what's
the
best
way
to
figure
it
out.
So
I
think,
like
you
said,
if
you
trust
the
image,
then
you
know,
then
you
assume
that
nothing
malicious
is
actually
part
of
the
image
and
then
the
only
thing
you
are
adding
is
your
own
binary.
D
B
Right
now,
for
example,
what
what
the
bomb
tool
does
is
takes
the
image
right
opens
the
layer.
It
recognizes
that
it's
a
debian
layer
right
and
it
opens
it-
they
have
the
debian
database
and
scans
all
of
the
packages
and
presents
information
right,
but
that
could
be
so.
This
is
what
some
people
call
an
after
the
fact
this
one.
B
You
run
your
build.
You
build
your
image
straight
from
the
operating
from
the
alpine
packages,
so
you
configure
the
packages
run
the
build,
and
you
end
up
with
a
one
layer
image
that
produces
bombs
that
are
straight
from
the
from
the
source
that
build
the
image
and
and
with
the
and
those
packages
are
itself
themselves
verified
because
they
they
are
signed
by
the
distribution
right.
So
you
you
don't
have
to
do
this,
because
if
you
build
an
image
with
appgo,
it
already
comes
with
an
s1
from
the
time
it
was
created.
B
Yeah
exactly
they
are
inside
kubernetes
and
we
are
trying
to
to
build
like
the
next
generation
of
that
yeah
and
we
are
already
publishing
daily
images
of
some
common
bases
that
you
can
use
as
base
images
for
your
projects
and
it's
still
version
0.2
or
I
think
it's
coming
today
out
app
called
0.2.
But
it's
already
showing
lots
of
promise
and
interest.
So
it's
another.
A
A
D
A
I
don't
have
maybe
the
source
code
and
I
am
stuck
with
an
image
coming
from
a
third-party
provider,
and
I
want
to
know
like
what
version
of
this
binary
I'm
actually
running,
then
I
am
able
to
actually
now
with
118
use
that
feature
to
figure
out.
Okay,
this
is
the
version.
Are
there
any
cvs
for
this
version.
B
B
A
B
Cool,
so
we
have
our
s1
and
it
will
make
sense
to
use
cosine.
Let
me
run
this,
so
I'm
going
to
use
cosine
here
and
I'm
going
to
attach
the
s1
file
that
we
just
created
to
the
to
the
image
that
that
we
published.
So
what
you
do
is
you
call
code
sign
attached.
You
can
attach
to
images
basically
any
file,
but
the
most
common
things
that
you'll
see
within
cosine
are
s-bombs
signatures
and
not
the
stations
at
the
station.
B
And
so
that
one
took
the
image
and
attached
it,
and
so
let
me
if
I
go
back
here
to
the
list
of
layers
now
I
have
a
second
layer
here,
which
is
the
s1
magist
I
just
produced.
So
all
of
this
is
what
happens
inside
of
the
kubernetes
staging
process
right
and
if
I
were
to
be
a
one
of
the
projects
under
the
under
the
kubernetes
organization.
I
would
have
my
images
staged
at
this
point
and
they
would
be
ready
to
promote.
A
B
A
D
A
B
A
B
B
I'm
going
to
switch
to
my
work
accounts
to
do
some
of
this,
so
now
we
saw
the
cosign
part
and
creation
and
signing
s-bombs,
and
now
we're
going
to
switch
to
the
actual
promoter,
so
the
promoter
k-promo
has.
It
also
does
a
lot
of
things,
but
the
main,
the
main
part
we're
going
to
be
focusing.
Is
this
this
part,
cip,
which
is
container
image
promotion.
B
So
these
are
other
images
that
I
have
in
the
same
registry,
and
this
is
a
basically
a
yaml
file
that
describes
the
contents
of
the
registry,
it's
stored
by
by
the
the
digest
of
the
images
and
the
attacks
associated
to
them,
and
this
is
I
just
outputted
it
to
to
to
show
how
promoters
the
promoter
sees
the
registries.
But
the
idea
is
that
you
can
that,
yes,
that
you
can,
you
should
build
your
manifests
using
that
information.
B
So
let
me
show
you
the
way
it's
structured,
so
I
think
that
that's
that's
yeah!
You
can
see
it.
So
the
promoter
uses
a
series
of
files
which
are
split
in
this
particular
way.
It
it
has
a
the
the
promoter
manifest
which
lists
the
registries,
and
then
it
has
another
file.
That's
called
images
general,
where
the
actual
collection
of
images
that
we
just
saw
is
is
stored.
B
Have
more
projects,
I
would
have
more
of
these
directories
each
with
their
own
manifests
and
but
it's
one
big
configuration
that
gets
added
between
all
of
the
files
and
and
that's
the
way.
If
you
see
the
the
gate
sim
for
repositories,
that's
the
way
that
they
are
configured
right.
So
this
is
the
actual
contents
of
the
of
the
of
the
manifest.
B
D
A
B
B
B
Exactly
yeah,
one
thing
to
note
is
that
currently,
the
the
identity
of
the
service
account
that
we
will
be
using
to
sign
is
hard
coded
into
the
register
into
the
promoter
code,
because
I'm
I'm
it's
not
finished
yet
and
I'm
using
it
to
test.
But
but
the
idea
is
that
we
will.
We
will
be
exposing
a
flag
to
pass
a
service
account
for
that.
B
B
So
projects
so
projects
will
be
using
by
default
the
account
of
of
the
kubernetes
organization
when
promoting.
But
if
you
were
to
run
the
promoter
by
yourself-
or
maybe
we
could
even
expose
it
here,
if
you
don't
want
to
use
the
the
kubernetes
identity,
but
that's
not
a
plan,
that's
not
planned
yet,
and
no
one
has.
Since
this
is
not
yet
running,
we
haven't
heard
it
of
anyone,
but
it
could
be
potentially
done
that
way
as
well.
B
I
see
okay,
so
I'm
going
to
dump
the
information
of
the
of
the
snapshot
of
my
source
registry
to
the
image
to
the
to
the
manifest
to
make
to
to
to
seat
it
with
the
images
that
are
stored
in
the
in
in
the
source
registry.
So
if
I,
if
I
take
a
look
at
the
file
that
I
just
created,
it
has
the
the
swamps
and
the
images
that
we
created
right
so
now
the
promotion
time.
B
Exactly
we
should
be
able
to
see
that
all
of
that
happening
live
so
without
further
ado.
This
is
the
way
you
do
it.
You
pass
this
flag
to
the
promoter,
then
manifester,
which
points
to
the
to
the
directory
where
all
of
the
manifests
live,
and
then
you
pass
confirm
to
it,
because
if
you
don't
pass
confirm
to
it,
it
will
just
tell
you.
The
images
will
be
too,
that
are
candidate
promotions,
promotional
candidates,
but
we're
going
to
do
the
actual
promotion
now
and
see
if
it
works.
So,
let's
see
and
if
it
works.
B
Yeah,
so
let
me
go
back
to
the
to
the
to
the
beginning.
So,
okay,
so
it's
it's
the
first.
The
first
thing
it
does
is
read
the
registries
to
determine
there's
lots
of
lots
and
lots
of
debug
info.
This
is
supposed
to
to
run
in
in
the
post
submits
and
it's
very
verbose,
because
if
something
breaks
you
can
go
in
there
go
and
check
there.
B
So
it's
so
every
time
it
mentions
an
edge
like
like
here
it's
one
of
the
difference
between
the
one,
the
two
registries.
So
it's
it's
an
image
to
that
it's
going
to
be
promoted,
so
it
goes
and
checks
what's
in
the
target.
What's
in
the
source,
builds
up
a
list
of
what's
going
to
be,
and
here
it's
starting
to
look
for
signatures
of
the
things
that
it's
finding
in
the
sources
so.
D
B
B
Yeah
yeah
yeah,
it
checks
actually
all
of
the
images
all
of
the
the
layers
that
are
candidates
to
be
promoted.
All
of
the
references
are
are
checked
for
signatures
right,
and
so
here
it
found
one
one
of
the
one
of
the
signatures.
What
was
found
and
it,
and
it's
checking
against
sister,
to
ensure
that
the
signature
is
valid.
A
B
B
If
you
sign
the
manifest
you
sign
the
shout
out
of
the
manifest,
then
you
ensure
that
that
chat
cannot
be
falsified,
since
it
addresses
the
actual
images
by
its
their
digest
as
well.
They
cannot
be
modified
because
the
digest
is
the
actual
content
reflection
of
the
content,
so
that
the
whole
chain
cannot
be
modified.
If
you
flip
one
bit,
all
of
the
chain
breaks
right,
right
right
makes
sense.
B
A
B
B
A
B
B
D
B
A
A
B
Right
this,
this
second
signature
that
I'm
adding
the
first
one
was
with
my
github
email
right,
which
would
be
equivalent
to
the
to
the
release,
engineering,
correct,
correct
and
the
the
next
one
is
using
this.
This
test
account
here
right,
which
is
simulating
what
would
be
the
kubernetes-wide
organization
item
right
right
and
if
you
see
here,
it's
signing
the
actual
image,
we're
also
going
to
sign
the
digest.
D
B
B
D
B
B
We
loaded
the
images,
so
if
I
refresh
this
here
are
all
the
promoted
images,
so
you
can
see
that
we
have
a
lot
of
stuff
here,
because
we
not
only
have
all
of
the
images
multi-arch
images
that
we
built,
but
we
also
have
the
signatures
for
each
of
them.
So
if
you
see
here
6660
nice,
so
what
this
means
is
in
our
in
our
original
image,
you
can
point
before
promotion.
B
You
can
point
cosign
to
verify
they
manifest
and
it
will
tell
you,
but
if
you
point
cosign
to
one
of
the
child
images,
it
will
not
find
a
signature
because
those
are
not
signed
correct.
It
doesn't
mean
that
it
they
are
less
secure
because
the
manifest
is
still
signed,
but
there's
no,
but
in
the
case
of
the
image
promoter,
since
we
have,
we
are
working
at
the
image
level
we
get
signatures
for
all
I
mean
at
some
point.
We
could
modify
it
to
only
send
the
manifests,
but
I'm
not
I'm
not
sure.
A
D
B
D
B
B
B
B
Okay,
so
this
is
an
important
part.
So
since
we
are
working
and
so
there's
a
team
of
volunteers
already
working
to
make
to
bring
to
bring
the
the
six
of
projects
to
general
availability
and
it's
undergoing
lots
of
infrastructure,
revamps,
it's
undergoing
stress
and
other
and
penetration
tests,
and
all
that
and
once
once
everything
is
verified
and
ready
to
go,
this
experimental
flag
will
be
dropped
and-
and
you
will
be
able
to
verify
and
do
everything
without
without
passing
the
the
variable.
D
B
B
C
A
Verify
one
one
thing
here
is
for
folks
who
work
in
environments
where
they
are
not
able
to
pull
something
directly
from
internet
and
still
want
to
verify
the
signatures.
Would
they
would
be
able
to
still
do
it?
But
then
the
only
thing
is
they
have
to
have
the
public
keys
available
for
them,
which
they
can
maybe
download
offline
from
t
logs
and
then
very
and
then
pass
it
on
as
a
flag
when
verifying
it
or
yeah.
B
A
Right
well
but
like
for
somebody
who
wants
to
verify
kubernetes
images
and
they
are
signed
by
the
full
co
route
and
kubernetes
project
for
them.
If
they
want
to
do
keyless
verification,
they
won't
be
able
to
do
it,
because
I
can't
pull
my
public
key
so
then
they
would
have
to
pass
that
public
key
as
a
flag
in
before
verification,
correct.
B
D
B
A
A
B
And
this
is
the
second
signature,
and
now
the
reference
points
to
the
new
one.
An
important
thing
to
note
is
that
both
of
those
at
the
stations
are
valid
for
and
they
don't,
the
the
actual
docker
reference
does
not
matter,
because,
since
we
are
assigning
the
digest
of
the
image,
they
are
valid
in
the
in
the
either
of
those
stations
and
can
be
used
to
verify
images
in
the
source
repository
or
in
the
target.
Repository.
B
B
A
A
A
Right,
I
I
think
we
almost
close
to
a
couple
of
hours
since
we
began,
maybe,
as
we
wrap
up,
I
wanted
to
explore
things
from
an
end
user
perspective.
Like
okay,
you
have
kubernetes
community
signed
images.
I
am
very
happy
and
as
an
end
user,
I
want
to
now
use
it
and
make
sure
I
can
verify
it
whenever
I
spin
up
a
static
board
of
of
my
kubernetes
components.
A
But
one
of
the
things
I
was
wondering
is
that
wouldn't
work
for
api
server
because
for
api
server
to
come
up,
you
need
that
for
admission
controller
to
be
used,
you
need
api
server
and
for
you
can't
verify
api
and
with
an
admission
control
because
it
doesn't
exist,
so
you
could
use
it
for
things
like
cube
proxy
or
conformance
images,
I'm
guessing,
but
things
like
api
server
control
manager.
Scheduler.
If
I
have
to
verify
it,
how
would
an
end
user
do
it?
B
Definitely
for
the
api
server,
it
cannot
be
used,
I'm
not
sure
if,
for
the
notes,
probably
not,
but
I'm
not
sure,
but
the
the
one
of
the
one
of
the
things
that
have
been
one
of
the
issues
that
has
been
raised
in
the
past
is
that
this,
the
verification
of
the
of
the
image
signatures
should
also
be
happening
at
the
runtime
level
so
that
the
container
runs
on
the
level.
I
think
the
the
first
person
to
note
this
to
me
was
sacha
sacha
gruner,
and
he
he
actually.
B
B
A
Yeah,
that
makes
sense,
and
I
almost
also
think
it
it
could
be-
a
spec
update
in
cri
implementations,
where
you
say
as
a
standard
for
container
runtime.
We
are
going
to
now
want
every
container
and
time
to
support
verification,
and
this
is
how
the
interface
would
look
like
and
then
container
id
cryo.
Everyone
can
come
up
and
implement
that
on
their
site,
so
that
any
runtime
will
have
the
exact
same
way
of
implementing
it.
A
D
D
B
Yeah
me
too
so
keep
an
eye
for
some
of
the
prereleases.
Hopefully
we
can
sign
the
next
ones
fingers
crossed
and
to
see
tools
getting
into
the
right
place
and
yeah,
and
if
I
would
like
to
invite
any
anybody
to
to
who's
interested
in
this
kind
of
subject,
matters
to
join
our
release.
Engineering
meetings
every
tuesday
we're
happy
to
to
see
you
there
and
come
ask
any
questions.
Collaborate
contribute.
If
you
want
to
to
have
you
there.
B
A
A
Yeah
exactly
okay,
so
I
think
it's
time
to
wrap
up
thanks.
Everyone
who
hang
hung
along
with
us
for
almost
two
hours
hope
you
learned
a
lot
and
for
folks
who
are
watching
the
recording
hope
you
enjoyed.
What
we
discussed
today
feel
free
to
share
your
feedback
on
twitter
or
any
other
way
that
you
can
find
us
and
then
we'll
be
more
than
happy
to
review.
It.
Learn
from
you
and
get
up
do
maybe
do
a
better
tgik
every
single
episode.