►
Description
Luke Hinds (Red Hat) will discuss project sigstore, a new Linux Foundation project designed to make the signing of software much easier and accessible for developers.
sigstore is a project with the goal of providing a public good / non-profit service to improve the open source software supply chain by easing the adoption of cryptographic software signing, backed by transparency log technologies.
sigstore seeks to empower software developers to securely sign software artifacts such as release files, container images, binaries, bill of material manifests, and more. Signing materials are then stored in a tamper-resistant public log.
A
A
A
A
A
All
right
everybody
welcome
back
to
monday
ama.
Today
we
have
a
new
topic
to
me:
sig
store,
luke
hines
is
here
with
us
from
red
hat
and
he's
going
to
tell
us
about
software
signing
for
the
masses.
This
is
a
new
to
me
and
probably
to
many
of
you
project
that
I
thought
would
be
good
to
get
a
101,
an
introduction
to
and
then
answer
any
questions
you
might
have
and
let
you
know
how
to
get
involved.
So
with
that
luke
introduce
yourself
and
rock
and
roll
great.
B
Yeah,
thank
you.
So,
yes,
it's
exciting
to
be
here.
Looking
forward
to
doing
this,
my
name
is
luke
heinz,
as
you
can
hear
from
the
accent
I'm
in
the
uk.
Although
some
people
say
I
sound
australian,
I
don't
know
why
I
work
in
the
red
hat
etl
office.
So
in
there
we
have
a
group
called
emerging
technologies
and
I'm
a
security
engineer
in
need.
So
it's
a
team
of
about
seven
of
us
and
we're
all
working
in
different
areas
of
security
and
yeah.
B
In
attacks,
some
of
the
ones
that
have
caught
mainstream
news
are
solar
winds,
attack
which
affected
many
us
government
military
systems.
We
can
expose
those
systems
to
risk
and
there
was
also
another
one
around
the
a
gas
line
pipeline
and
these
led
to
president
joe
biden
releasing
an
executive
order
to
address
the
secure
supply
chain.
So
this
is
an
area
that
I've
been
looking
at
for
a
while,
but
it's
got
some
significant
attention
on
the
eyes
on
this
basically
and
essentially
supply
chains.
B
So
there's
all
these
various
build
systems,
components
and
humans
and
packaging
systems
and
different
artifactor
types,
containers
tables,
binaries
files,
text
files
etc,
and
I
won't
really
do
a
deep
dive
into
the
attacks,
but
common
ones
that
we
see
are
account
compromise.
This
happens
quite
a
lot,
so
somebody
will
compromise
a
developer's
account,
a
compromise
of
build
systems,
we're
particularly
exposed
here
as
open
source
projects,
because
a
lot
of
our
build
infra
is
public
okay.
So
we
have
our
our
ci
systems,
perhaps
not
the
passwords,
but
how
our
ci
systems
operate.
B
Anybody
can
go
in
and
look
at
various
config
files
that
dictate
how
a
build
system
should
operate.
So
there's
a
lot
of
if
you've
got
very
easy.
Recce
around
this
rook
announce
high
post
squatting
happens
a
hell
of
a
lot
in
packaging.
Okay,
maintain
our
accounts
have
taken
over
there's
a
multitude.
I
could
have
put
on
a
lot
of
bullets
here,
but
it
would
have
been
over,
but
the
problem
is
that
general
consensus
is.
B
B
So
if
we
look
at
who
is
actually
signing
code
today,
we
look
at
some
critical
projects.
Critical
projects
is
open
to
interpretation.
People
might
feel
their
other
projects
that
aren't
listed
here.
That
are
perhaps
more
critical,
but
we
pick
some
of
the
ones
that
we
did
some
due
diligence
on
when
we
look
at
who
is
signing
code.
So
when
I
talk
about
signing
I'm
talking
about
generating
some
cryptographic
keys,
that
will
allow
you
to
sign
so
that
there's
no
repudiation
around
who
signed
it.
B
So
you
know
who
you're
getting
it
from
and
you
can
guarantee
the
attestation
the
integrity
of
that
particular
artifact
that
you've
received.
So
if
we
look
it's
kind
of
quite
a
dotted
landscape,
a
lot
of
people
are
using
pgp,
quite
an
old
tool
set
okay
and
most
of
the
time
they'll
do
something
called
tofu
trust
on
first
use.
So
you
just
assume
the
key
that
you've
got
is
from
the
individual,
who
you
expect
it
to
be.
You
import
it
into
your
keychain
and
that's
it.
B
B
Now
we've
got
kubernetes
there
when
we
originally
put
this
slide
deck
together.
Kubernetes
were
not
signing
anything
at
all.
Okay,
so
there
used
to
be
a
a
a
sad
smiley
face
there,
but
we've
actually
managed
to
to
on
board
the
kubernetes
community
now
so
they're,
actually
using
sixth
law
to
sign
and
verify
distressed
containers
that
are
coming
in
and
we're
also
looking
up
to
help
them
do
releases.
B
B
So
yes,
it's
a
very
gothic
landscape.
A
lot
of
some
people
do
have
these
tools,
but
they
don't
really
use
them.
Users,
don't
use
them
and
the
reason
they
don't
use
them
we'll
start
to
explore
soon.
So
when
you
sign
software
okay,
this
gives
you
like.
I
said
it,
gives
you
integrity
of
the
content.
So
if
I,
if
I
sign
a
table-
and
I
pass
it
over
to
you-
you
can
verify
that
and
you
can
be
sure
that
in
transit
nobody's
tampered
with
that
particular
table
okay
using
non-repudiation.
B
You
can
then
leverage
authentication
from
that.
Okay
and
then
you
can
also
get
some
sort
of
assurance
around
time
with
timestamping.
But
then
you
can
be
protected
against
certain
things
like
replay
attacks
and
so
forth.
But
the
problem
is
with
this
technology:
it
is
challenging
okay,
so
managing
of
the
so
managing
the
private
keys
is
difficult
for
a
lot
of
folks.
There
are
security
geeks
out
there
that
find
it
no
problem,
but
they're
generally
the
sort
of
three
percent
and
it
can
get
expensive
if
you're
going
to
do
it
properly.
B
You'll
need
something
like
a
ubiqui
or
a
hsm,
some
sort
of
cryptographic.
Hardware,
storage
security
standards
can
be
quite
complicated
and
difficult
to
understand.
For
some
people,
the
ux
of
the
tools
leaves
a
little
bit
to
be
desired.
Really,
revocation
is
difficult.
So
if
you
lose
your
key,
it
can
be
quite
difficult
to
clean
up
the
blast,
radius
and
existing
mappings
of
identity
to
key
pairs,
have
their
shortcomings
or
cannot
be
trusted
at
all.
B
The
other
thing
you
do
is
you
in
you
introduce
an
intermediate
trust
so
like
a
certificate
authority,
so
they
can
vouch
for
yes,
I
believe
this
to
be
this
individual.
Okay,
now
looking
around
again
examples
of
people
trying
to
use
technology,
and
this
isn't
to
blame
these
projects
at
all.
You
know
these
projects
are
actually
trying
to
do
the
right
thing,
they're
trying
to
sign
things.
B
If
we
look
at
the
example
on
the
left,
this
is
a
screenshot
from
the
tails
project.
Anybody
who
knows
tales
it's
a
linux
distribution,
that's
meant
by
it's
meant
to
use
by
whistleblowers
and
journalists,
so
their
privacy
and
in
the
the
the
assurities
of
their
security.
Those
are
the
utmost
important.
B
As
you
know,
it's,
it
can
be
a
hazardous
area
to
operate
as
a
whistleblower.
And
if
you
look
at
this,
the
keys
are
actually
stored
on
a
wordpress
site
and
wordpress
sites
are
hacked
all
the
time.
So
if
somebody
wants
to
hack
this
site,
they
could
just
swap
out
those
keys
for
a
net
fairies
pair
of
keys
and
then
essentially
compromise
a
load
of
whistle
guys.
If
we
look
at
the
right.
This
is
a
screenshot
from
the
node.js
release.
B
Page
and
again,
you
know
kudos
that
these
folks
are
trying
to
do
the
right
thing,
but
there's
a
lot
of
keys
to
manage
here.
Okay,
so
there's
these
various
keys
that
you
have
to
import
with
gpg,
and
then
you
have
to
import
some
users
that
used
to
be
on
the
project
but
aren't
on
the
project
anymore.
Okay-
and
you
know
this-
this
is
troublesome.
How
many
users
would
actually
do
this?
B
That's
the
thing
I
mean
I
was
speaking
to
somebody
that
works
in
the
container
engine,
another
pod
manager
for
daniel
walsh.
Some
of
you
might
know-
and
he
said,
look
how
many
people
still
use
gpg
in
their
email
very,
very
few
and
that's
a
kind
of
a
good,
a
good
kind
of
capture
really
of
of
how
these
tools
have
just
not
got
the
utilization.
B
So
we
thought
imagine
a
world
where
signing
was
just
a
lot
easier.
There
wasn't
the
pains
and
the
headaches
around
key
management,
you
know,
and
how
could
we
increase
the
adoption
and
the
proliferation
of
cryptographic
signing
and
verification
of
things
in
the
software
supply
chain?
So
we
came
up
with
this
idea
of
project
sigstor.
Okay
and
like
all
things,
we
tried
to
borrow
a
good
idea
and
then
sort
of
respin
it
into
the
particular
area
that
we're
looking
to
address.
B
So
we
we
looked
at
let's
encrypt
and
what
they
managed
to
do
where
you
had
an
internet
where
a
lot
of
sites
used
to
run
on
http,
let's
encrypt
came
along,
they
made
it
free
and
easy
to
get
https
certificates
for
your
website
and
then
where
they
did,
that
they
changed
the
optics
and
then
browsers
started
to
get
assertive
against
http
sites
and
show
them
as
being
something
that's
less
than
desirable
and
it
managed
to
shift
the
idiom.
You
know
it
changed
the
whole
optics
around
mining.
B
So
that's
what
we're
looking
to
do
with
sigskill,
so
sigstor
is
actually
a
it's.
A
group
of
projects,
open
source
projects
to
provide
the
infrastructure
and
the
client
tooling,
for
this
signing.
Okay-
and
it's
also
going
to
be
a
free
public
public
good
service,
okay,
that
anybody
can
use,
there
is
no
payment
for
membership,
there's
no
tiers
of
membership,
it's
free
to
use!
So
the
idea
being
this
that
this
will
be
a
service
that
is
for
the
good
of
all,
because
the
more
secure
the
supply
chain
is
the
better
it
is
for
everybody.
B
I
think
this
is
something
that
goes
above
any
individual
company
and
and
coincidentally,
all
of
this
stuff
runs
on
kubernetes
and
you
can.
You
can
run
this
in
a
cloud
native
environment,
so
we'll
have
a
look
at
what
the
various
projects
are,
that
big
store
the
constitute
sig
store.
So
we
have
a
project
called
forcio,
which
is
a
certificate
authority
that
provides
code.
Signing
certificates
based
on
an
open
identity,
connect
id
I'll
go
into
a
little
bit
more.
B
What
that
means
shortly,
but
we
have
recall
which
was
our
first
project
that
we
worked
on,
and
this
is
a
signature,
transparency
log.
So
this
is,
you
can
think
of
it
like
a
blockchain,
okay,
it's
a
system
that
when
you
enter
data
into
it
signatures
and
digest
and
so
forth,
they're
append
only
they're
immutable.
So
you
cannot
change
them,
so
nobody
can
tamper
with
that.
So
it
makes
a
good
public
point
of
accountability
around
signing
and
we
have
a
generic
container
signing
tool
and
we're
working
on
other
clients
for
signing
in
other
things.
B
Well,
so
we
have
one
like
a
maven
plug-in
a
ruby
gems
signer,
and
there
is
also
we're
starting
to
look
at
something
within
crates
for
the
rust
community.
So
there's
a
lot
of
work
going
on
around
building
these
various
client,
tooling,
so
a
kind
of
a
quick
overview
flow
of
of
how
we
manage
the
keys.
So
I've
spoken
about
the
private
keys
and
we
have
this
technology
which
we
call
keyless.
B
B
It's
a
it's
a
one-shot
job
and
then,
after
that,
there's
no
worrying
about
storing
the
key
or
revocation,
but
we'll
show
you
how
we
do
that.
So
so
we
have
a
user.
Okay,
they
have
an
artifact,
let's
say
a
container
which
they
want
to
sign.
Okay,
then
we
have
our
our
ca.
Also,
and
we've
got
two
transparency
logs.
So
these
are
the
merkle
tree
systems,
the
kind
of
blockchain
systems,
the
certificate,
transparency,
log
and
the
signature
transparency
log.
So
what
would
happen?
B
Is
the
client
would
generate
a
key
pair,
a
cryptographic
keypad,
so
a
private
key
and
a
public
key,
and
these
do
not
even
touch
disk.
These
are
encoded
to
memory
they're,
very,
very
short-lived.
After
that,
what
they'll
do
is
they'll,
make
a
request
to
our
ca.
Okay
and
what
they'll
do
is
using
the
public
key
and
they
will
hash
their
email
address.
Okay.
So
this
is
a
challenge
to
show
that
they
have
the
public
key.
The
email
address
is
just
a
an
announcement.
B
We're
not
even
not
sorry
it's
it's
just
a
a
value
that
is
easy
to
use
for
manage,
so
we're
not
actually
pulling
out
the
email
address
and
then
making
a
decision
that
this
email
address
belongs
to
this
user.
It's
really
for
us
to
have
proof
that
that
user
has
that
public
and
private
key
pair
on
in
their
in
their
in
their
person.
B
Okay
and
then
what
will
happen
is
we'll
then
send
them
back
and
they're
doing
this
manually,
we've
got
stuff
to
work
in
ci
as
well,
but
if
they're
doing
this
manually,
they'll
get
a
screen
then
where
they
can
log
in
with
an
open
identity
provider,
so
github,
google
or
microsoft,
we're
looking
to
incorporate
lots
more
as
well
there's
about
20
of
them.
Okay.
So
then
I
could
then
click
login
with
google,
okay
and
then
there'll
be
a
screen
where
I
can
grant
access
using
my
red
hat,
email,
okay
and
then
what
will
happen?
B
The
system
will
query
the
open
identity
provider
for
the
email
address.
Okay,
so
you
grant
us
as
an
application
the
permissions
to
get
your
email
address
from
google
or
github
or
microsoft,
whoever
it
is.
We
then
take
that
email
address
back
okay,
which
is
the
same
one.
You
did
the
hash
challenge
with
and
we
then
put
that
into
an
x
509
certificate,
okay
and
then
that
goes
into
a
system
called
a
certificate
transparency
log.
These
are
actually
used
quite
widely
as
well,
by
browsers,
okay-
and
this
is
actually
time
stamped
as
well.
B
B
Now
what
we
have
is
from
this.
We
can
now
discard
the
keys,
those
don't
matter
because
we've
frozen
in
time
this
particular
moment
that
an
individual
had
a
key
pair
in
their
person
and
proved
by
a
third
party
identity
provider
that
they
are
that
they
have
access
to
a
certain
account,
so
they
they're
associated
with
that
identity.
Okay
and
then
those
went
into
the
transparency
logs,
and
this
thing
gives
us
a
trust
root.
B
Okay,
so
any
user
can
perform
a
lookup
to
see
that
hellhines
redhat.com
generated
a
signature
using
a
certain
public
key
or
certain
artifact
example
of
container
digest
at
a
particular
time.
Okay,
so
you
have
all
you
need,
then,
to
verify
the
sign-in
event
of
a
container
image.
So
we
actually
have
this
working
with
oci
container
registries,
but
you
can
sign
a
container
using
your
email
address
now
some
people
when
they
look
at
they
say:
that's
that's
great,
but
email.
Is
that
really
secure?
B
Well,
it
arguably
is
because,
with
all
of
the
open
identity
providers,
you
can
utilize
two-factor
authentication
and
we're
looking
at
having
means
to
check
that
2fa
is
enabled.
So
then
you
do
have
some
good
security
protections
there.
Okay,
but
the
other
key
thing
is
the
email
address
is
in
the
transparency
log,
so
you
can
then
monitor
the
log
for
people
using
your
email
address.
B
B
Okay,
so
to
go
into
a
little
bit
more
about
I've
been
talking
about
these
things
called
transparency
logs,
so
we'll
try
and
understand
what
they
are
of
it,
so
it
use
utilizes
an
algorithm
called
a
merkle
tree.
Okay,
the
merkle
trees
have
been
around
for
quite
some
time.
Git
actually
uses
a
form
of
merkle
tree
block
chains,
use
a
merkle
tree
fedora
core
os
and
silver
blue
uses
a
merkle
tree,
but
a
kind
of
that
the
fedora
folks
might
not
agree
with
me,
but
it's
essentially
very
similar,
so
the
so.
B
Now,
if
I
was
to
try
to
tamper
with
any
of
those,
it
would
change
the
root
hash.
Okay,
so
somebody
can
effectively
know
that
the
integrity
of
achieving
has
been
compromised
somehow,
and
this
makes
it
a
very
good
system
for
public
countable
integrity,
okay,
so
another
technology
that
I
don't
have
listed
here
that
utilizes
this
is
bittorrent,
so
so
what
they
would
effectively
do
here
is
you've
kind
of
downloaded.
B
You
have
you
have
a
torrent
file
that
you
wish
to
download
for
the
torrent,
client,
okay,
and
what
torrent
clients
do
is
they
will
split
the
file
into
many
many
file
parts?
Each
of
those
file
parts
will
be
hashed,
a
sha-256
hash
of
them
will
be
captured,
okay
and
then
they
will
all
those
constitute
parts
will
create
a
merkle
tree.
So
all
of
these
hashes
will
have
a
root
hash.
So,
as
each
file
part
is
pulled
in,
you
can
capture
the
hash
and
construct
the
tree
and
then
compare
the
root
hash.
B
And
then
you
know
if
any
single
little
file
has
been
tampered
with
in
some
way.
It
will
obviously
change
the
entire
cryptographic
computation
of
the
tree,
so
it
makes
it
so
that
all
of
the
clients
that
are
part
of
the
bictorrent
network
that
are
seeding
or
niche
in
a
particular
file
can
all
verify
the
integrity
of
that
file.
So
you
don't
have
to
worry
about
one
evil.
Client
trying
to
to
to
to,
I
don't
know,
provide
a
virus.
B
So
these
are
merkle
trees.
So
this
is
a
project
we
call
recall
okay
and
transparency
logs
help
us
answer.
Questions
like
is
someone
using
my
private
key
or
my
identity
to
sign
artifacts.
If
some
keys
are
hacked,
leaked
or
lost,
what
is
the
brass
radius?
Okay,
so
we
can
do
due
diligence
around
attacks
when
they
happen.
Who
has
signed
a
particular
race?
Is
everybody
else
in
the
same
as
me,
or
am
I
facing
some
sort
of
man
in
the
middle
attack?
B
Okay,
and
how
can
I
be
sure
that
an
audience
source
is
ample
resistant?
How
can
I
be
sure
that
the
data
in
there
is
tamper
resistant
well
because
it
uses
merkle
tree
technology,
so
just
to
kind
of
a
little
bit
more
background
on
on
why
we
leverage
the
transparency
log?
Now
it's
using
another
technology
called
a
certificate
transparency,
and
this
is
run.
B
These
are
utilized
within
a
majority
of
browsers.
Now
some
browsers
are
yet
to
fully
implement
them.
Okay
and
let's
encrypt,
runs
one,
I
think
a
few
big
providers-
google
cloudflare,
they
all
run
a
transparency
log
and
we'll
have
a
look
at
how
that
works.
So
you
kind
of
go
get
an
idea
why
we
use
this
for
software
signing,
so
you
have
a
website,
admin,
okay,
a
browser
and
a
certificate
authority.
So
this
is
how
things
used
to
be.
B
So
what
would
happen
is
if,
if
you
wanted
difficult
for
your
website,
what
you
would
do
is
you
would
send
a
certificate
signing
request
to
the
ca?
Okay
and
then
the
ca
would
say.
Okay,
let
me
do
some
checks.
I
want
to
see
your
credit
card.
I
want
you
to
make
some
sort
of
record
to
show
that
you
own
the
domain
do
some
various
checks.
This
all
happens
behind
closed
doors,
they'll,
say:
okay,
we're
good
here's
your
certificate,
which
you
can
use
to
run
on
httpsbigbang.com.
B
Is
this
safe
for
me
to
do
so,
and
the
ca
will
say
yup
sure
here
we
go
there's
a
chain
of
trust.
You
get
a
nice
green,
padlock
and
everything
great
okay.
Now
the
problem
with
this
model
is
we're
essentially
putting
all
our
trust
into
one
single
authority
and
expecting
them
to
do
the
right
thing.
Okay
and
a
lot
of
what
they
do
is
behind
closed
doors,
it's
not
to
say,
they're,
doing
the
wrong
thing,
but
they're
not
auditable,
there's
no
public
audit
of
that.
Okay.
So
this
is
where
difficult
transparency
came
about.
B
So
with
certificate
transparency,
we
have
the
same
flow
again
early,
I'm
I
I'm
bigbank.com.
Here's
my
certificate
signing
requests,
ea
does
some
checks,
they
say
they're,
good,
okay,
but
there's
an
extra
step
now
where
they
now
have
to
send
the
certificate
training
to
a
difficult
transparency
log.
So
we've
got
this
certificate
transparency
log
as
the
new
actor
the
display.
B
So
what
would
happen
is
a
browser
would
say:
okay,
I'm
going
to
visit
a
site
certificate,
transparency.
Log!
Do
you
have
an
entry?
There's
actual
header
expect
ct
that's
utilized
and
if
the
certificate
transparency
log
says
no
and
then
there's
a
problem.
Okay,
so
I'm
not
sure
that's
the
actual
browser
area
that
you'll
get
but
you'll
get
some
sort
of
a
lot
of
browsers
will
give
you
a
kind
of
a
a
b
where
types,
but
we
now
have
this
certificate
transparency
log.
B
B
B
Okay,
so
I'll
do
a
quick
overview
of
some
of
seek
stores
projects.
So
we
have
falsio
the
ca.
Okay-
and
this
is
the
software
signing
certificate
authority,
okay,
so
here
we
have
a
system
that
can
generate
the
certificates,
it
can
query
and
make
grant
requests
to
the
open
identity
providers
and
it
can
interface
with
a
developer
okay.
So
this
gives
us
this
keyless
technology,
where
we
effectively
have
an
ephemeral
key
pair
again
and
a
few
interesting
things
about
this.
B
So
it's
quite
interesting.
This
was
quite
a
first,
where
we
had
an
open
source
and
openly
audited
route
certificate
that
was
generated
and
coming
soon.
Coincidentally,
other
projects
are
interested
in
using
our
root
ca
now
and
that's
the
the
ca
that
pins.
We
then
have
recall
the
transparency
log,
so
you
can
see.
All
of
these
projects
are
in
our
our
organization,
sig
store,
so
anybody
can
come
along
and
contribute
to
those
I'll
go
into
that
shortly.
B
B
B
We
have
a
rest
api
which
is
available
to
make
entries
to
the
log,
get
consistency
and
inclusion,
proofs
and
so
recall,
is
actually
starting
to
get
a
lot
of
leverage
outside
of
stick
store
like
the
keyless
sign
and
stuff
that
I've
told
you
about.
Lots
of
people
are
starting
to
use
this
for
means
of
firmware,
binary
transparency
and
all
sorts
of
other
interesting
security
cases.
B
We
run
a
public
good
instance.
That's
there
for
anybody
to
use
okay,
and
just
to
repeat
myself,
as
I
say
it
can
be
run
independently
of
a
project,
so
recall
has
what
we
call
a
plugable
pkl
interface,
so
you
can
send
x509
certificates,
gpg,
the
ssh
keys,
mini
sign
and
we
plan
to
add
other
sign-in
systems
as
well.
B
So
the
one
an
example
of
one
of
the
tools
is
cosine,
so
this
is
what
the
client
would
use.
So
the
previous
two
were
part
of
the
public
infrastructure.
The
service
that
supports
this-
and
this
is
an
example
of
a
client,
so
with
cosine,
what
you
can
do
is
you
can
generate
an
ephemeral
keeper,
okay
or
if
you
wanted
to
you,
could
use
kms.
So
we
support
vault,
the
aws
and
azure
and
gcp
kms
systems.
B
But
the
kind
of
the
the
exciting
case
is
the
ephemeral
key
pair,
so
you're
generating
a
femoral
key
pair.
You
crest,
you
request
a
signing
certificate
from
forcio,
the
ca.
Okay,
you
download
the
container
manifest
from
the
registry.
You
generate
a
signature,
you
push
that
signature
up
to
the
registry,
okay
to
an
oci
registry,
and
then
that
also
creates
an
entry
in
recall.
Okay.
So
then
you
have
that
captured
sign
in.
So
what
somebody
can
do,
then,
is
at
a
later
point.
B
B
The
key
part,
which
is
how
will
this
fit
with
openshift,
so
we've
very
much
planned
to
leverage
this
and
openshift.
So
I
speak.
I
spend
lots
of
time
speaking
to
different
people
that
work
in
the
various
silos
of
the
of
openshift,
so
quay
3.6
will
support,
dig,
store
signatures,
okay,
so
as
I'll
create
quay
3.6
you'll
be
able
to
do
this.
B
So
we're
working
with
the
folks
in
the
pogman
engine
team
to
implement
all
of
the
cosign
big
store
code
into
podman,
and
then
we
also
have
a
project
that
we've
worked
on
called
tecton
cd
chains,
and
this
allows
you
to
sign
tecton
pipelines
and
task
runs
and
that
will
of
course
likely
downstream
into
openshift
pipelines.
That's
our
hope.
So
all
of
these
technologies
are
planned
to
be
productizing,
openshift,
they're,
not
as
yet
guaranteed,
but
the
work
is
happening
upstream.
B
That's
as
much
as
I
can
say
at
the
moment,
okay,
so
there
is
no
official
release.
We
tend
to
sort
of
go
through
a
process
where
we
have
sort
of
developed
a
preview
and
tech
preview
performance
before
things
are
productized,
but
the
work
is
happening
upstream.
To
make
this
happen,
and
then
the
idea
is
that's.
What
somebody
will
be
able
to
do
is
find
any
containers
any
any
deployment.
B
Config
files,
all
of
these
you'll
be
able
to
find
with
six
store
and
you'll,
be
able
to
verify
as
well
and
we're
doing
lots
of
work
around
the
s1
as
well
secure
builder
materials.
So
you
have
a
kind
of
a
signed
ledger
or
inventory
different
systems
that
interacted
with
an
artifact
that's
constructed
within
a
supply
chain.
B
So
if
anybody
is
interested
in
more
information,
we
recently
got
a
really
nice
new
website
put
up
okay,
we
we
currently
are
in
soft
launch,
so
we
have
public
systems
that
are
available
for
you
to
utilize.
If
you
wanted
to,
you
could
download
cosign
now
and
start
signing
your
containers
start
using
the
admission
controller.
This
is
all
working
code
that's
available
and
we
have
public
services
that
are
free
to
use
and
we
also
have
an
open
api.
B
So
if
you
fancy
writing
your
own
client
for
your
own
use
case,
then
all
of
our
open,
all
of
our
apis
are
openly
documented,
relatively
easy
to
interact
with
those
they're
all
restful
apis,
and
our
next
plan
is
to
launch
a
public
service.
So
we
have
a
soft
launch
at
the
moment
and
we're
currently
in
discussion
with
linux
foundation
around
launching
this
full
public
free
to
use
service.
B
So
a
summary
100
open
source
code,
apache
2,
licensed
all
of
the
tooling
a
lot
of
the
operational
code
as
well,
will
be
open
source
we're
already
under
a
soft
launch.
So
if
you
want
to
have
a
play,
you
can
do,
there
will
be
a
free
to
use
non-profit
public,
good
service,
okay
and
the
current
members
that
are
involved
in
it's
expanding
quite
quickly
and
I
actually
need
to
update
this
is
red
hat
founded
members,
google
and
podo
university,
and
that
brings
me
to
the
end
of
the
presentation.
A
All
right
who,
who
was
that
asking
a
question
there?
I
have
a
lot
of
actual
questions
and
I'm
really
psyched
that
this
is
actually
happening
now
and
that
the
soft
launch
is
going
because
everyone
can
go
off
and
and
check
it
out.
Can
you
tell
me
a
little
bit
about
how
the
the
the
certificate
authorities
are
interacting
with
you?
Are
you
know,
are
they
adopted?
You
go
all
the
way
back
to
that
slide.
You
had
with
the
certificate
authorities
on
it
and
them
utilizing
it.
A
B
Good
very
good
question,
so
the
certificate
authority
side
is
covered.
That's
already
up
and
running
it's
a
sort
of
separate
effort.
That's
been
established
for
quite
a
while,
but
what
we
did
was
we
looked
at
what
they
did
and
then
we
thought
hold
on.
We
could
use
that
for
secure
supply
chain.
So
in
a
lot
of
ways,
we're
borrowing
some
some
of
our
ideas
from
them,
but
that's
actually
there
now.
A
All
right
and
tell
me
a
little
bit
about
the
soft
launch
and
the
relationship
with
the
linux
foundation.
I
mean
they're
they're
hosting
you.
Are
they
the
people
that
we're
trusting
to
host
this
or
how?
How
is
that
working,
or
is
that
just
where
the
data
code
is
stored?
That
is
a
little
fuzzy
for
me.
Of
course,.
B
Yes,
so
so
the
code
will
always
be
open.
Source
it'll
always
always
be
community
developed.
We
need
to
run
a
public
service
okay,
so
we
will
need
slight
reliability
engineers.
You
know,
folks,
with
pages.
If
the
service
goes
down
a
devrel
project
manager
type
individual.
So
we
need
some
staffing
to
run
a
sir,
and
so
we
didn't
really
want
to
do
that
as
a
any
particular
company.
B
We
wanted
it
to
be
a
neutral
body.
So
so,
let's
encrypt
are
actually
nested
under
the
linux
foundation.
They
have,
they
have
an
intermediate
called
isrg.
The
internet
security
was
dutch
group,
so
we
thought
lf
would
be
perfect
because
it's
a
neutral
body,
okay
and
then
anybody
can
sponsor
seekstore,
like
you
sponsor
the
cncf
or
any
particular
project,
and
then
that
money
would
then
be
utilized
by
the
lf
to
pay
their
staffing.
A
Yeah
so,
and
we
sort
of
inherently
trust
the
linux
foundation
to
remain
neutral.
So
that's
that's
a
good
thing
and
that's
a
good
place
placeholders
unless
encrypts
have
got
a
long
history
with
them.
So
that's!
That's
yes,
yeah!
So
technology
wise
in
open
shift.
Excuse
me
my
phone
decided
to
ring
hang
on
a
second.
A
B
A
A
And
who
wouldn't
be
because
we
are
creating
a
container
a
second?
Basically,
you
know
constantly
creating
containers
in
the
cicd
workflows
and
the
pipelines
that
we
create
with
openshift
and
so
that
that's
you
know
it's
going
to
be
an
interest,
interesting
adoption
channel
to
get
it
embedded
into
the
tech
ton
and
to
the
pipelines
and
do
that.
So
I
you
talked
a
lot
about
the
client
side
of
things
like
so
an
individual
wanting
to
sign
an
individual
container
but
from
an
enterprise
point
of
view,
so
say
some
big
bank,
that's
using
openshift.
A
B
Yes,
yeah,
it's
it's
very
clever.
I
mean
it's
somebody
that
I
work
closely
with
google
dan
lawrence.
He
was
the
one
to
come
up
with
this
keyless
idea,
which
really
that
was
just
that
was
the
killer
use.
But
I
mean
we
had
the
interesting
technology
around
the
transparency
line,
but
he
came
up
with
this
idea
of
leveraging
open
identity
connect,
and
that
was
like
amazing.
We
don't
you
know,
we
don't
have
to
worry
about
managing
the
keys
anymore.
B
You
know-
and
so
it
was
very
much
like
a
a
real
sort
of
open
source
success
story.
Where
somebody
created
something
and
said:
hey
I've
got
this
thing
and
then
somebody
else
said:
okay,
that's
interesting,
have
you
thought
about
doing
this
and
it
just
blew
up
from
there
and
then
right
project
at
the
right
time?
Suddenly,
you
know
supply
chain
attacks
became
daily
news.
A
I
think
it's
going
to
be
a
really
interesting
because
we've
definitely
gone
over
the
tipping
point
with
creating
containers
like
we
have
well.
You
know
with
the
advent
of
kubernetes
and
you
know
all
of
the
different
just
distributions
of
kubernetes
and
all
the
different
ways
and
flavors
that
we
install
it
everywhere
on.
On
the
you
know,
every
different
clouds
provider,
but
I
I
think
this
is
one
of
the
things
that
should
have
been
for
me.
A
B
B
Virus
or
it
feels
a
bit
dirty,
it's
socially
unacceptable
and
we
want
the
same
thing
for
containers
and
artifacts.
Really
you
know
it's
not.
Even
if
it's
not
us,
that's
signing
it's
not
about.
We
want
to
control
everything
and
nothing
runs
unless
six
stops,
but
it
just
if
we
can
help
that
momentum.
You
see
what
I
mean
then
yeah.
A
Not
that
I
want
to
pile
anything
on
else
on
the
certification
programs
that
we
have
here
at
red
hat
for
containers
and
other
things.
But
it's
it
seems
to
me
that,
like
red
hat
is
in
the
business
of
being
trusted
too
and
and
a
lot
of
other
companies
are
and
a
lot
of
the
fsi
and
the
government
agencies
and
all
those
folks,
I
mean
there
should
be
a
tsunami
of
people
who
want
to
embed
this
beyond
red
hat
and
other
other
folks
and
and
make
this
happen.
A
B
B
Translations
will,
of
course,
follow
suit
development,
wise
we're
reaching
like
cosine
hit
1.0
and
we're
looking
to
release
recoil
as
1.0,
but
there's
still
lots
of
work
to
do.
You
know
improve,
perhaps
improve
our
ci
testing
coverage
and
no
sorry,
not
not
not
code
coverage,
but
integration
tests
can
be
improved,
I'm
sure
and
and
client
tooling.
Really.
So
we
put
up
this
public
infrastructure
and
it's
just
begging
for
people
to
come
along
and
be
creative
and
create
their
own
tooling
around.
B
And
the
other
thing
that
massively
helps
us
is,
if
you
start
using
seekstore,
because
because
the
more
open
source
projects
we
have
that
are
adopting
us,
I
mean,
of
course
somebody
does
the
assesses
it's
useful
to
them.
Okay,
but
if
they
do,
then
they
let
us
know
that
helps
us
then
say:
look
you
know
it's
important
this.
This
service
runs
because
people
are
relying
on
us,
yeah.
A
So
that
brings
me
back
to
the
kubernetes
side.
You
mean
we
talked
a
little
bit
about
openshift,
because
it's
an
openshift
comments,
briefing
and
all
of
that.
But
what
is
how
does
stig
store
and
all
of
your
projects?
How
do
you
interact
with
the
kubernetes
community?
Are
you
heading
to
kubecon,
in
los
angeles.
B
B
B
A
B
Which
we
actually
borrowed
the
idea
from
the
tecton
cd,
where
companies,
individuals
and
projects
that
are
using
us
can
put
in
a
testimonial
about
how
they're
using
us
how
it's
been
a
benefit
to
them
and
also
our
twitter
as
well
so
at
project
six
store.
Twitter
is
very
much
where
we're
very,
very
active
on
twitter.
There's
a
project,
six
store,
twit
twitter
account
and
it
retweet
retweets.
B
All
of
my
tweets
that
I
make
about
seekstore
or
my
sort
of
partnering
crime
dan
lawrence
over
for
the
google
open
source
security
team
stuff
that
he
does
gets
retweeted
and
and
anybody
in
the
community
that's
doing
something
I
mentioned
sigstor.
We
try
to
sort
of
to
let
people
know.
So
that's
a
really
good
way
to
stay.
On
top
of
us.
A
B
B
Okay
and
then
here
you'll
find
there
is
not
actually
on
the
front
page,
but
there
is
a
community
okay
and
then
in
here
you'll
see
there's
a
google
calendar
invite.
So
if
you
click
on
that,
you'll
make
an
entry
where
we
have
our
weekly
meeting.
Okay
and
there's
also
an
invite
to
our
slack
channel
make
that
a
little
bit
bigger.
So
we
have
a
slack
channel.
There's
600
people
in
there
welcome
to
come
along
and
ask
questions,
and
then
we
also
have
our
our
new
website.
B
B
A
B
A
B
A
Following
me,
all
right
take
care
and
we'll
get
the
slides
from
you
and
put
it
up
as
a
blog
post
on
openshift.com
shortly.
So
anyone
listening
along
and
go
grab
the
slides
and
please
do
check
out
the
sig
store
site
and
we'll
make
this
one
of
the
hottest
projects,
hopefully
because
it's
necessary
right
all
right.