►
From YouTube: OpenSSF Day at OSS NA - Demystifying Digital Signatures - Priya Wadhwa, Chainguard, Inc
Description
OpenSSF Day at Open Source Summit North America - Demystifying Digital Signatures - Priya Wadhwa, Chainguard, Inc
A
Priya
wadwa
is
a
senior
software
engineer
at
chain
guard
where
she's
working
with
the
sig
store
community
sig
store
and
security,
tooling
working
groups
and
she's
helping
maintain
both
sig
store
and
tecton
projects.
Priya
is
passionate
about
making
security
easy
and
accessible
for
all
developers
and
is
excited
to
share
more
about
sig
store
today.
So
I
invite
priya
to
come
up
and
get
all
connected
in,
so
that
we
can
learn
more
about
these
incredible
supply
chain
projects.
B
B
B
So
just
out
of
curiosity
to
see,
I
just
want
to
get
a
sense
of
like
how
familiar
people
already.
Could
you
raise
your
hand
if
you've
heard
of
six
star
before
okay
great
a
lot
of
people?
Could
you
also
raise
your
hand
if
you've
actually
used
six
story
before
okay
cool
about
half
the
people?
Okay,
great,
that's
great
to
see
because
I'm
gonna
start
a
quick
overview
of
six
store
how
it
works.
B
B
So
before
we
talk
about
six
door,
I
just
wanted
to
talk
about
signatures
in
general
and
kind
of
what
signatures
guarantee.
So
the
main
purpose
of
a
signature
is
to
guarantee
that
software
has
not
been
changed
since
it
was
signed.
So
if
the
verification
comes
out
correct,
we
can
be
sure
that
the
software
has
not
been
tampered
with.
Since
the
signature
happened,
we
can
also
use
signatures
to
know
what
producers
a
software
a
piece
of
software
came
from
and
they
can
actually
be
used
as
points
of
validation
in
a
larger
pipeline.
B
B
B
So
the
thing
about
having
a
private
key
pair
as
a
maintainer
is
that
keeping
long-lived
private
keys
is
not
easy.
Safe
is
not
easy.
It
kind
of
assumes
that
you're
not
going
to
lose
them,
and
it
also
means
that
they're
not
going
to
get
stolen
and
so
kind
of
puts
a
lot
of
the
onus
on
the
maintainer
to
keep
their
private
keys
safe.
B
It
also
puts
the
burden
on
the
maintainer
to
figure
out
how
to
distribute
their
public
keys
to
end
users,
and
then
it
also
means
that
end
users
have
to
figure
out
how
to
verify
software
before
they
use
it
themselves,
and
this
can
kind
of
be
really
difficult
to
do,
especially
if
you
just
want
to
run
software,
and
you
don't
want
to
think
too
hard
about
how
to
verify
it
first
search
code.
Signing
certificates
are
an
option.
B
And
so
that
kind
of
puts
us
all
in
the
position
that
this
is
fine
dog,
where
we
just
sort
of
sit
there
and
it's
too
hard
to
get
out
of
the
fire.
So
we
just
accept
it,
and
this
is
where
zig
store
comes
in.
So
the
good
news
is
that
you
can
use
six
sixty
today
for
signing
your
software
and
we
you
don't
even
actually
have
to
manage
keys
if
you
don't
want
to
so
how
does
this
work?
So
we
have
so
part
of
my
drawing
skills.
B
B
B
So
with
cosine,
you
can
run
a
simple
cosine
sign
and
sign
any
sort
of
software
that
you
have
and
under
the
hood,
cosign
is
going
to
use
the
openid
connect
protocol
to
verify
your
identity.
So
it's
going
to
basically
take
you
to
this
page
in
your
browser
log
into
six
store
where
you're
gonna
log
in
with
your
email
address,
and
we
support
a
lot
of
the
big
providers
like
github,
google
and
microsoft.
B
You
basically
will
log
in
with
your
email
and
cosign
will
retrieve
the
identity
token
associated
with
this
protocol,
and
that's
basically,
how
you
prove
who
you
are
by
signing
in
with
your
email
address.
This
is
where
one
of
the
core
six
store
services
comes
into
play,
so
this
service
is
called
full
seo.
Our
code
signing
certificate
authority.
B
B
Full
cio
is
going
to
verify
that
identity
token
and
then
embed
the
associated
email
address
and
the
certificate.
So
you
know
that
the
certificate
has
been
issued
to
this
particular
email
address
under
the
hood
coastline
is
also
going
to
generate
an
ephemeral
public
private
key
pair.
It's
going
to
use
the
private
key
to
sign
the
software
and
then
that
public
key
will
also
be
embedded
in
the
certificate.
B
The
ephemeral
key
pair
actually
just
always
lives
in
memory,
never
hits
disk.
So
we
kind
of
call
this
keyless
signing
with
keyless
in
quotations,
because
while
there
is
a
key
pair,
you
really
don't
have
to
think
about
it
or
worry
about
it.
It
all
sort
of
happens
under
the
hood
and
then
disappears
once
the
signing
is
done.
B
So
at
this
point,
we've
kind
of
with
vulcio
we
kind
of
have
removed
the
need
for
public
private
keys
and
we're
just
using
these
free
code
signing
certificates
instead,
and
then
this
is
where
the
final
core
segstore
service
comes
into
play,
so
we
have
recore,
which
is
append
only
immutable
transparency
log.
So
once
you
add
entries
into
the
transparency
log,
they
can't
be
changed
and
they're
there
forever
and
they're
completely
publicly
accessible.
B
B
B
Okay,
if
everything
works
out,
and
so
basically
the
only
thing
the
end
user
really
has
to
do
is
take
a
look
at
the
identity
embedded
in
the
certificate
and
decide
if
they
trust
it.
So
yeah
simplifies
a
lot
of
this
process,
so
signing
with
cosign
is
pretty
easy.
I've
got
some
of
the
sample
commands
here,
so
you
can
sign
images,
anything
that
lives
in
an
oci
registry,
there's
also
support
for
assigning
arbitrary
files
or
blobs,
and
then
specific
support
for
signing
out
of
stations
and
s-bombs.
B
So
if
you
have
an
attestation
or
an
s-bomb,
especially
associated
with
an
oci
image,
you
can
actually
sign
it
and
cosign
will
upload
it
to
your
oci
registry,
where
it'll
live
alongside
the
image
verifying
pretty
much
exactly
the
same.
But
with
verification
as
an
end,
user
run
verify
for
images,
verify
blob
for
blobs
and
verify
attestation
for
attestations
and
s-bombs,
and
then
we
actually
have
a
six
star
policy
controller
as
well.
B
So
this
will
basically
the
policy
controller
is
basically
a
kubernetes
emission
web
hook,
which
you
can
run
in
your
cluster
and
supports
q
and
rego
policy
definitions.
So
with
this
you
can
basically
say
I
only
want
to
accept
images
into
my
cluster
that
have
been
signed
or
have
been
signed
by
this
particular
identity
or
images
that
come
with
an
attestation.
B
B
You
get
this
little
warning
that
your
email
address
will
be
stored
in
a
public
transparency
log,
so
everyone
will
be
able
to
see
it,
and
I'm
just
going
to
sign
in
with
my
email
now
under
the
hood
consent
can
do
everything
that
I
just
showed
in
my
amazing
artwork.
It's
going
to
request
a
certificate
from
from
full
co
and
then
store
an
entry
in
the
log.
B
That
basically
gives
some
information
about
how
this
image
was
built.
So
I
have
this
custom
software
provenance
attestation.
It's
not
super
helpful.
I
built
the
image
with
docker,
but
with
cosine
we
can
actually
sign
this
out
of
station
and
then
store
it
alongside
the
image.
So
it's
pretty
easy
cosign
a
test,
I'm
going
to
pass
in
the
name
of
my
image
pass
in
the
attestation
and
then
say
that
it's
an
attestation
of
type
salsa
providence
and
we're
going
to
go
through
the
same
flow.
B
B
Image
and
it'll
grab
the
entry
from
the
transparency
log.
Do
all
the
verification
make
sure
the
certificate
is
valid
and
you
can
see
that
the
certificate
has
been
issued
to
me.
So
at
this
point
I
just
have
to
decide
if
priya
at
chainguard.dev
is
trustworthy
because
that'll
be
a
fun
exercise
for
all
of
you.
B
And
then
we
can
also
verify
the
attestation
with
the
verify
attestation
command.
I'm
going
to
remember
to
pipe
this
one.
So
it
looks
a
little
prettier
and
yeah
looks
like
it
checked
out
a
similarly
certificated
subject
is
me
issued
by
google,
so
quick
demo
of
how
you
can
really
easily
sign
and
verify
things
with
cosine.
B
B
You
can
either
choose
to
sign
certain
commits
or
you
can
set
it
up
to
sign,
commits
by
default,
and
it's
really
cool,
because
you
can
basically
have
this
additional
guarantee
that
the
person
who
actually
wrote
the
code
also
owns
the
email
address
that
was
signed
off
with
philly,
who
has
been
working
on
this
project.
I
stole
this
like
little
screenshot
of
his
commit.
So
at
the
moment
there
are
a
couple
of
limitations
with
goodstein.
B
The
six
store
ca
route
is
not
in
the
github
trust
route,
so
the
commits
still
kind
of
show
up
as
unverified,
but
hopefully
that
will
be
worked
on
in
the
future
and
at
the
moment,
anyone
with
access
to
the
commit
can
still
do
the
verification
and
make
sure
that
the
commit
was
and
see
what
email
a
commit
was
actually
signed
with
another
quick
demo
of
this.
So
I
have
a
little
repo
I'll
just
add
in
a
little
file
that
we
can
add.
A
B
And
we
go
through
the
same
flow
I'll
sign
in
with
my
email
and
we're
good
commit
is
done.
So
if
I
wanted
to
actually
see
the
signature
on
this
comment
now
I
can
do
this
command
and
under
the
hood,
git
sign
is
going
to
grab
the
relevant
entry
from
the
transparency.
Log
say
that
the
certificate
was
issued
by
six
store
that
it
was
made
by
me.
Pre,
chainguard.dev
and
it'll
just
verify
everything.
B
B
So
I
can
grab
the
required
entry
from
recore
print
it
out.
We
can
see
what's
in
it,
so
it's
kind
of
the
same
thing
as
what
we
saw
before
the
encoded
certificate
and
the
associated
signature.
If
we
pull
the
signature
and
the
certificate
out,
we
can
use
cosine
verify
blob
to
actually
verify
the
commit
shot
here.
So
we're
going
to
pass
in
the
certificate,
the
signature
and
then
the
commit
sha,
and
this
should
hopefully
verify
yeah,
and
so
it
looks
like
it
all
worked
out,
and
we
know
that
the
commitment
was
signed
by
me.
B
B
Awesome
so
wrapping
up,
I
just
wanted
to
talk
a
little
bit
about
what
I
and
a
bunch
of
people
in
this
room
have
been
working
on
six
story:
ga
we're
working
on
general
availability
for
the
course
six
star
services
record
and
full
seo.
We've
done
a
lot
of
work
in
the
past
few
months
and
we
still
have
some
work
to
do,
but
it's
moving
along
really
well
and
some
cool
things
that
will
come
with
six
door.