►
From YouTube: SIG Interoperability Meeting - Dec 2, 2021
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Yes,
somehow,
three
months
old,
no
I've-
I
was
there
in
between,
but
somehow
the
meeting
request
slipped
out
of
my
calendar,
not
sure.
B
And
oh
yeah,
you
know
the
meeting
invite
expired
just
before
this
summertime,
thingy,
no
daylight,
saving,
time
thing
and
original
invite.
I
sent
it
to
sid
interval
with
the
mail
list,
but
the
navy
might
kara
said
team
right.
I
think
she
has
forgotten
to
send
it
to
the
mail
list
which
I
can
do
so
you
get
the
invites
on
your
calendar
yeah.
I.
A
B
So
have
you
had
the
chance
to
look
at
the
road
map
I
think,
like
you
know,
we
started
refreshing
it,
so
we
will
talk
about
it
anyway,
anyways
when
we
start
the
meeting,
but
just
not
yet,
but
it's
on
my
list.
B
A
B
B
C
D
B
B
So
the
agenda
is,
as
usual,
action
item
review
and
then
we
will
quickly
take
a
look
at
the
road
map.
Then
we
can
have
a
chat
on
the
white
paper.
We
finished
speaking
of
this
year.
I
think,
and
then
we
move
the
stage
to
them
and
then
learn
about
six
store,
so
the
action
items.
The
first
action
item
is
on
cara
and
me
and
that's
about
the
roadmap,
which
we
will
talk
about
it.
B
Maybe
we
can
close
the
ex
nightmare
and
then
take
the
topic
again
after
we
have
some
updates
on
the
roadmap,
which
may
result
in
additional
action
items,
and
the
other
action
item
is
on
cara
to
present
the
work
we
are
doing
in
here
to
end
user
console
which
I
keep
it
open.
Kara
is
off
this
week,
so
she
won't
be
able
to
join.
So
I
keep
the
x
night
one
and
that's
all
action
items
we
had
now
the
road
map.
B
So
to
recap
what
we
discussed
during
previous
meetings
and
as
written
on
the
agenda,
the
roadmap.
I
think
we
released
the
first
version
around
summer
2020.
If
I
am
not
mistaken
yeah.
I
think
that's
when
we
released
it,
it's
almost
one
and
a
half
years,
and
we
have
done
a
lot
of
work,
especially
in
events
area
which
has
become
its
own
sick,
and
now
the
creation
of
siblings
was
also
approved.
B
So
in
addition
to
that,
I
think
during
one
of
the
first
meetings
ramen
mentioned
that
the
policy
driven
cd
is
something
he
is
interested
to
see
and
we
got
similar
feedback
from
others.
When
it
comes
to
how
policy
they're
going
to
see
they
could
help
organizations
to
employ
guardrails
in
their
pipeline.
So
that
is
another
item
we
intend
to
include
in
the
roadmap
yeah
post-driven
cd.
So
those
are
the
two
potential
new
entrants
to
our
roadmap.
B
While
we
move
events
to
you
know
it's
something
we
accomplished
in
our
sikh
and
it
is
now
living
its
life
in
cd
events
and
sig
events,
and
the
other
things
in
the
roadmap
was
like
information,
knowledge
sharing,
which
we
have
been
doing
in
regular
manner.
So
I
think
that
is
something
we
can
consider
as
accomplished
and
we
will
continue
having
those
type
of
presentations
from
different
communities
to
keep
on
sharing
the
latest
developments
from
all
these
different
communities,
the
work
stream
setup.
B
B
And
the
visualization
topic
is
there,
and
this
is
kind
of
a
common
concern
for
events.
You
guys
are
because
you
can
use
events
to
visualize
your
pipelines
and
reach
traceability,
so
that
is
then
we
can
discuss
on
the
roadmap
directly
and
then
pipeline.
Standardization
languages
is
something
we
haven't
looked
at
yet,
but
there
were
few
people
who
want
to.
You
know
have
some
kind
of
standardization
when
it
comes
to
doing
some
kind
of
pipeline
s
code
and
so
on.
B
We
can
continue
discussing
on
the
roadmap
as
well,
and
the
last
focus
area
was
integration
with
the
tools
that
are
not
traditionally
seen
as
crcd
tools.
Again,
this
is
a
common
interest
between
interval,
sig
and
event
seek.
I
believe,
unseek
has
ideas
on
this,
because
the
events
will
not
be
specific
to
cicd
orchestration
tools,
but
they
could
be.
You
know,
employed
by
other
tools.
That
may
not
be
seen
as
traditional
ci
cd
tools.
Again,
we
can
keep
this
as
an
item
in
our
roadmap
to
look
at
further.
B
I
take
that
as
no,
let
me
put
the
link
to
chat
one
thing.
Perhaps
then
it
would
be
cool
to
get
your
opening
about
is
like
it's
related
to
its
interoperability
between
the
cicd
pipelines,
orchestrators
and
security,
vulnerability
tools
or
the
tools
that
are
active
in
security
or
supply
chain
domain.
So
the
interaction
between
those
tools
and
pipelines
could
be
something
we
can
take
as
a
discussion
point
when,
after
your
presentation,
perhaps
so,
we
can
highlight
that
under
supply
chain
topic
in
the
roadmap.
B
B
D
B
Yeah
I've
seen
spdx
referred
in
events,
six
meetings
like
two
weeks
ago
or
something
so
it's
like
again,
we
are
seeing
like
there
will
be
like
we
will
be
converging
on
these
topics:
anyways
but
yeah
how
to
communicate
these
things
with
those
communities.
So
we
can
find
you
know,
opportunities
colorway.
But
let's
take
that
after
your
presentation
then-
and
that
was
the
roadmap
and
you
have
the
link
in
the
chat.
B
So
that
was
the
roadmap
and
the
interworldwide
paper.
I
think
the
white
paper
is
in
kind
of
a
bit
weird
state
right
now,
because
we
talked
about
events
in
the
white
paper
and
now
events
has
its
own
sea
and
we
have
a
project
which
we
are.
We
all
are
pretty
excited
about
it.
So
now
that
development
puts
the
you
know
white
paper
in
a
weird
situation.
B
Maybe
we
should
look
at
the
white
paper
again
and
refresh
it
or
maybe
even
stick-
has
an
idea
to
come
up
with
its
own
white
paper.
So
that
is
something
we
need
to
take
into
account
and
the
other
thing
in
the
white
paper
we
talked
about
metadata
stuff
as
well,
and
perhaps
policy,
but
now
those
topics
are
they
fall
under
this
broader
supply
chain
topic
again.
That
will
be
something
we
may
need
to,
or
we
think
about
like
how
we
can
associate
interoperability
versus
supply
chain.
So
I
think
we
missed.
B
B
C
Just
to
refresh
my
memory,
what
was
the
as
far
as
I
remember,
the
last
state
was
that
we
delivered
it
over
to
the
creator
team
and
they
were
supposed
to
do
something
and
then
nothing
happened
or
was
there
something
else
that
we
should
have
done?
C
B
B
B
I
think
it
was
like
before
summer
or
something
like
that.
So
that
is
the
state
the
white
paper
was
in,
but
let
me
take
an
action
item
on
me
and
check
with
tracy,
if
anything
that
we
need
to
do
there
to
or
make
it
better
for
creative
team
to
make
the
white
paper
presentable
for
different
audiences.
I
think
it's
about
the
question
of
having
different
audiences
because
it
will
not
be
just
the
you
know:
cicd
communities
or
developers,
but
we
hope
this
paper
will
be
read
by
decision
makers,
managers
or
such
audiences.
C
Yeah,
it's
just
so
it's
clear
what
if
it
was
something
more
from
us
need
to
do,
because
that
was
not
clear.
For
me
at
least.
B
Yeah,
I
think
we
we
were
kind
of
done,
but
this
you
know
reorganizing.
The
white
paper
was
hunting.
Tracy
highlighted
last
time.
We
talked
about
this
topic
but
yeah.
I
took
an
action
and
I
will
check
this
with
tracy
again
yeah.
We
need
to
reorganize
the
white
paper
anyways.
Now,
with
the
you
know,
cd
events,
events
and
supply
chain
aspects,
so
yeah
that
works
still
standing
to
be
done.
B
B
D
Sure
oh
screen
share
over
here
I
don't
have
a
super
formal
like
beginning
to
end
presentation.
I've
got
a
couple
slide
decks
from
before
and
some
demos
and
stuff,
and
we
can
kind
of
hop
around
between
them
and
answer
questions
as
we
go.
So
the
overall
goal
is
to
talk
about
the
sig
star
project.
So
let
me
find
tap
to
screen
share
that.
D
Yep,
yes,
awesome,
which
should
be
good
now,
cool
yeah
so
again
feel
free
to
interrupt
it
anytime,
I'm
going
through
here
and
just
speak
up,
because
I
can't
see
the
hamstrings
or
anything
like
that.
Yeah
I've
got
a
couple
slide
decks
here.
We
can
do
some
demos,
like
I
said,
and
some
documentation
on
the
websites
and
that
kind
of
thing
to
jump
around
between,
but
first
I'll
start
out
with
just
kind
of
a
high
level
overview
of
the
overall
c
store
project.
D
D
The
easiest
way
to
describe
it,
I
think,
is
probably
what
I
like
is
google
six
stores
to
basically
try
to
be
the
let's
encrypt
of
code
signing
and
if
you
think,
back
to
what
the
internet
was
like.
You
know
six
seven,
eight
years
ago,
before,
let's
encrypt
really
got
adoption
most
websites
weren't
using
tls
and
certificates,
that
little
red
x,
the
scary
accent
something
wasn't
over
https.
D
It
was
only
over
http,
it
was
pretty
common
way
more
common
than
it
should
have
been
right
there,
even
banks
and
financial
institutions
and
places
sending
passwords
unencrypted
over
http-
and
this
is
true,
even
though
certificates
and
browsers
have
been
around,
for
you
know,
20
plus
years
back
dating
back
to
the
early
90s.
D
They
just
weren't
really
that
adopted,
because
it
was
hard
to
use
them.
It
was
hard
to
get
them
right.
You
had
to
go,
find
a
certificate
authority.
You
had
to
pick
one
out
of
the
dozens
you
had
to
pay
them
some
money
with
a
credit
card.
Some
of
them
were
kind
of
sketchy.
D
D
Folder,
hopefully
get
it
in
the
right
place
and
then
maybe
your
website
would
actually
serve
correctly,
and
then
you
had
to
remember
to
do
it
again
in
a
year
because
they'd
expire,
if
you
forgot
the
certificate,
wouldn't
be
trusted
anymore,
and
you
know
it
was
a
big
mess.
D
We
looked
around
at
the
kind
of
open
source
software
supply
chain,
ecosystem
and
landscape.
Sometime
in
2020,
I
think,
is
when
this
effort
basically
kicked
off
and
kind
of,
did
a
survey
and
found
that
you
know
a
lot
of
the
same
problems
existed
here.
There
were
ways
to
sign
code,
but
nobody
was
doing
it.
D
There
was
the
pgp
kind
of
web
of
trust
ecosystem
that
never
got
critical
mass
and
relied
on
people
preserving
their
keys
and
sharing
them
at
parties,
and
then
there's
kind
of
the
parallel
ecosystem
set
up
for
code.
Signing
certificates
which
are
exactly
like
web
browser
certificates.
D
You'd
buy
them
have
to
do
some
kind
of
identity
check
to
prove
who
you
are.
If
you
weren't
a
real
business,
it
was
really
hard
to
get
them.
They
were
like
500
and
they're
only
good.
For
a
couple
years.
You
had
to
make
sure
not
to
lose
them,
so
nobody
was
really
doing
it
unless
you
had
to
because
you're
trying
to
ship
software
and
like
the
windows,
drivers
or
one
of
the
app
stores
that
required
certificates.
D
So
we
said
what,
if
we
kind
of
do
the
same
thing
that's
encrypted
and
set
up
an
automated
api
for
getting
certificates
we'll
make
them
super
short-lived,
so
you
don't
have
to
worry
about
renewing
them.
You
just
get
a
new
one,
each
time
and
then
try
to
build
tooling
to
automate
all
of
it
and
so
at
a
high
level.
That's
basically
what
sig
store
is
all
the
different
components
are
set
up,
just
to
make
it
easy
to
get
certificates
and
publish
them
and
discover
them
for
your
code.
D
So
you
don't
need
to
buy
anything.
It's
completely
free,
it's
community
run.
It
is
a
kind
of
separate
project.
As
part
of
linux
foundation,
the
infrastructure
is
managed
by
the
community.
The
certificate
authority
is
managed
by
the
community,
and
so
it's
all
free
for
open
source
and
everything
the
complicated
technology
powering.
It
is
a
whole
bunch
of
transparency,
a
lot
even
time
stamps
and
cryptographic.
Proofs
and
everything,
but
as
an
end
user,
you
don't
really
have
to
worry
about
that.
D
You
can
just
sign
code
with
a
simple
command
without
having
to
worry
about
keys.
You
can
verify
your
code
with
another
command
without
having
to
worry
about
how
to
find
keys
for
people
and
trust
that
everything
is
being
run
correctly,
because
it's
all
using
transparency,
logs
and
transparent
infrastructure.
So
people
can
monitor
and
audit
this
to
make
sure
nothing.
Bad
is
happening.
D
These
are
the
different
components.
Kind
of
listed
out
down
here
do
some
demos,
but
we
started
with
automation
with
the
cosine
command,
which
allows
you
to
sign
and
verify
container
images
that
are
part
of
the
oci
or
open
container
initiative
specification.
D
D
One
of
the
other
cool
benefits
of
using
the
oci
spec
is
that
you
can
use
that
for
things
other
than
container
images
too,
which
is
great
for
an
interoperability
perspective.
You
can
store
any
type
of
artifact
in
oci
registries
now,
so
people
use
it
for
distributing
other
types
of
binaries
one
big
example:
there
is
homebrew
really
with
homebrew
it's
the
package
manager
for
mac.
They
switched
to
using
the
github
container
registry
for
hosting
and
distribution
of
all
those
binaries.
D
Even
though
they're
not
container
images
stuff,
like
wasm,
uses
this
specification
as
well
now
to
avoid
having
to
reinvent
a
new
package
manager
for
a
new
ecosystem,
so
it's
set
up
for
containers,
but
it
really
works
with
anything
stored
in
one
of
these
registries,
which
is
starting
to
expand
beyond
containers
because
of
the
kind
of
vendor
neutral
specifications
that
are
present.
D
This
works,
though,
using
these
other
components
on
the
right,
recore
and
full
co.
So
record
is
the
name
for
the
transparency
and
time,
stamping
service
that
we
use.
D
This
is
the
transparency
log
that
stores
all
of
the
records
for
signatures
and
artifacts,
and
that
kind
of
thing,
if
you're
not
too
familiar
with
transparency
like
they're,
very
kind
of
subtle
and
a
lot
of
moving
parts
there,
but
you
can
kind
of
think
of
them
as
an
append,
only
log
that
can
be
verified
and
to
be
append
only
so
if
one
person
is
running
a
transparency
log,
you
can
add
entries
to
that
log
and
you
can
make
sure
that
they
haven't
tampered
with
any
of
the
previous
entries
or
deleted
any
of
the
previous
entries.
D
D
D
This
is
critical
to
web
security
because
it
prevents
somebody
from
accidentally
or
maliciously
issuing
a
certificate
for
a
domain
that
they
shouldn't.
Have
you
can
imagine
how
bad
it
would
be
if
a
small
ca
issued
a
certificate
for
google.com
or
microsoft.com,
or
something
like
that
they
could
man
in
the
middle
or
hijack
all
of
that
traffic.
D
D
This
is
what
actually
issues
code
signing
certificates
to
people
and
systems
and
machines
and
ci
cd
pipelines,
and
all
that
so
going
back
to
the
let's
encrypt
analogy:
the
first
time
you
get
a
certificate
for
a
domain
with,
let's
encrypt,
they
do
a
series
of
challenges
to
prove
that
you
actually
own
that
domain.
That's
what
kind
of
provides
the
security
guarantees
before
they
give
you
a
certificate
for
your
website.
D
They
make
sure
that
you
actually
own
the
domain
and
so
you're
authorized
to
get
certificates
for
that
with
let's
encrypt,
they
had
to
kind
of
invent
some
new
standards
because
nothing
existed
here
and
those
standards
are
referred
to
as
acme.
I
forget
what
it
stands
for,
but
those
are
you
know
real
ietf
adopted
standards
for
these
challenges.
They
look
something
roughly
like
you
know,
calling
out
encrypt
api.
D
They
give
you
a
random
token,
and
you
have
to
put
that
token
somewhere
in
the
dns
record
for
the
domain
or
an
http
header,
or
something
like
that,
something
that
only
the
operator
and
owner
of
that
domain
should
be
able
to
do,
and
then
they
query
the
dns
records
until
they
see
that
challenge
and
then
you're
issued
a
certificate.
It
turns
out
that
with
developers
and
people
there's
actually
already
a
great
set
of
apis
to
do
those
challenges.
So
we
didn't
need
to
invent
anything
new.
D
It's
basically
referred
to
as
open
id
connect
or
oidc,
and
that's
what
happens
when
you
want
to
authenticate
with
google
or
authenticate
with
github
or
one
of
the
identity
providers
on
a
different
site,
if
you
ever
click
the
login
with
google
or
log
in
with
github
button.
That's
what's
happening
here,
your
browser,
pops
open
to
that
site.
You
click,
ok
and
then
the
two
services
share
proof
that
you
are
that
actual
person
so
based
on
that
standard,
full
seo
kind
of
pops
open
your
browser
and
you
click
log
in
with
google.
E
E
Can
you
run
your
own
copy
of
it
for
testing
or
to
bootstrap
your
own
separate
community
of
of
code,
signing
et
cetera.
D
Yeah
great
questions-
and
I
was
really
a
little
imprecise
there
yeah.
So
this
is
all
open
source.
It's
all
here
at
github.com,
a
lot
of
stars,
a
lot
of
it
option
all
that
fun
stuff.
The
different
components
are
in
here
there's
some
other
valve
repos
and
stuff
like
that.
So
this
is
all
free
to
use
and
the
community
run
infrastructure.
So
this
is
why
it's
a
little
subtle.
So
all
the
code
is
free
right.
All
the
code
is
open
source
under
permissive
licenses.
D
D
That's
the
transparency
log,
the
certificate
authority
and
some
other
global
services,
that's
also
free
to
use
and
run
by
the
community
and
some
corporations
that
sponsored
the
infrastructure,
the
kind
of
subtle
part,
though
you
know
it's
technically
free
for
anyone
to
use,
but
everything
is
public,
so
you
can
sign
and
throw
stuff
on
here.
That's
like
you
can
sign
a
closed
source
code,
but
you
have
to
accept
that
it's
going
to
be
public
on
this
record.
D
Sometimes
that's!
Okay,
right!
If
you're
distributing
a
binary,
that's
built
from
closed
source,
you
might
still
want
to
sign
that
binary
and
put
that
on
the
public
record.
But
if
it's
like
internal
stuff
that
you
never
distribute
outside
of
your
company,
then
it
might
not
be
appropriate.
You
might
not
want
to
leak.
You
know
the
different
builds
you're
doing
on
this
public
record,
so
you
can
run
these
components
internally
as
well.
D
Some
of
it
isn't
completely
relevant,
but
yeah
it's
kind
of
mix
and
match
the
transparency.
Log
itself,
in
particular,
doesn't
always
make
sense
to
run
internally
the
way
transparency
logs
work
is
they.
You
know
kind
of,
can
issue
challenges
to
prove
that
things
haven't
been
tampered
with,
and
you
only
really
get
the
tamper
proof
guarantee
if
you
have
like
a
third
party
or
somebody
else,
actually
auditing
blog,
and
so,
if
you're
running
this
internally,
then
sure
it
probably
won't
be
tampered
with.
D
But
unless
you
have
somebody
kind
of
in
a
separate
trust
domain
and
verifying
it
you're
not
actually
kind
of
taking
advantage
of
those
guarantees
but
yeah
some
of
the
other
components
still
make
sense
to
run
internally
like
the
certificate
authority
and
the
different
signing
tools
and
everything
so
yeah.
The
open
source
community
infrastructure
is
free
for
anyone.
If
you're
willing
to
accept
the
kind
of
public
nature
of
it.
Does
that
answer
that
question.
D
One
of
the
other
interesting
points
of
the
community
infrastructure
I'll
get
into
here,
quick
before
I
jump
into
the
presentation,
because
I
don't
think
this
is
covered
too
well-
is
actually
the
cryptographic
route
of
trust
that
we
maintain
here
for
the
community,
so
the
the
short-lived
certificates
and
everything
like
that
are
cool
because
you
don't
have
to
manage
keys,
but
that
still
doesn't
really
solve
the
entire
problem
right.
This
all
just
changed
back
up
to
a
different
route
of
trust
with
browsers.
D
This
is
managed
by
like
the
kind
of
browser
forum
has
a
root
ca
kind
of
program
where
they
publish
requirements
on
how
people
have
to
operate
their
certificate
authorities.
And
if
you
do
that
correctly,
then
you
can
get
your
search
trusted
by
browsers,
which
is
how
it
works
on
the
internet
that
doesn't
really
exist.
So
we
kind
of
had
to
bootstrap
something
here
too
for
open
source
signing,
and
so
we
maintain
this
kind
of
community
cryptographic
trustworth
again
in
the
community
and
in
the
open.
D
So
this
is
the
repository
that
contains
all
the
keys
that
sign
everything
else.
In
the
six
store
trust
route,
so
there
are
five
community
members
that
actually
hold
physical
hardware
tokens.
These
are
the
you
know,
yubikeys
or
something
similar,
and
we
need
a
kind
of
quorum
of
those
five
to
actually
make
any
changes
to
the
cryptographic
trust
route
here.
So
this
is
set
up
using
the
update
framework
or
tuff,
which
is
another
open
source
project
on
the
linux
foundation.
D
It
provides
protections
for
rotating
the
keys,
moving
people
in
and
out
expiration
and
all
of
that
stuff.
So
the
initial
one
was
bootstrapped
in
a
live
streamed
youtube
ceremony:
it's
called
which
you
can
watch
where
you
know,
people
from
the
community
watched
and
verified
each
step
of
the
way,
and
it
was
all
done
kind
of
in
a
pull
request
flow
where
we
all
kind
of
took
the
keys
out
of
the
packages
held
them
up
to
the
cameras
that
stuff
to
show
that
they
weren't
tampered
with
published.
D
So
this
repository
is
the
actual
trust
group
for
everything
else
and
it's
you
know
been
forked
and
cloned
all
over
the
place,
so
it
can't
be
tampered
with
and
then
every
couple
months
we
have
to
get
back
together
and
resign,
something
before
it
expires
here
and
so
everything
else
kind
of
changes
back
up
to
this.
This
is
pretty
cool.
D
A
lot
of
companies
do
something
similar
internally
with
kms
systems
or
hardware-backed
tokens
and
cloud
providers
even
offer
a
lot
of
those
as
services,
but
that
stuff
doesn't
really
work
in
a
distributed
environment
where
you
don't
really
trust
the
other
people.
D
This
was
a
pretty
fun.
We
had
probably
a
couple
hundred
people
watching
live
when
we
did
the
first
ceremony
cool
any
questions
on
that
before
I
jump
back
over
here.
D
E
Yes,
one
one
quick,
maybe
two
deep
question
the
multi-part
keys,
so
the
the
solution
there
using
something
like
shimmer
secret,
key
sharing
or
some
other
mechanism.
D
D
Let
me
see
if
I
can
find
the
right
file
in
here
just
forget
how
these
are
set
up:
yeah,
okay,
so
it's
really
just
a
simple
kind
of
json
file
that
lists
the
actual
keys
and
then
the
policy
requiring
how
many
of
them
have
to
be
used
to
sign
and
make
a
change
and
then
all
those
keys
kind
of
sign
the
initial
ones
you
to
self-signed
root.
So
it's
not
anything.
Super
fancy.
Crypto,
like
shamir
just
says
here-
are
the
five
keys
in
the
route
and
then
there's
a
threshold
in
here
somewhere.
D
So
this
says
when
it
expires,
we
have
to
sign
a
new
one
before
this
date.
This
was
the
original
one.
So
we've
actually
signed
a
couple
since
then,
and
then
there's
you
know,
roles
and
delegations.
So
you
can
say
you
know,
sub
keys
can
sign
certain
things
and
then
here's
the
threshold.
So
unless
you
have
three
out
of
the
five,
you
can't
make
any
changes
to
these
things.
That
makes
sense
so
the
nice
part
you
can
do
this
with
any
kind
of
algorithm
selection
like
schmuters.
D
I
don't
think
you
can
quite
do
it
with
anything.
There's
like
rsa.
You
see
the
two
five
five
online,
all
that
fun
stuff
and
it's
also
a
little
bit
more
explicit
so
like
with
schumer's.
If
you
wanted
to
set
it
up
with
like
three
out
of
five,
then
I
think
you
can't
actually
see
which
three
did
it
and
stuff
like
that
which
is
nice
in
some
cases,
but
here
it's
a
little
bit
more
explicit,
so
you
can
see
which
keys
signed
it,
which
keys
haven't,
who
you're
still
waiting
on
and
that
kind
of
thing.
E
Cool
like,
like
the
threshold
cryptography
that
mesh
is
using.
E
So
it's
still
in
development,
but
okay,
never
mind.
D
Yeah
awesome
yeah.
So
if
you
look
this
up,
if
you
want
to
look
get
in
more
details
about
how
this
works
out,
it's
part
of
the
the
update
framework
and
there's
a
whole
specification
and
all
the
different
things
that
are
addressed
here
with
the
roles
and
the
time
stamps.
All
that
fun
stuff,
there's
a
whole
world
of
supply
chain
attacks
and
with
package
managers
and
update
systems
that
the
update
framework
addresses
they
might
not
have
ever
even
considered.
It
goes
very
deep.
D
Cool
yeah,
so
here
basically
stats
hundreds
plus
contributors,
a
whole
bunch
of
companies
involved
lots
of
github
stars
that
fun
stuff.
I
think
we're
actually
getting
close
to
a
million
log
entries
now,
a
little
old
and
there's
work
going
on
now
to
actually
make
it.
So
we
can
shard
that
log
and
migrate
it
if
we
ever
have
to
and
fun
stuff
that
way.
D
So
if
you
want
to
get
involved,
yeah
there's
a
lot
of
projects.
There's
developer
tooling
integrations
for
signing,
there's
infrastructure,
you
can
help
run
release
engineering,
a
lot
of
fun
ways
to
get
involved
and
help
out.
D
Let's
see
what
I'll
talk
about
next,
I
guess
I
can
try
doing
some
demos,
quick,
showing
how
this
works
with
containers.
Would
that
be
interesting.
D
Yes,
awesome,
so
let's
go
into
the
cosine
directory.
I'll
clean
up
might
have
two
cool,
I'm
just
going
to
delete
all
the
signatures.
Get
my
image.
All
cleaned
up.
People
see
my
terminal
or
should
I
make
it
bigger.
D
Okay
cool,
so
this
is
just
anything
going
on
here:
yeah
cool
do
a
build,
so
this
is
cosine.
It's
the
easiest
way
to
get
started.
This
is
I'll,
go
so
there's
a
bunch
of
different
commands
and
things
in
here.
D
All
right,
this
should
be
right,
repo
now
yeah.
So
this
is
all
hosts
on
github.
There's
a
couple
different
binaries
in
here
actually
including
like
some
kubernetes
integrations
and
that
kind
of
thing,
but
the
cosine
command
line
tool
itself
is
easiest,
so
we
can
do
cosine
and
see
all
different
sub
commands.
There's
a
lot
of
stuff
going
on
here.
D
Even
some
work
with
stuff
like
s-bombs
and
other
types
of
attestations.
The
easiest
flow
here
is
actually
to
use
normal
keys
instead
of
the
fun
keyless
certificate
of
34.
So
I'll
show
that
and
then
show
how
it
works.
If
you
want
to
not
manage
keys
too
so
the
first
way
we
get
started
with
generating
a
key
pair,
and
this
actually
supports
a
bunch
of
different
cloud
kms
systems.
D
If
you
want
to
use
that
gcp
vault
azure
aws,
all
that
stuff
as
funny
as
the
cloud-based
ones
or
you
can
just
leave
all
that
off
and
just
you
generate
keypair.
D
So
this
is
going
to
generate
one
on
disk,
so
I'll
do
type
in
your
passphrase,
so
it
can
get
encrypted
or
write
the
old
one
cool,
and
now
we
get
a
key
pair.
A
cosine
dot
key
and
a
cosine
dot
pub.
D
This
uses
basic
ec
dsa
stuff,
which
is
fips
compliant
and
meets
all
that
the
government
regulations
and
fun
stuff
I'll
show
you
what
it
looks
like
here,
I'll
start
with
the
public
key.
This
is
a
standard,
pki
or
x509
public
key
using
ecdsa
algorithm.
So
this
is
the
thing
you
want
to
share.
If
you
want
people
to
be
able
to
verify
your
signatures,
distribute
this
as
widely
as
possible.
D
I'll
show
the
secret
key
too.
This
is
the
thing
you
normally
don't
want
to
show
people,
but
it's
encrypted.
Actually,
so
nobody
can
do
anything
with
this
unless
they
also
have
my
passphrase,
which
I
didn't
show
so
it's
safe.
If
you
accidentally
check
one
of
these
in
to
get
and
publish
it,
there's
actually
some
cool
floats,
you
can
do
by
checking
them
in
on
purpose
which
I'll
show.
I
could
show
an
example
of
that
one,
but
yeah.
So
here
is
the
public
and
private
keeper.
D
So
now
we
are
going
to
sign
an
image
and
verify
it.
Let's
do
okay,
so
let
me
drop
experimental.
That's
for
the
cool
features
this
isn't
signed
right
now
right,
so
this
should
fail.
If
I
try
it
so
I'm
going
to
pass
in
the
public
key.
I
want
to
verify
against
because
I
cleaned
this
up
at
the
start
I
deleted
and
awesome.
It
fails
correctly,
no
matching
signatures.
D
D
And
now
it's
signed,
this
is
using
gcr,
but
you
can
do
this
with
github
any
registry
that
you're
kind
of
authenticated
against.
So
now,
if
we
want
to
verify
this
time,
it
should
work
yay.
So
it
says
all
the
checks
it
did.
We
didn't
use
certificates
or
anything
like
that,
so
those
checks
are
really
relevant
here,
but
we
verified
the
signature
itself.
Let
me
do
this
again,
but
pipe
it
to
jq,
so
you
can
see
what
we
actually
signed
and
verified.
D
So
I
signed
a
container
image
here
by
its
tag
right,
if
you
just
do
gcr.io
for
testing
slash,
distros
or
whatever,
that
implicitly
adds
a
tag
of
colon
latest
and
that
tag
can
move
around
so
we're
citing
something
like
a
pointer
in
this
case.
So
what
actually
happens
is
that
cosine
resolves
that
tag
to
the
digest.
The
digest
is
the
sha
256
identifier
for
that
image.
That
cannot
change
so,
instead
of
signing
something
that
can
change
and
move
around,
we
sign
the
digest
itself
right
here.
D
D
So
that's
kind
of
what
that
signature
looks
like
pretty
basic
can
just
express
whether
it's
signed
or
not.
You
can
sign
something
multiple
times
with
different
keys
with
the
same
key
and
kind
of
mix
and
match,
and
do
verifications
that
way.
You
can
require
like
two
people
to
sign
something
you
can
require
two
out
of
five.
You
can
build
up
that
threshold
stuff
or
you
can
say
any
one
of
these
three
keys.
If
you
want
to
support
some
basic
rotation,
there's
one
other
little
feature
I'll
show
here,
quick.
D
You
support
these
little
custom
annotations.
So,
if
you
want
to
say
you
build
up
which
you
can
use
these
annotations
to
build
up
more
complex
workflows,
if
you
want
to
so
here,
I'm
going
to
add
one
saying:
foo
equals
bar
now,
if
we
sign
or
if
we
verify
we'll
see
two
signatures,
the
first
one
which
had
no
annotation.
D
This
is
the
first
one
from
before
we've
added
a
second
one.
Now
that
does
have
this
kind
of
actual
set
of
annotations
and
I
didn't
specify
anything
for
verification,
so
I
got
it
all,
but
you
can
pass
those
same
flags
in
for
verification
now
and
now
we
should
only
see
the
second
one
yeah
awesome,
so
you
can
use
this
to
put
stuff
like
commit
information
or
time
stamps
or
release
version
numbers,
and
that
kind
of
thing
to
build
up
more
workflows.
D
D
Keyless
modes
now,
so
this
is
cool,
but
it
requires
you
to
kind
of
distribute
that
public
key.
Here's
one
example
of
how
to
do
that
before
I
jump
over
to
the
key
list
stuff
one
here
yeah.
This
is
a
little
example
showing
how
to
do
all
this
stuff
inside
of
github
actions
to
do
signing
and
verification.
D
In
this
one
I
actually
committed
the
private
key
and
again
it's
encrypted,
and
the
secret
is
stored
in
github
actions
as
a
secret.
But
what
this
allows
you
to
actually
do
by
committing
the
public
key
and
the
private
key
is
you
can
easily
rotate
right
in
the
github
action
here?
What
we
actually
do
is
stick
the
commit
hash
that
the
container
was
built
in
in
that
annotation
field.
D
So
if
you
ever
want
to
change
these
keys
at
any
point,
you
can
just
kind
of
blow
them
away,
add
new
ones
to
the
repo
and
a
new
commit
and
push
that
commit,
and
because
we
sign
the
commit
itself,
you
kind
of
get
this
self
circle
of
the
commit
telling
you
which
key
to
verify
against.
So
you
can
go
to
the
repo
you
can
see
which
commit
the
thing
was
built
at
and
you
can
look
up
the
right
key
to
verify
it
against
just
with
this
kind
of
inband
rotation
mechanism.
D
D
D
Because
experimental
mode
is
turned
on,
this
is
going
to
work
with
the
fun
keyless
flow,
so
no
keys
at
all.
This
is
the
open
id
connect
prompt
that
I
talked
about.
So
this
pops
up,
I'm
going
to
log
in
with
google
and
cool.
That's
it
we're
done.
If
you
look
here
what
happened
in
the
terminal,
so
generating
ephemeral,
keys,
retrieving
sign
certificate.
Your
browser
will
now
open
too.
So
this
generates
the
same
type
of
keys
we
did
before,
but
it
does
it
all
in
memory,
so
those
keys
never
touch
disk.
D
D
We
take
that
key
put
it
in
a
certificate
request:
send
it
up
to
fulcio,
which
does
this
challenge
to
make
sure
that
we
actually
own
the
correct
email
address.
It
gives
us
the
certificate.
We
sign
the
image
with
it
and
then
all
that
stuff
gets
thrown
away
and
put
into
the
transparency
log.
That's
what
the
section
here
is.
D
So
I'm
going
to
verify
the
experimental
turn
on
no
keys
and
go
through
jq
for
good
formatting
awesome.
So
a
lot
more
info
this
time
and
that's
because
of
the
whole
certificate
setup
so
I'll
break
this
down.
This
is
the
same
stuff
as
before,
sign
the
image
here's
the
digest,
but
now
we
have
a
bunch
of
other
information
in
here
regarding
the
transparency
log
and
the
certificate
and
that
kind
of
information
this
tells
us
the
entry
in
the
log
which
we
can
use
to
look
stuff
up
later.
If
we
want
to.
D
This
also
tells
us
that
this
what
email
address
I
verified
this
against
right.
So
this
is
my
personal
gmail
account,
and
this
is
what
it
was
verified
against
right,
because
google
actually
did
the
vouching
and
verification.
Here.
Google
said
that
at
that
time
I
controlled
the
gmail
account,
so
this
is
all
thrown
here
into
the
signed.
D
D
D
You
have
to
kind
of
build
that
stuff
up
on
your
own,
but
at
least
you
can
prove
that
that
person
signed
it
and
nobody
else
tampered
with
it
along
the
way.
If
that
makes
any
sense,
let's
look
at
the
transparency
log
now
for
this.
So
there's
a
separate
cli
cosine
does
all
this
automatically
under
the
covers,
but
if
you
want
to
play
with
the
transparency
log
directly,
your
separate
cli
called
recourse
cli
for
the
transparency
log.
So
I'll
do
log
info
here
you
can
see
yep.
D
This
is
the
size
of
the
tree
at
this
point
getting
close
to
a
million.
This
is
the
hash.
Every
time
you
run
this
command.
If
the
number
goes
up,
we
actually
do
a
verification
here
to
make
sure
the
tree
hasn't
been
tampered
with.
So
we
can
see
the
last
time
I
ran
this.
Actually
I
ran
the
log
into
it.
Eight,
six,
five
one
six
now
I
just
ran
it
again
at
906
961
and
we
did
a
little
verification
to
prove
that
nothing
had
been
tampered
with
in
between
those
and
the
logs
just
append.
D
D
I
was
doing
some
development
this
morning
see
if
I
can
quickly
fix
it,
otherwise,
we'll
move
on
yeah,
so
this
will
pull
down
the
exact
entry
that
I
uploaded,
which
has
the
digest.
It
has
the
key.
It
has
a
certificate
and
all
that
information,
if
I
can
fix
my
cli
quickly
yeah,
this
is
kind
of
what
cosine
does
under
the
covers
for
you.
D
Format
equals
json
yeah
there
we
go
awesome.
So
this
is
everything
that's
stored
in
the
transparency
log.
For
this
entry
we
can
see
the
digest
of
the
thing
that
we
signed.
We
could
see
the
signature
itself
and
we
could
see
the
public
key
that
was
generated.
So
if
we
take
this
part,
so
it's
body,
hashed
signature.
D
Maybe
that
cool,
so
this
actually
displays
the
full
certificate.
So
we
can
see
what
that
looks
like
that
was
issued
by
suit
store.
So
here's
the
ec
dsa
p256
stuff
for
the
algorithm
itself,
we've
got
the
issuer,
sync
store.
The
you
can
see
that
this
is
for
code
signing.
D
If
you
compare
this
to
a
certificate
from
let's
encrypt,
that
would
say
something
like
forget
the
tls,
whatever
the
key
usages
for
that
is,
and
then
we
should
see
yeah
here
it
is
so
this
is
the
subject
if
you
get
one
for
a
web
browser
or
a
domain,
or
something
like
that,
the
subject
would
be
for
the
domain,
but
this
because
I
should
get
us
down
to
my
email
address.
We
use
the
email
field
in
here.
D
Then
it
is
the
signature
on
the
certificate
itself
that
we
verify
against
when
we
want
to
check
stuff.
So
this
is
what
the
certificates
for
the
stuff
look
like
these
get
stored
right
in
the
signature
in
the
container
image,
as
well
as
in
the
transparency
log.
So
the
cool
property
of
the
transparency
log
again
is
that
you
can
audit
that
log.
You
can
go
through
each
entry,
one
by
one
or
set
up
a
little
system
to
do
it
for
you
and
look
for
things
issued
with
your
email
address.
So
just
like
most
companies
do.
D
If
they're
using
certificates,
you
can
run
a
little
bot
to
check
to
make
sure
that
nobody's
issued
a
certificate
for
your
domain
that
you
don't
understand,
so
your
t.s.h
is
one
little
site
for
that,
so
you
can
type
in
something
like
google.com
and
then
see
all
of
the
certificates
in
the
transparency
log
issued
for
google.
You
could
do
a
similar
thing
with
the
record
transparency
log
for
your
email
address,
there's
a
little
command
to
search.
It
it'll
tell
you
all
of
those.
D
So
if
you
see
something
you
don't
expect,
that
means
somebody
probably
compromised
your
credentials
and
you
can
remediate
or
take
action
from
that.
D
Yeah,
so
there's
a
bunch
of
different
modes
in
this
you
can
search
stuff.
You
can
get
time
stamps
signed.
You
can
create
other
entries.
The
flow
I
show
just
uses
basic
signatures
and
cosine,
but
you
can
do
stuff
like
there's
a
bunch
of
other
different
signature
formats,
so
if
you're
still
using
pgp
or
something
you
can
store
that
in
record.
D
There's
new
ssh
certificates,
where
you
can
sign
things
with
your
ssh
public
keys
and
then
get
just
added
support
for
that,
so
you
can
actually
sign
git
commits
now
with
ssh
public
keys.
You
can
store
those
in
the
transparency
log
pretty
much
any
signature
format
can
get
uploaded
and
stored
in
here.
D
B
I
have
a
question
about
current
adoption.
Like
you
mentioned,
like
you,
have
almost
1
million
entries
like
900
thousand,
something
like
I
also
see
lots
of
you
know.
Tweets
on
twitter,
like
veronica,
is
doing
this.
The
other
point
doing
that
like
how?
How
is
the
adoption
going
like?
Will
we
get
something
like
this
and
clip
like
six
store
for
the
masses?
Kind
of
thing
like.
D
I
hope
so
yeah
a
lot
of
it
is
about
automation
and
tooling,
and
so
it's
something
that
we're
pretty
excited
about.
Actually
there's
a
blog
post
on
my
company
website,
I'll
pull
up
just
yesterday.
Just
to
make
this
even
easier
something
one
of
my
colleagues
wrote
to
help
a
lot
with
adoption
is
I
showed
the
kind
of
interactive
person
flow
where
it
pops
open
your
browser
to
verify.
D
D
I
guess
this
group
and
the
cdf
in
general,
but
you
can
do
openid
connect
with
service
accounts
or
machines,
and
one
of
the
really
exciting
recent
changes
is
that
we
work
with
github
to
github
actions
to
support
issuing
openid
connect
tokens
to
the
workload
running
inside
of
the
action,
and
so,
if
you
run
cosine
sign
from
inside
of
github
actions,
now
this
little
demo
shows
you
how
all
you
do
is
cosine
sine
no
keys
or
anything
like
that
inside
of
github,
then
it
works.
D
So
if
we
scroll
down,
you
can
see
what
that
looks
like
and
it's
actually
pretty
cool,
because,
instead
of
just
an
email
address
with
github
puts
in
those
tokens,
it's
the
full
repository
action
that
ran
itself.
So
here's
the
file
to
the
action
in
the
repository
and
then
what
ref
it
ran
at.
D
It
even
includes
some
extra
information
that
I
think
we
took
out
of
here,
but
it's
showing
these
dots
of
the
exact
build
number
that
ran
the
invocation,
the
commit
digest,
who
triggered
it
all
that
stuff
gets
thrown
into
those
tokens,
and
so
just
by
turning
on
one
flag,
no
key
management
or
anything
like
that.
You
can
sign
everything
coming
out
of
github
actions.
D
Techton
cd
supports
the
same
thing
depending
on
which
cloud
provider
you're
running
it
under
google
has
something
called
workload:
identity,
amazon,
their
kubernetes
system
has
something
similar
where
your
workload's
running
on
their
virtual
machine,
they're
inside
of
containers,
can
get
these
tokens
that
are
scoped
to
the
exact
instance
or
machine,
or
something
like
that.
That's
running
I
mean
you
can
get
certificates
bound
to
those
then,
and
so
yeah.
D
The
interactive
stuff
doing
it
from
your
personal
machine
is
is
good,
but
you
know
the
adoption
is
limited
to
how
many
times
you
built
and
signed
something
yourself,
that's
kind
of
generally
an
anti-pattern
anyway.
So
the
existence
of
these
new
automated
systems
is
what's
really
driving
the
more
people.
D
Turning
this
on,
if
you're
familiar
with
the
go
releaser
project,
it's
an
awesome
tool
set
for
building
and
releasing
go
projects
from
github
gitlab,
whichever
source
code
provider
you're
on,
but
this
will
turn
and
go
project
into
images
and
debian
packages
and
rpms
and
all
the
different
ways
you
might
want
to
distribute
something
from
code
automatically,
and
this
supports
now
that
same
kind
of
stuff.
So
if
you
give
it
a
token,
it
can
sign
everything
for
you
using
all
of
the
safe
store,
tooling,
so
yeah
getting
everything
automated
and
making
it.
B
D
Awesome
any
questions
or
anything
here,
I
think
we're
basically
out
of
time.
B
B
B
So
with
that,
I
thank
all
of
you
for
joining
today,
so
our
next
meeting
and
possibly
the
last
meeting
for
this
year,
will
be
in
16th
of
december,
so
until
we
see
each
other,
I
hope
you
a
very
nice
rest
of
your
day
and
nice
weekend
since
it's
almost
weekend
yeah
thursday
thursday.
So
talk
to
you
next
time.
Thank
you
for
joining
thanks,
bye,
bye.