►
From YouTube: OCB: Secure your Open Source Supply Chain with Sigstore
Description
Bob Callaway and Ivan Font of Red Hat will introduce a new project called 'sigstore' that was recently launched under the Linux Foundation. Sigstore aims to empower software developers to easily and securely sign software artifacts such as release files, container images, binaries, bill of material manifests and more. Signing materials are then stored into a tamper resistant public log. They'll show a demo of the system working on OpenShift to sign container images and integrated into a build pipeline with Tekton and Open Policy Agent.
A
Hello,
everyone
welcome
to
another
openshift
commons
briefing.
Today
we're
going
to
talk
more
security,
you've
been
seeing
a
lot
of
security
briefings
lately.
That's
because
well
I
mean
we
all
really
care
about
security.
You've
heard
about
the
recent
acquisition,
and
hopefully
you
watched
the
stack
rocks
briefing.
A
We've
had
briefings
on
dev
cycops
and
this
one's
great,
because
there's
this
new
project
called
project
sig
store
that
our
guest
bob
calloway
and
ivan
font
have
been
working
on
they'll.
Tell
you
more
about
it
and
they're
both
here
from
the
cto
office
at
red
hat
in
the
emerging
technologies
division,
and
this
project
was
just
recently
donated
to
the
linux
foundation
so
giving
that
intro
bob.
Would
you
like
to
introduce
yourself
as
well
and
kick
it
off.
B
Helps
if
you're
new
right
all
right,
so
hey
everybody
bob
callaway
good
morning,
good
afternoon,
good
evening,
wherever
you
are
so
as
perina
said,
I'm
part
of
the
cto
office
here
at
red
hat
and
one
of
the
maintainers
on
the
collection
of
projects
that
we're
calling
stick
store
today.
What
we're
hoping
to
do
is
just
give
you
an
overview
of
the
problem
space
that
we're
we're
working
in
some
of
the
challenges
exist
that
exist
today.
B
So
with
that
we'll
jump
right
in
so,
as
you
guys
have
heard
from
the
last
few
briefings,
there's
there's
a
lot
of
challenges
in
in
securing
the
overall
supply
chain
for
software.
There
was
a
report
that
came
out
that
said
in
the
last
you
know
two
years,
there's
been
a
400,
some
percent
increase
and
and
part
of
the
reason.
Why
is
that?
The
supply
chains
are
fundamentally
complicated,
right
you've
got
developers
workstations
to
various
ci
systems.
You've
got
public
code,
repos
you've
got
you
know
about
stories.
B
Behind
the
firewall
container
registries,
I
mean
there's
a
lot
of
moving
parts
that
it
ultimately
takes
to
to
develop
and
deploy
and
iterate
on
cloud
native
software.
So
there's
no
shortage
of
of
issues
that
are
that
have
come
up
of
late.
Certainly,
the
solarwinds
attack
is
one
that
I
think,
is
a
lot
on
a
lot
of
people's
minds
right
now,
but
at
the
end
of
the
day,
right,
maintaining
keys,
making
sure
that
you've
got
account
security
set
up.
B
B
You
know
often
times
you
think
about
artifacts,
and
even
if
you
go
to
the
solarwinds
kind
of
post-mortem
and
look
at
what
happened,
code,
signing
is
often
kind
of
looked
to
as
one
way
that
you
can
hopefully
verify
the
integrity
of
what
is
being
distributed.
But
when
we
look
in
the
open
source
community
today
across
many
of
the
popular
projects,
some
of
them
are
being
signed.
B
You
can
see
here
in
the
table
they'll
they
have
some
of
the
most
popular
ones
out
of
the,
but
you
know
there
are
different
ways
in
terms
of
how
we
publish
key
material.
How
are
the
trust
models
that
are
applied,
whether
you
need
to
start
and
verify
from
default
or
whether
you
need
to
trust
on
first
use?
You
know
these
there's
a
collection
of
some
of
the
other
package
managers
that
exist
today.
B
You
know
part
of
the
reason
why
signing
is
so
important
is:
not
only
does
it
provide
integrity,
but
it
also
provides
some
other
features
non-repudiation
to
make
sure
that
hey
somebody
can't
claim
that
they
didn't
create
something
that
you
know.
The
presence
of
a
signature
implies
the
possession
of
the
public
private
key.
B
You
know
the
user
experience
leaves
a
lot
to
be
desired,
not
to
mention
once
you
figure
out
how
to
use
that
you've
then
got
to
figure
out.
What
do
you
do
with
this
key
pair
right?
I've
got
to
clearly
keep
it
secure
to
make
sure
that
nobody
gets.
You
know
hold
of
the
private
key
and
can
mask
or
investigate
as
me,
but
you
know,
do
I
buy
an
hsm?
Do
I
use
a
ub
key?
What
if
I
want
to
do
this
in
the
cloud?
B
B
I've
got
multiple
maintainers
who's,
actually
able
to
speak
on
behalf
of
the
project
itself,
who's
able
to
publish
an
artifact
and
how
do
how
do
consumers
of
that
software
ultimately
go
through
the
steps
to
verify?
Not
only
is
it
signed,
but
is
it
signed
by
somebody
that
we
should
trust
and
maintainers
come
maintainers
go?
How
do
I
maintain
that
list
of
of
the
project?
Maintainers
is
also
another
challenge
as
well,
and
so
here
you
get
an
example
on
the
right
side
of
of
the
node.js
project.
B
Now
they
publish
this
on
on
github
and
not
meaning
to
throw
any
shade
at
the
node
team,
because
this
is
a
as
I
mentioned
before.
This
is
a
hard
thing
to
to
fundamentally
manage,
but
you
know
if
a
maintainer
leaves
how
do
you
actually
ensure
that
you
know
that
key
pair
is
not
used
after
the
fact
to
go
sign
a
malicious
release
of
that
project?
B
B
B
We
donated
the
the
problem
or
the
project
set
to
the
linux
foundation
as
well,
so
we'll
we've
actually
also
launched
a
what
we're
calling
a
public
good
service
basically
is
a
hosted
instance
of
the
set
of
projects
that
developers
can
use,
but
if
you
want
to
take
it
and
use
it
yourself,
you
can
certainly
do
that
firewall
as
well.
So
let's
jump
in
and
figure
out
a
little
bit
more
about
what
what's
in
sig
store
itself.
B
So,
as
I
just
mentioned,
you
know,
six
doors
is
collection
of
modular
projects
that
can
be
used
independently
or
together
as
a
whole,
to
address
some
of
these
problems.
We
have
implemented
this
by
default
on
top
of
kube,
with
with
certainly
everything
done
in
containers,
and
I
guess
the
best
mental
model
that
I
can
give
you
if
you're
familiar
with
the
let's
encrypt
project,
that's
a
public
good
service.
B
That's
that's
trying
to
make
it
easier
for
folks
to
secure
their
websites,
and
so
through
the
advent
of
the
acme
protocol,
as
well
as
hosting
up
infrastructure.
That's
paid
for
by
a
you
know,
an
open
consortium
of
entities
that
are
all
incentivized
to
see
a
more
secure
internet
and
that's
certainly
good
for
all
of
us.
You
know
we
we
see
ourselves
in
in
that
same
light
as
well.
B
B
B
So
I'm
going
to
walk
you
through
how,
at
from
a
developer's
point
of
view,
how
you
would
take
advantage
of
sig
store
and
then
we'll
jump
into
a
demo,
because
obviously
sitting
and
staring
at
charts
isn't
as
fun
as
seeing
it
work
in
so
imagine,
you're
a
developer
and
you
you've
created
some
awesome
piece
of
software
that
you
want
to
go
and
share
with
the
world.
So
first
thing
I've
got
to
do.
Is
I've
got
to
generate
a
key
pair
if
you
can't
sign
without
using
public
key
cryptography?
B
So
I
need
a
key
pair
and
we
joke.
We
jokingly
call
six
store,
keyless
signing
in
the
same
vein.
That
serverless
is
doesn't
use
a
server.
Obviously
it
does
behind
the
scenes.
It's
just
obfuscated.
You
know
we
call
this
keyless
signing
in
the
same
sense.
Yes,
we
use
a
key,
but
the
lifespan
of
the
key
really
can
be
a
matter
of
milliseconds
in
this
in
this
system.
B
B
The
developer
owned
this
this
set
of
keys.
I
will
note
as
well
that
again
back
to
the
modular
point,
if
you
have
your
own
key
pair
and
you've
gone
down,
that
process
to
store
it
securely
in
an
hsm
and
not
you
know,
in
a
vault
with
arm
guards,
that's
totally
fine
too.
Nothing
here
precludes
you
from
bringing
your.
B
So
anyways
developing
software
I've
got
a
key
pair.
The
first
thing
that
I'll
do
is,
I
will
go
and
authenticate
using
the
openid
connect
protocol
for
those
of
you
who
aren't
familiar
with
this
if
you've
gone
to
any
website
of
late-
and
you
see
the
login
with
google
or
log
in
with
apple
or
log,
in
with
facebook
buttons
on
a
website
they're,
actually
using
a
protocol
called
open
id
connect
behind
the
scenes.
B
This
is
built
on
top
of
oauth
and
essentially
just
uses
an
external
identity
provider
to
authenticate
and
make
an
attestation
around
who
you
fundamentally
are
at
the
end
of
the
day.
So
in
our
system
you
would
reach
out
to
the
full
co
service.
You
authenticate
using
open
id
connect
and
then
we
would
get
a
id
token.
That's
what's
passed
underneath
the
covers.
B
Signing
certificate
and
publish
that
in
as
kind
of
a
basically
your
new
public
key,
so
folks
can
use
that
certificate
to
verify
a
signature
just
as
they
could
if
they
only
had
the
artifact
so
once
that
certificate
is
published
into
the
log
and
returned
back
to
the
developer.
Now
I've
got
this
key
pair.
I've
got
a
code
signing
certificate.
What
should
I
do
now?
Well
next
thing
to
do
is
actually
just
sign
the
software
itself.
You
can
use
open
ssl.
B
You
can
use
our
client
tooling,
that
we
we
provide,
but
at
the
end
of
the
day
we
want
that
artifact
to
be
signed.
Now,
the
next
thing,
once
we
have
a
signed
artifact
and
we've
got
the
the
signature.
We
need
to
put
that
into
a
transparency
log
and
that's
where
the
recore
project
comes
in,
so
we'll
show
an
example
of
what
goes
in
the
log,
but
at
the
end
of
the
day,
it's
the
public
key,
it's
the
signature
itself,
and
then
we
we
we
extract
the
hash
value
from
the
from
the
signature.
B
So,
in
the
immutable
log
we
have
a
record
of
what
artifact
was
signed.
It
was
signed
with
what
public
key
pair
and
we
store
all
that
information
on
the
log.
So
if
people
want
to
go
back
and
verify
that
themselves,
they
can
do
that
and
then
finally,
we'll
get
into
this.
When
we
talk
about
the
integration
with
opa
that
we'll
demo,
you
have
to
have
some
way
of
of
kind
of
rounding
out
this
trust
loop
to
say:
hey.
B
These
are
the
actual
software
releases
that
exist
and
are
trusted,
and
these
are
the
maintainers
in
the
software
project
that
I
trust,
there's
a
couple
of
different
ways
that
that
we've
seen
folks
address
this
problem.
Some
people
are
comfortable
putting
a
maintainer's
list
on
on
github.
Some
people
put
a
maintainer's
list
on
a
website.
Obviously
those
have
some
pros
and
cons,
but
we
also
see
transparency
logs,
potentially
playing
a
role
here
as
well.
So
the
other
day
you
want
to
be
able
to
publish
what
are
the
known,
good
releases
and
who's.
B
Who
are
the
signers
that
I
fundamentally
trust
put
that
into
a
system
as
well.
So
now
I've
signed
it.
I
published
it
to
all
the
transparency
logs.
I
can
throw
away
the
keys.
I
don't
need
them
anymore,
because
they're
they're
again
stored
in
this
immutable
ledger
and
I
as
a
developer.
I
can
now
monitor
these
transparency
logs
and
look
for
hey.
Has
anybody
else
published
anything
with
that
private
key?
Maybe
I
thought
I
threw
it
away,
maybe
somebody
you
know
I
used
a
a
system
and
the
memory
was
compromised.
B
You
know
you
want
to
make
sure
that
you
monitor
your
identity
and
say
who
else
might
have
had
my
my
password
and
logged
in
and
generated
an
identity
token.
So
the
concept
of
monitoring
is
also
really
critical
in
this
model
to
make
sure
that
hey,
if,
if
you
see
a
certificate
or
a
signature
being
generated
with
your
your
identity,
then
obviously
that's
a
notion
of
hey
wait
a
minute,
maybe
my
keys
weren't
as
secure
as
perhaps
I
thought
and
then
once
I've
monitored
it.
B
So
with
all
that,
we
will
jump
to
a
demo.
So
I
will
do
this
live
here.
Hopefully
you
guys
can
see
my
screen
so
we'll
walk
through
the
basically
the
exact
same
thing
that
I
just
showed
you
in
slides
through
through
the
command
line.
So
the
first
thing
we'll
do
is
we'll
create
a
software
artifact
that
we
want
to
distribute
in
this
case,
I'm
just
going
to
generate
some
random,
a
small,
little
random
file
and
put
that
into
a
filename
artifact
next
thing
again.
B
B
All
of
these
commands
will
publish
as
well
on
on
our
website
on
a
blog
post.
So
I'll
go
live
later.
I
actually
want
to
try
this
out,
we'll
verify
that
signature.
Everything
comes
back
and
says
it
verified
okay.
So
the
next
thing
we'll
do
is
we'll
reach
out
to
an
open
id
connect
identity
provider
and
get
a
that
id
token
that
I
mentioned
so
we're
using
here
a
cli
command
that
will
help
to
launch
a
browser
to
drive
this
authentication
workflow.
B
So
in
this
case
you
know,
sig
store
is
not
managing
a
list
of
username
and
passwords.
We
never
get
your
username
and
passwords
we're
relying
on
a
delegated
token
to
be
generated
from
one
of
these
two
providers
today
we're
gonna,
probably
add
microsoft
and
many
more
to
come,
but
for
just
the
sake
of
this
demo,
we'll
log
in
with
google.
B
B
B
So
assuming
that
that
worked,
we're
gonna
now
throw
away
the
keys,
because
we
don't
need
them
anymore.
We're
now
going
to
look
at
the
signed
certificate
that
came
back
from
ulco
a
couple
things
to
call
out
again
if
you're
not
familiar
with
looking
at
x,
509
certificates.
This
may
seem
like
greek
to
you,
but
at
the
end
of
the
day
again,
we
want
a
linkage
between
identity
and
the
possession
of
the
key
pair,
and
you
can
see
inside
the
certificate.
B
B
Signatures
got
our
root
ca
in
the
list
as
well,
just
in
case
you're,
you're
interested.
You
want
to
import
that
all
into
your
trust
store.
So
now
I've
got
a
signed
artifact.
I
no
longer
have
any
key
pairs.
I've
got
the
code
signing
cert
that
I
can
use
to
prove
this.
The
next
step
is
to
actually
go
and
submit
this
to
the
recore
transparency.
B
Again,
you
could
do
this
with
curl,
but
that
that
submit
is
pretty
nasty,
so
we'll
just
cli
instead,
so
what
we've
done
is
we've
submitted
all
that
information
up
to
recore
you'll
note
here
we
did
actually
send
the
entire
file
up
to
the
system.
That
file
is
not
stored
in
the
transparency
log
itself,
only
the
sha
256
digest
value
is
actually
stored
in
the
log.
So
again,
if
you
were
to
sign
a
piece
of
software,
you
don't
necessarily
want
that
to
be
a
distribution
vehicle
for
it.
B
B
What
we'll
do
is
we'll
use
another
sub
command
of
this
called
verify.
Where
again
we
pass
it
the
same
exact
credentials
and
we're
going
to
be
able
to
see.
Not
only
is
that
entry
in
the
log,
but
we're
going
to
see
a
ton
of
sha
hash
values
and
I'll
go
into
a
little
bit
around
how
this
is
all
built
together,
a
little
bit
later
in
the
talk
but
long
story
short.
D
C
C
Oh,
let
me
thanks
for
that
yeah.
It
would
help
if
I
shared.
Wouldn't
it
thanks
all
right
so
yeah
just
you
should
be
seeing
the
terminal
here
and
we'll
go
ahead
and
open
up
a
web
browser.
As
I
mentioned,
we'll
open
up
a
tab
here
and
you
can
take
a
look
that
we
have
a
demo
app
running
here.
It's
just
a
simple
hello
world
app
and
just
show
you
quickly
what
the
contents
of
this
repository
is.
We
have
this
repo
that's
hosted
on
github,
just
a
simple
go
web
app
that
displays
some.
C
So
let's
say
you
come
in
on
a
friday
and
you
have
some
work
to
do.
You
have
to
make
a
change
to
your
app,
so
we
go
ahead
and
first
we
have
to
build
the
base
image
for
the
application
that
we're
using
here.
This
is
the
hello
world
application,
so
we
can
do
a
podman
build
using.
We
have
a
base
doctor
file
here
we
have
a
docker
file
for
the
base
image
and
we
can
see
we
go
ahead
and
build
that
we
go
ahead
and
push
this
built
container
image
to
the
container
registry.
C
C
C
Several
tasks
that
are
run
as
part
of
this
pipeline
we'll
go
ahead
and
fetch
the
repo.
This
is
the
git
repo,
with
the
commit
that
I
just
pushed
then
we'll
build
the
image.
There's
a
few
steps
here.
We
build
the
image
and
push
the
image
using
buildup
to
our
integrated
container
registry.
That's
running
inside
of
openshift
here.
C
And
then
we
extract
the
email
from
the
actual
certificate
and
that
will
refer
to
the
identity
that
was
used
to
find
that
image
and
then
we'll
pass
that
to
an
opa
policy
that
will
apply
and
verify
that
that
image
was
signed
by
an
entity.
That's
in
the
maintainers
list
that
you
saw
earlier
and
then
we'll
just
go
through
a
simple.
You
know
apply
the
manifest
and
update
the
deployment
so
that
we
can
get
the
changes
deployed
into
our
cluster
here
and
see
them
go
live
so
here
we
can
see
we're
building
this.
C
C
Then
we
go
verify
the
base
image,
but
we
didn't
actually
sign
that
image.
The
the
base
image
wasn't
signed,
and
so
we
fail
here
because
we're
actually
trying
to
retrieve
the
signature
for
that
image
and
it
doesn't
exist.
So
that's
what
that
error
is
saying,
and
it's
basically
saying
that
we
sell
it
to
verify.
So
we
actually
failed
the
pipeline
because
the
image
isn't
even
signed.
So,
let's
transition
back
to
the
terminal
and
let's
actually
sign
that
image.
C
So
we'll
go
ahead
and
log
in
with
google,
and
here
we'll
just
use
my
iphone
redhat.com,
we
authenticate
successfully
there
and
then
what
it'll
do
is
it'll
actually
use
the
gener.
The
femoral
key
pair
it'll
it'll
create
the
signature
and
then
it
will.
It
will
use
the
certificate
that
it
got
back
from
fusio
and
be
able
to
upload
a
new
object
to
the
container
registry
that
contains
the
signature,
the
certificate
and
chain,
along
with
the
reference
to
the
image,
the
sha
of
the
image
that
was
signed.
C
So
cosine
is
a
project
within
the
six
store
umbrella
in
the
github
org,
and
that's
the
cosine
command
that
you
saw
there
to
sign
the
container
image
and
its
architecture.
As
I
spoke
a
little
bit
too,
is
basically
outlaid
here,
and
you
can
see
that
cosine
will
generate
that
ephemeral
key
pair.
You
can
also
use
a
key
management
system
or
any
existing
key
pair.
C
If
you
have
that,
so
we
try
to
accommodate
all
the
different
use
cases
and
then
it
requests
a
code
signing
certificate
from
pusio,
which
you
saw
then
calls
out
to
an
identity
provider
like
github
or
google
in
this
case,
and
it
will
basically
authenticate
that
the
that
the
that
you're,
the
owner
of
that
private
key
associated
with
that
email
account
so
once
we
get
that
back
coast
time
will
then
download
the
container
manifest
from
the
registry
this
contains.
This
is
a
reference
to
the
image
that
you
want
to
sign.
C
It
generates
the
signature
using
the
the
key,
that
is,
the
thermal
keys
that
it
generated
attaches
the
certificate
and
chain
and
uploads
the
signature
and
the
public
key
and
certificate
chain
to
the
container
registry
as
a
new
oci
object
and
then,
after
it
does
all
that
it
creates
an
entry
in
recore
using
the
similar
sort
of
contents
and
uploads
and
creates
an
entry
in
that
transparency.
Log
for
the
signed
container,
let's
go
back
and
take
a
look
to
see
how
our
pipeline
is
doing
here
looks
like
the.
C
C
So
we
verify
the
image
and
then
cosine
outputs
here
that
the
claims
were
valid
validated,
so
you
can
actually
add
annotations
as
well.
If
you
want
to
be
the
signature
that
gets
uploaded,
you
can
actually
add
any
sort
of
additional
annotations
and
it
also
verifies
that
the
entry
was
existed,
existed
in
the
transparency
log
along
with
those
claims,
so
the
signature
was
integrated
into
recore.
C
Any
certificates
were
also
verified
with
the
fusion
route
that
we
obtained,
and
then
you
can
see
that
the
certificate
has
the
common
name
here:
ipod
redhat.com
and
then
you
can
see
the
red
hat,
simple,
signing
spec
that
gets
dumped
as
well.
That's
the
payload
for
the
the
object
that
gets
uploaded
to
the
container
registry.
C
So
once
we
get
that
common
name,
we
apply
our
opa
maintainers
policy.
That
says
ifont
at
redhat.com
is
an
authorized
maintainer
for
this
image,
and
so
we
go
ahead
and
pass
that
past
the
open
maintenance
policy
and
then
we
apply
the
manifest
and
update
the
deployment.
So
let's
go
take
a
look
at
the
deployment
and
if
we
refresh,
we
see
the
updated
hello
ocp
world
change
that
we
made
a
little
bit
earlier.
C
Okay
great,
so
we
can
show
that
we
can
find
the
container
image
and
we
won't
go
through
the
ci
cd
flow
successfully
until
that
image
is
signed.
Well,
what
happens
in
a
if
credentials
are
stolen?
So
let's
say
you
leave
for
the
weekend.
You
know,
and
over
the
weekend
somebody
obtains
the
credentials
and
steals
the
credentials
to
the
container
registry
that
you
use
to
upload
the
face
image,
as
well
as
the
signature
that
you
also
use
to
find
that
base
image.
C
C
C
Let's
say
this
is
a
very
sophisticated
black
hacker,
and
this
user
also
knows
that
hey,
we
are
using
recore
and
the
sixth
floor
architecture
to
be
able
to
create
a
transparent
trusted
source
for
anything
that's
signed,
so
this
user
knows
that
we
have
to
create
an
entry
in
there.
Otherwise
we
might,
there
might
be
some
red
flags
that
are
raised.
So
let's
go
ahead.
This
user
knows
that
we
need
to
go
ahead
and
find
the
the
actual
base
image.
This
is
a
malicious
image
and
they're
signing
it.
C
You
know
the
transparency
log
is
there
for
a
good
or
malicious
intent,
and
the
idea
is
that
it
needs
to
be
monitored,
and
so
here
the
user
would
be
able
to
log
in
with
whatever
identity
provider
they
want
to
use.
In
this
case,
they'll
try
and
use
google
and
they
don't
have
access
to
my
iphone
at
redhat.com.
C
Obviously
here
I
have
both
accounts
integrated,
I'm
representing
both
I'm
putting
on
both
hats,
but
this
person
has
their
own
email
that
they
can
only
authenticate
with,
and
it's
just
evil
person.
You
know
hacker
lols
gmail.com,
so
that
is
authenticated
there
and
we
can
see
here
that
cosine
generated
ephemeral
key
pair
for
that
signature,
grabbed
the
certificate
from
pulcio,
which
then
authenticated
with
google
again
and
then
uploaded
the
signature,
the
payload
and
the
certificate
chain
for
that
container
image
and
created
a
transparency
log
entry
through
recore.
C
So
all
right,
so
we
now
have
pushed
a
malicious
image
out
there.
So
now
it's
open
to
be
able
to
download
and
be
used
by
others.
So
let's
make
another
change
you
come
in
on
monday
and
you
do
not
know
what
happened
over
the
weekend.
So
let's
go
ahead
and
come
in
here
make
another
change:
hello,
again:
ocb
world
you
have
to
come
in
and
monday
morning
make
this
change.
Let's
commit
another
change
here
and
let's
push
that.
C
C
C
C
We
have
a
record
manifest
schema.
This
is
kind
of
the
basic
version
version
here.
The
spec
basically
just
contains
the
signature
information,
so
you
we
can
do
like
gpg,
x509
mini
sign.
We
support
different
signatures
and
you
can
have
the
url
here
to
the
signature
itself,
along
with
the
public
key
that
was
used
and
then
the
data
itself.
Again,
it's
just
a
link
to
the
data.
It's
not
the
actual
data
itself,
along
with
a
hash
of
that
data
to
verify
the
integrity
of
the
contents.
C
So
recore
has
been
built
with
extensibility
in
mind,
so
there's
a
plugable
pki
interface
that
supports
multiple
different
formats,
x509
gpg
so
on
and
so
forth,
and
we
have
plans
to
add
further
signing
systems
and
then
it
also
has
a
plugable
supply
chain
format.
So
we
can
support
like
oci
or
notary
v2
signatures
in
the
future
whenever
that
becomes
ready,
and
it's
also
designed
to
work
with
systems
like
the
update
framework
and
in
toto
and
as
well
as
like
rpm
signature,
transparency,
d-bomb
and
f-bomb
stuff
as
well.
C
D
C
Actually
signed
the
image,
so
everything
was
validated
everything
existed
in
the
transparency
log.
Everything
checked
out,
okay
here,
but
you
can
see
the
certificate
was
actually
contained.
The
contents
for
the
common
name
of
the
user's
email
address
here:
hacker
lowells
unbeknownst
to
the
user,
trying
to
use
this
image
unless
we
have
a
actual
oppa
policy
that
we
can
enforce
the
list
of
maintainers
here,
and
we
can
see
that
it
fails
the
oppa
policy,
because
the
certificate
with
this
email
is
not.
B
Just
in
the
interest
of
time,
because
I
want
to
leave
a
few
minutes
for
q,
a
we'll
just
jump
to
the
kind
of
where
we're
where
we're
looking
at
kind
of
the
road
map
for
some
of
these
projects-
and
you
can
view
all
of
this
at
our
community
repo
as
well.
So
if
you
have
thoughts
or
ideas
submit
those,
certainly
as
issues
you
know
in
terms
of
how?
How
can
we
make
the.
B
B
B
We
could
look
at
integrating
with
schedulers
to
ensure
that
we
only
run
trusted
content
on
particular
nodes,
or
we
could
look
at
even
going
down
to
the
lower
levels
right,
integrating
in
with
container
d
pod
man
and
whatnot
to
actually
catch
this
at
the
at
the
runtime
layer.
So
so
we
would
only
launch
the
the
image
if
we
were
able
to
verify
the
signature.
So
we've
we've
started
looking
into
all
of
these
areas
and
we
think
we'll
we'll
be
able
to
offer
a
variety
of
different
approaches
going
forward.
B
You
know,
I
think
the
other
thing
too
is.
While
we
showed
a
pretty
basic
example
with
the
maintainers
list,
opa,
you
know
and
other
policy
engines
you
know-
certainly
have
you
know
a
larger
functional
set
that
we
can
maybe
take
advantage
of.
So
we'll
look
at
improving
and
formalizing
those
extension
points.
B
And
finally,
you
know
this
is
solving
this
problem
more
broadly,
if
we
don't
get
that
list
of
community
projects
that
I
open
the
presentation
with
to
start
signing
their
content
and
getting
people
used
to
verifying
this
content,
then
all
of
this
is
just
you
know,
a
fun
technical
exercise.
So
we
are
also
working
with
many
of
the
most
popular
open
source
community
projects
out
there,
whether
it
be
the
package
managers
for
ruby
or
pi
pi,
whether
it
be
popular
distributions
like
fedora.
B
You
know
to
make
sure
that
we
are
signing
the
content
that
they
are
distributing
and
that
we
are
making
it
very
easy
and
simple
to
use
it
with
their
build
systems.
So
you
know,
there's
there's
a
lot
of
work
to
do
to
kind
of
close
the
loop
on
both
the
policy
side,
as
well
as
getting
people
to
adopt
this,
but
we're
seeing
a
ton
of
interest
in
the
community.
B
So,
as
we
kind
of
alluded
to,
we
are
in
a
point
where
we
launched
a
couple
weeks
ago,
so
we're
still
in
a
soft
launch
phase,
if
you
may
so,
we've
made
kind
of
a
public
statement
that
while
we
are
running
these
services
live,
they
are
not
to
be
considered
production
grade.
We
have
no
sla
around
it,
but
they
are
available
for
for
folks
to
go
play
around
with
everything
that
we
showed
today
was
a
live
demo.
So
no
none
of
that
was,
you
know,
hacked
up
behind
the
scenes.
B
B
You
can
use
the
apis
directly
as
I
showed,
but
you
know
we're
in
the
soft
launch
phase
to
try
to
work
out
some
of
the
bugs
and
make
sure
that
we've
got
some
of
the
use
cases
you
know
really
hardened
and
we
look
to
go
into
more
of
a
production
capacity
this
summer
next
slide.
Please,
and,
as
I
mentioned,
you
know
we're
if
you
use
the
analogy
of
of
let's
encrypt
part
of
the
reason
why
people
can
fundamentally
trust
less
encrypt
is
because
they're
not
owned
by
one
single
corporate
entity.
B
B
B
Next
slide,
please
so
in
summary,
click
through
the
animations,
please,
you
know
this
is
100
open
source.
You
would
expect
no
less
from
red
hat
and
google
and
others
here,
but
you
know
all
of
the
tooling
everything
that
we're
running
is
all
publicly
available.
We
are,
you
know
the
system
is
live.
We
are
actively
in
development.
Like
I
said,
we've
got
a
lot
of
great
activity
going
on
in
slack
and
on
on
mailing
lists.
B
It's
totally
free
to
use.
There's
no
cost
required
we're
going
to
support
a
number
of
of
identity
providers
so
that
you're
not
locked
into
only
using
github
or
only
using
google,
as
we
showed
today
we're
going
to
add
many
of
the
the
more
popular
ones
as
well
and
then
finally,
you
know
we
we've
got
a
you
know
a
blossoming
community
and
we
would
love
to
see
folks
that
are
watching
this
to
come,
join
or
come
play
around
with
some
of
the
technology
that
we've
made.
B
But
at
the
end
of
the
day,
open
source
is
successful
when
folks
jump
in
and
share
their
ideas
and
help
to
contribute.
So
this
is
kind
of
a
call
to
action
to
if
you,
if
you're
passionate
about
something
that
we've
talked
about
today
and
you'd
love
to
help
or
give
us
feedback,
please
you
know
jump
in
the
slack
channel,
shoot
us
an
email,
we'd
love
to
we'd
love
to
hear
from
you.
A
B
Yeah
great
question,
so
short
answer
is:
yes,
there's
nothing!
You
know
the
cosign
specific
tool
is,
is
container
specific
but
there's
nothing
to,
as
I
showed
you
generating
random
content.
There's
nothing
here.
That
says
we
can't
use
this
system
to
sign
xml
files,
json
files,
you
know
pretty
much
anything
that
you
could
use.
You
know
open
ssl
to
sign.
B
We
could
put
into
put
into
these
transparency
logs,
so
you
know
we're
we're
trying
to
go
after
one
of
the
most
popular
vehicles
for
distributing
software
today,
which
is
why
we're
working
with
folks
like
the
java
community.
You
know
the
node.js
community
etc,
as
well
as
kind
of
some
of
the
linux
distributions.
But
you
know
the
use
cases
here
are
pretty
much
all
content
agnostic.
A
A
B
Like
I
said,
I
think
you
know
give
us
a
few
more
weeks
here.
We
are
putting
the
system
through
its
paces
through
many
of
the
community
members
in
in
partnering
with
many
of
the
open
source
projects.
But
you
know,
if
you
look
at
the
transparency
log
component,
we're
actually
reusing
an
open
source
project
called
trillion
which
came
from
google.
That
runs
these
transparency
log
service
behind
certificate
transparency.
B
B
So
we
think,
by
the
end
of
the
summer,
we
will
have
a
system
that
we
can
turn
on
into
production
and
get
folks
to
start
using
meaningful
and
the
other
thing
about
production,
as
I
will
note
as
well
for
all
our
golang
programmers
out
there
whenever
you
pull
down
a
go
module
to
include
in
your
program
where
actually
certificate
transparency
is
used
behind
the
scenes
there.
So
we're
looking
at
you
know
again
we're
building
off
of
a
system.
That's
already
been
battle
tested
for
quite
a
while.
B
C
Yeah
I
mean,
I
think,
I'd
like
to
see
it
go
everywhere,
where
open
source
security
is
needed,
which
is
pretty
much
everywhere.
I
think
I
think
I
think
we
we
still
have
some
more
work
to
do.
Definitely
to
get
it
at
a
at
a
point
where
it
can
be
started,
but
to
be
adopted
more
inclusively
everywhere,
as
bob
mentioned,
I
think,
probably
a
few
more
weeks
to
get
to
get
the
instance
a
little
bit
more
battle
tested
but
yeah.
C
C
B
And
one
other
point
I
think
we
made,
but
I
think
it's
worth
maybe
making
again.
You
know
this
is
a
modular
system.
So
if
you
already
have
your
own
certificate
authority
behind
the
firewall,
we
can
integrate
with
that.
If
you
already
are
managing
your
key
pairs
today,
we
can.
We
can
certainly
integrate
and
use
that,
so
you
can
run
just
the
signature
transparency
log
if
you
want,
if
that's
all
that
matters
for
your
particular
use
case
or
you
can
replicate
the
entire
infrastructure
that
we're
running
for
the
public
good
service.
B
A
B
Oh
thanks,
I
mean
it's
like
I
said
it's.
This
is
a
chicken
in
the
egg
type
thing.
If
nobody
signs,
then
you
know
what's
the
point,
so
I'd
really
encourage
folks
to
go
not
only
play
around
with
it
and
get
familiar
with
it
themselves,
if
you're
a
developer
but
also
lobby.
You
know
your
your
favorite
projects
right
point.
Send
them
to
a
link
to
our
our
website,
send
them
a
link
to
it.
You
know
our
blog
get
them
aware
of
hey.
B
There's
innovation
happening
in
this
space
that
they
can
take
advantage
of,
and
so
part
of
the
your
role
in
a
community.
Even
if
you're,
not
a
coder,
you
can
advocate,
for
you
know
these
better
practices,
whether
it
be
software
signing
or
just
general
best
practices
with
security.
So
there's
other
ways
that
folks
can
get
involved
beyond
just
showing
up
and
running
good.
C
Absolutely
yeah
and
just
to
add
to
that
as
well.
It's
kind
of
a
network
effect
sort
of
problem
right
because
as
more
projects
start
using
it
eventually
that
grows
and
grows,
and
then
eventually
it
may
become
the
default
and
then
now,
if
you
don't
do
it,
it's
seen
as
a
security
risk
right
so
get
the
word
out.
You
know
as
more
projects
start
using
it.
We
have
the
infrastructure
there
to
meet
people
where
they're
at
as
bob
was
saying.
So,
let's
get
more
projects
in
here.
A
Well,
thank
you
and
we
will
be
posting
those
slides.
If
you
are
watching
this
on
youtube
or
on
twitch,
you
can
find
them
there,
as
well
as
the
recording
but
we'll
send
that
out
and
thank
you,
everybody
for
joining
us
and
go
to
sixstore.dev,
my
remembering
that
correctly
awesome
and
slack.sixstore.dev
all
right,
we'll
meet
you
all
there
thanks
again
ivan
and
bob
really
appreciate
it.