►
From YouTube: Protecting the world’s greatest open source ecosystem with Sigstore by Patrick Flynn , Appu Goundan
Description
Would you make a sandwich with lettuce or tomatoes you picked up off the street? For most people, we hope, the answer is "no". We like to know that our ingredients are clean, who produced them and if they're safe to eat. Today many of us build software with 3rd party packages but there either isn't enough metadata or we're all too lazy to determine if they're truly safe to use. We risk accidentally shipping broken, vulnerable or dangerous software through compromised credentials, dependency confusion attacks or any of the many other techniques malicious actors have at their disposal.
Sigstore, an OpenSSF project to make cryptographic signing of artifacts easy to do and to verify, is a core part of solving the dependency trust problem. In this talk, by two of the sigstore-java maintainers, we will be introducing you to the Sigstore project and it's use with Maven Central. We’ll show how you, as a producer or consumer of Maven Central artifacts, can use Sigstore to sign and verify your artifacts and protect yourself and your users from malicious software supply chain attacks.
APPU GOUNDAN
Appu is a Software Engineer on the Google Open Source Security Team (GOSST) with a focus on securing the open source software supply chain. He has no actual ghost busting abilities, but has a decade of experience in Java developer tooling.
PATRICK FLYNN
Patrick Flynn works on software supply chain security for Chainguard. Prior to Chainguard Patrick led worked at Google where he was the TL of notable products like reCAPTCHA, Cloud Code, as well as leading the Google Cloud's Java Tools team that built Jib (the Java container image builder).
A
Thank
you:
hey
excited
to
be
here
in
Belgium
today
we're
talking
about
protecting
the
world's
greatest
open
source
ecosystem,
whichever
I
mean
with
six
store,
the
ecosystem
is
job,
so
this
is
us
I'm
Abu
on
the
bottom
right
I'm,
a
software
engineer
at
Google
I've
been
working
in
Java
tooling,
for
a
while
I
worked
on
jib,
it's
pretty
if
you've
ever
used.
That
I
also
maintain
some
just
release
images
and
I'm
working
on
six
door.
A
Attackers
have
been
finding
new
ways
to
attack
software,
not
while
it's
running
anymore,
but
before
it
even
starts
running
at
the
source
during
build
and
inventory
and
distribution.
So
what
can
we
do
we're
here
to
talk
about
six
door?
So
that's
what
we're
trying
to
do.
We
think
six
door
can
help
solve
some
of
these
problems.
A
So
what
is
sick
store?
It's
a
fast,
growing,
open
source
community.
It's
several
projects
within
the
open
SF,
which
is
part
of
the
Linux
Foundation.
It
contains
free
community
operated
and
publicly
available
services
like
a
transparency
log
and
a
certificate
Authority
and
a
bunch
of
language
clients
to
simplify,
signing
and
verification.
A
A
B
B
B
The
attacks
are
real.
You
know
this
is
happening
more
and
more,
as
you
saw
in
that
graph,
the
there
are
various
ways
in
which
your
dependencies
can
become
compromised.
It
starts
at
the
source
right
if
somebody
gets
access
your
GitHub
credentials
and
can
like
actually
get
code
into
your
repo
you're
kind
of
hosed
right.
They
can
get
like
if
you're,
using
CI
for
the
signing
and
automated
pushes
to
the
repos.
These.
These,
like
their
hack,
is
going
to
look
completely
valid
to
your
users.
B
B
If
somebody
gets
access
to
those-
and
this
has
happened
also-
they
can
push
whatever
kind
of
artifacts.
They
want
to
your
namespace
in
the
package
repository
and
reach
a
lot
of
users
that
way
they're,
also
dependency,
confusion,
attacks
which
is
effectively
because
you
know
at
Enterprise,
sometimes
you'll
have
internal
repos
and
there'll,
be
fallback
algorithms,
or
even
like
on
Android,
for
a
long
time
with
Gradle
people
would
have
like
jcenter
and
Maven
Central
configured
as
repositories
in
the
in
their
builds.
B
Finally,
you've
got
typo
squatting,
which
is
kind
of
like
a
spray
and
pray
approach
to
to
attacking
people,
because
you're
just
kind
of
hoping
that
somebody's
gonna,
you
know,
make
a
mistake
when
they're
typing
in
the
namespace
and
pull
your
version
instead
of
there
instead
of
the
right
one.
But
it's
happened
and
it
actually
happens
quite
a
lot
and
you
can
reach
quite
a
lot
of
devices.
That
way
too.
B
And
so
what
are
the
solutions
like
the
chain
guard
approach
to
this?
To
much
of
those
problems
is
trying
to
imbue
cryptographic
trust
throughout
the
supply
chain,
and
you
know
most
people
know
about
cryptography
being
a
valuable
thing
for
sort
of
hiding
secrets
for
transmitting.
You
know
your
credit
card
to
Amazon
when
you're
buying,
whatever
it
is,
you
buy
it,
but
it
also
can
be
a
form
and
it
is
really
importantly,
is
a
form
of
verifying
identity.
B
Yeah.
Ultimately,
if
you
sign
something,
you
are
proving
to
an
entity
that
you
are
the
owner
of
the
private
key
peer
to
the
public
key
you
signed
with
and
that
that's
generally
useful
right
and
it's
not
new,
as
you
know,
probably,
if
you
use
Maven,
Central
or
maybe
not,
even
though
you
use
Maven
Central
every
artifact
in
Maven
Central
requires
a
pgp
sign.
A
sign,
signature
and
websites
obviously
use
this
very
effectively
today.
B
Like
I,
said
Maven
Central
enforces
pgp,
so
there
are
signing
there,
but
the
reality
is
that,
like
in
other
ecosystems,
people
just
don't
sign
or
the
systems
make
it
optional,
and
even
if
you
do
sign
with
pgp
at
least
Jason
Van
ziel,
a
co-founder
of
Maven
and
Maven
Central
points
out
here
that
only
around
two
percent
of
folks
that
are
downloading
artifacts
are
also
downloading
the
signatures
that
go
with
them
to
verify
them.
So
signing
is
great,
but
if
you're
not
verifying,
there's
not
a
whole
lot
of
value
there.
B
Your
transitive
depth
tree
is
probably
exposed
to
a
significant
amount
like
you're
talking
about
hundreds
of
jars
sometimes,
and
that
means
hundreds
of
Open
Source
maintainers.
Some
of
them
are
coming
from
like
Enterprise
areas
where
everything's
signed
and
going
through
CI
some
are
being
built
on
somebody's
computer
and
that
hobbyist
is
not
going
to
go
through
the
trouble
of
storing
their
pgb
key
somewhere,
safe
somewhere,
where
they
can
reliably
get
access
to
it
and
then
somewhere,
where
they'll
know.
B
The
other
problem
is
key
distribution,
so
I
I,
don't
know
if
you're
familiar
like
for
verification
to
actually
make
sense
in
the
pgp
world.
It
depends
on
the
web
of
trust,
and
one
of
the
one
of
the
sort
of
Ceremonies
in
in
the
web
of
trust
was
like
the
idea
of
a
signing
party.
Everybody
gets
together
with
their
pgp
keys,
they
sign
each
other's
keys
and
over
time.
Hopefully,
you
have
like
a
transitive
connection
between
somebody.
B
This
is
a
great
idea,
but
in
practice,
at
our
scale
in
you
know,
in
the
global
World,
it
doesn't
really
work
and
I.
Believe
hervey
is
going
to
talk
about
this
in
a
talk
right
after
this
one.
So
I
encourage
you
to
go
check
out
his
pgp
versus
six
door.
Talk
for
Maven
Central,
the
ca
Authority
model,
the
one
that
you
see
using
the
web
has
proven
to
be
pretty
successful
and
six
door
has
taken
that
approach
instead.
B
So
how
does
the
ca
Authority
model
work
right
like?
Ultimately,
what
problem
is
it
solving?
So
we
have
upu
here
and
Jason
vanziel
another
contributor
to
six
door.
Java
who's
worked
on
the
maven
plugin,
now
they're,
separated
by
the
metaverse
up,
who
has
never
met
Jason
in
real
life.
They
need
to
talk.
B
They
need
to
trust
each
other's
identity,
which
means
that
upu
needs
to
trust
Jason's
public
key,
but
he
can't
just
take
it
from
Jason.
It
just
doesn't.
There's
no
reason
for
him
to
trust
that
public
key,
because
there
could
easily
be
a
man
in
the
middle
attack
where
the
public
key
is
replaced
by
some
other
public
key,
so
Apu
needs
a
way
to
actually
determine
that.
That
key
is
safe,
an
easy
way
to
sort
of
look
at
an
example
where
that
problem
is
solved
is
online
right
on
the
web.
B
If
you
take
a
look
at
this
browser
window,
I'm
sure
you've
always
you've
all
seen
this,
and
you
look
for
this
when
you're
doing
online
transactions
or
want
to
preserves
your
privacy.
It's
that
lock
icon
up
in
the
browser
telling
you
that
your
your
communication
is
going
over.
Https
https
makes
use
of
certificates
and
those
certificates
are
actually
coming
from
the
same
server
that
is
serving
the
google.com
right.
That
certificate
includes
a
public
key,
but
why
are
you
trusting
it?
The
answer
is
the
certificate
Authority.
B
The
certificate
Authority
solves
this
problem
by
creating
a
trusted
third
party.
That
is
not
just
somebody
on
your
web
of
trust.
It's
like
a
large
business
with
an
office
and
people
and
they
go
through
the
the
hard
work
of
verifying
that
the
the
public
key
that
that
wants
to
assert
that
it
is
some
identity
is
actually
actually
belongs
to
that
identity.
Of
course,
it
has
its
own
bootstrapping
problem
right.
Why
do
you
trust
a
certificate
Authority
if
you've
never
been
there
if
they've?
B
Never,
given
you
their
public
key
on
a
piece
of
paper
or
something
and
the
way
that's
solved,
and
it's
I
mean
it's
not.
You
know
perfect,
is
that
at
the
moment
typically
Cas
have
their
public
Keys
baked
into
your
operating
system
right.
So
many
of
you
might
know
this,
like
you,
can
find
that
you
can
find
a
list
of
the
ca
public
keys
in
the
OS
browser.
Vendors
have
also
started,
and
it's
been
a
while
baking
CA
Authority
public
keys
that
they
trust
into
the
browser.
B
So
how
can
six
store
replicate
this
model
of
having
a
CA
based
authority
to
verify
everybody's
public
keys
right?
So
that's
a
lot
to
handle.
We
need
to
safely
generate
the
like
keys
for
the
for
the
root,
so
we
need
these
private
Keys.
We
need
to
store
those
keys
somewhere
safe.
We
need
to
be
able
to
handle
rotation
and
we
somehow
to
handle
distribution
as
well.
B
Tough
is
the
framework
that
we
use
is.
It
was
developed,
I
think
it's
part
of
the
cncf
and
it's
a
it's
used
by
a
number
of
large
companies
whose
name
generally
kind
of
all
are
missing
from
my
brain.
At
the
moment
they
provide
a
framework
for
Distributing,
really
important
things
like
software
updates
and
keys.
B
So
one
of
the
really
Key
Parts
is
that,
like
you,
want
to
be
able
to
suffer
the
compromise
of
a
key
without
being
completely
owned
and
one
of
the
ways
we
do
that
at
six
store.
Is
we
instead
of
having
one
private
key
for
the
root
we
have?
Five
and
those
five
keys
are
owned
by
five
separate
people
distributed
globally
and
stored
offline
in
Secure
Hardware?
B
This
means
that
if
one
or
two
of
those
keys
gets
compromised,
we
can
still
like
push
forward.
Tough
also
helps
us
protect
against
malicious
mirrors,
rollback
attacks,
fast
forward
attacks,
and
many
more
so
now
that
we
have
a
safe,
Public,
public,
key
and
private
key
pair
for
CA
root.
How
do
we
distribute
them?
We
actually
distribute
them
with
our
clients.
So
if
you're
familiar
with
cosine
the
CLI
or
if
you
use
six
store
Java
the
ca
root,
public
keys
are
bundled
with
the
clients
and
then
copied
into
your
system
ad
initialization
time.
B
B
Yeah,
so
getting
a
new
https
cert
back
in
the
day,
was
sort
of
like
applying
for
your
driver's
license.
It
was
something
that
you
had
to
do
like.
Maybe
you
called
somebody
up
or
you
had
to
submit
like
photo
ID,
you
had
to
pay
money
and
it
took
sometimes
weeks
to
do
and
clearly
nobody
wants
to
do
this
for
like
most
most,
especially
like
non-profit
use
cases.
B
B
So
not
only
is
it
easy
now
to
get
assert
like
you
can
automate
it,
and
we
have
these
great
tools
like
certbot
and
cert
manager
on
kubernetes
that
handle
rotation
and
everything
for
you
suddenly,
like
you,
don't
even
need
to
know
about
how
to
handle
certs.
It
just
gets
done
right,
and
this
is
really
evidence
that
developer
experience
matters
and
it's
the
lesson
that
six
door
thinks
it's
going
to
successfully
apply
to
code
signing.
B
A
A
A
Let's
start
with
full
Co
is
one
of
the
infrastructures
infrastructure
services
that
sixer
provides
it
embeds
your
verified
identity
in
the
certificate,
unlike
pgp,
where
you
could
just
say,
hey,
I'm,
I,
don't
know
CEO
of
Microsoft
microsoft.com
fulcio
will
verify
that
you
do
indeed
control
that
email
address.
We
use
short-lived
signing
certificates.
This
is
helps
kind
of
it
keeps
you
from
having
to
like
manage
keys
and
we
discard
private
keys
after
use
every
signing
event.
A
A
So
let's
try
to
answer
the
question
of
who
signed
this
oledc
tokens
are
a
way
to
show
identity,
they're
issued
by
various
authorities
for
people
or
even
machines.
So
in
this
case
we
have
an
oidc
provider.
You
may
have
seen
something
like
sign
in
at
Google
or
sign
in
with
Google
for
some
third-party
site.
They
obtain
an
oidc
token.
That
proves
your
identity,
so
you
can
sign
in
when
I
say
I'm
a
human
at
test.com
and
this
information
is
embedded
in
the
oidc
token,
so
someone
can
use
that
to
verify
your
identity.
A
A
Now
we're
not
actually
saying
you
have
to
pick
proving
that
you're,
a
human
or
a
robot,
it's
up
to
the
release,
Engineering
Process,
to
decide
whether
to
include
humans
or
trust
in
the
machines.
No
Skynet,
please,
but
the
six
door's
goal
is
to
provide
the
mechanisms
to
use
the
identities
to
fulfill
like
anyone's
security
requirements.
A
To
continue
on
who
signed
this
when
you're
asking
full
Co
for
certificate,
you
have
to
prove
that
you
have
the
private
key
along
with
the
public
key.
So
one
simple
way
to
do
this
is
to
just
sign
the
identity
and
send
that
signed
identity
over
to
fulzio,
along
with
the
token
and
the
public
key
full
sale.
Can
then
decode
the
signature
using
the
public
key
and
decide
like
hey?
You
probably
have
the
private
key.
A
A
You
first
obtain
proof
of
identity,
so
that
can
come
from
your
IDC
provider.
You
generate
public
private,
key
pair
use,
the
private
key
to
sign
the
identity,
and
then
you
send
the
token
signed
identity
and
public
key
over
to
full
Co.
Full
Co
does
some
verification
here.
It
verifies
the
ID
against
the
ID
oidc
provider.
A
So
it
says
you
claim
to
be
upload.
Google.Com
I'm,
going
to
go.
Ask
Google
to
make
sure
that
that's
true,
it
verifies
that
the
public
key
is,
is
the
one
that
you're
assigning
with
or
is
it
the
companion
of
the
private
key
that
you're
signing
with
by
checking
the
signed
identity?
And
then
it
issues
you
the
certificate?
A
So
in
this
certificate
you
can
see
there's
the
public
key
and
then
there's
a
bunch
of
information
that
full
Co
ads
in
there's
the
subject
or
the
like
the
identity
that
we
are
claiming.
There's
the
issuer
who's
the
authority
that
is
attesting
to
that
identity.
So,
if
you're
writing
policy
on
this,
you
can
say:
hey
I,
trust,
facebook.com,
but
I.
Don't
trust
face
bake.com,
that's
not
a
trustable
oidc
provider,
even
if
they
claim
to
have
like
your
username,
it
has
a
short
validity
period.
A
A
Where
do
I
store
my
keys
so
we're
not
actually
storing
any
keys
in
keyless
signing.
We
use
ephemeral
Keys,
we
don't
care
about
long-term,
private
key
storage,
so
we
put
the
public
key
in
the
signing
certificate.
If
someone
wants
to
find
that
they
just
need
the
certificate,
the
private
key
will
use
the
sign
our
artifact,
we
obtain
a
signature
and
then
we
throw
it
in
the
trash.
A
A
A
We
use
recore
for
two
things
in
keyless
signing.
We
register
the
signing
time
with
the
transparency
log
because
we
have
short-lived
certificates
by
the
time
you
do
verification.
The
certificate
probably
is
expired.
So
you
need
something
to
tell
you
that
signing
happened
during
the
validity
period,
so
recore
kind
of
gives
you
a
time
stamp
and
says:
hey
yeah.
It
looks
like
a
signing.
A
Event
happened
in
that
10
minutes
that
things
are
valid
and
recore
is
open
and
allows
third
parties
to
monitor
an
art,
Monitor
and
audits,
signing
events,
and
this
is
helpful
to
kind
of
maintain
the
Integrity
of
the
log
like.
Not
only
do
you
have
to
trust
recore
I
mean
you,
don't
just
have
to
trust
recore,
you
can
say
hey
all
these
third
parties
have
checked
the
Integrity
of
the
log
and
it
seems
to
be
consistent
and
there
is
a
possibility
that
you
can
provide
services
to
users.
Like
you
can
say,
hey.
A
A
So
what
do
you
upload
to
recore
to
put
in
the
log?
We
don't
upload
artifacts,
we
only
upload
the
digest.
This
is
because
recore
is
not
storage
for
your
artifacts.
You
do
not
go
to
record
to
download
artifacts,
you
go
to
your
package
repository
or
your
release
bucket
or
whatever
Rico
Only
Stores
metadata,
so
it
stores
the
artifact
digest
the
signature
and
the
signing
certificate,
which
contains
your
public
key
and
all
this
other
identity
information.
A
So
you
send
it
over
to
recore.
Recore
verifies
the
signature
and
then
it
signs
and
enters
it
into
the
log.
This
log
entry
is
important
because
it
contains
the
timestamp
where
it
kind
of
observed
the
signing
event.
Recore
also
signs
all
this
information.
So
if
you
ever
get
this
log
entry
from
an
alternate
Source,
maybe
it's
stored
offline
instead
of
asking
recore
for
it.
Every
time
you
can
just
check
that
the
log
entry
was
signed
using
recourse,
private
key
recourse
public
key
again
is
distributed
with
tough.
A
A
The
signing
certificate,
you
can
also
distribute
the
log
entry
which
contains
the
timestamp
or
you
can
ask
recore
for
it.
Every
time
which
can
be
expensive
both
to
the
verifier
say.
Maven
Central
is
accepting
thousands
of
requests.
You
don't
want
to
have
to
hit
the
record
every
time,
but
this
the
entry
is
important
because
it
has
the
timestamp.
A
So
you
need
to
store
all
these
files.
It's
a
lot
of
files
to
add
to
your
Maven
release.
We
already
have
a
lot
of
files.
We
have
sources
and
javadoc
and
pom,
and
we're
trying
to
put
this
all
together
in
one
single
metadata
file,
but
that's
not
quite
ready
yet
so,
let's
just
keep
going.
So
how
do
you
actually
audit
a
monitor
since
the
Merkle
Tree
is
open?
You
can
take
your
binoculars
and
look
at
it
like
this
man
here
there
are
currently
only
two
kind
of
working
monitors.
A
There's
one
from
Purdue
University
and
one
from
trust
fabric.
The
space
isn't
fully
explored.
You
know,
six
door
is
always
accepting
contributors,
so
this
is
a
space.
That's
interesting
to
you,
we'd
love
to
have
you
we'd.
Also
love
to
have
you
work
on
six
door
Java.
This
is
a
Java
conference
with
Java
experts.
A
So
let's
move
on
from
there.
So
that's
a
lot
of
things.
Do
I
have
to
do
this.
Every
time
I
sign
my
head
is
going
to
explode
and
the
answer
is
no,
because
we
have
clients
and
the
clients
will
orchestrate
the
keyless
signing
workflow
for
you
and
they
integrate
into
the
tooling.
You
know
and
use
every
day
so
there's
clients
and
go
rust.
Javascript
Python
and
there's
the
six
storage
Java
client,
which
Patrick
and
I
work
on
this
is
the
best
one.
Let's
give
it
a
trophy.
A
And
six
for
Java
is
an
official
six
store
project
within
the
six-store
repository
we
did
a
early
release.
0.1.0
is
our
first
release
on
September
1st.
You
can
see
the
code
there.
It's
a
native,
Java
client.
You
don't
have
to
use
someone's,
go
binary
to
integrate
into
your
Java,
tooling,
its
general
purpose.
A
A
A
A
And
we
have
this
keyless
signer
object,
so
this
comes
from
the
six
store
Library,
it's
a
builder
and
we
have
six
door
public
defaults.
So
there's
six
store
public
infrastructure,
which
includes
a
full
Co
instance
and
a
recore
instance,
and
these
defaults
are
kind
of
baked
into
library
to
make
it
easier
to
use.
But
if
you
want
to
you
can
set
the
client,
you
can
set
the
oidc
client.
So
this
is
something
that
you
know
to
verify:
identity.
You
can
set
the
signing
mechanism
I!
Think
right!
A
A
A
So
let's
run
this
I
have
a
little
script
here.
That
just
runs
this
program
with
this
parameter
that
artifact
that
we
built.
So
let's
run
sign.sh
it's
going
to
bring
up
a
browser
window,
so
I
can
log
in
this
is
actually
the
Dex
oidc
provider.
That's
part
of
six
store
and
it's
just
a
proxated.
These
three
options
you
can
log
in
with
GitHub,
Google
or
Microsoft
I.
Don't
have
a
Microsoft
account
available
on
this
browser.
A
A
A
And
one
more
thing:
the
identity,
so
here's
my
email,
upload,
google.com
and
here
is
the
oidc
provider
so
accounts.google.com.
If
this
was
like
accounts.goggle.com,
you
probably
shouldn't
trust
it
and
then
there's
a
bunch
of
like
standard
certificate
information,
including
my
public
keys
in
here
somewhere.
A
The
bundle
contains
the
base64,
encoded,
Digest
certificate
and
sign
signature
and
then
a
bunch
of
like
log
information,
but
what's
important
to
us
right
now
is
the
integration
integrated
time.
So
this
is
the
timestamp
we're
using
to
verify
that
signing
event
indeed
was
registered
during
the
validity
period
of
the
certificate
so
GQ.
A
A
A
A
A
A
There's
the
public
key
and
then
the
signature
is
signature
and
then
the
artifact
that
we
want
to
verify
the
signature
of
so
here
it
says,
verified
okay,
which
is
not
a
lot
of
information,
but
that's
all
it
gives
us,
and
you
know
we
can
kind
of
make
sure
this
still
works.
Let's
put
bananas
and
check
the
verification,
it
says
verification
failure,
because
it's
not
it's
not
a
signature
for
that.
Artifact
foreign.
A
B
A
A
Artifact
into
a
digest
over
here
and
then
it
uses
the
kilos
verifier,
which
is
similar
to
the
keyless
signer
object
against
public
Sig
store,
and
then
here
we
have
a
simple
call
to
verify.
Online
verify
online
is
a
verification
that
requests
the
bundle
from
recore
instead
of
relying
on
the
one
on
the
disk.
A
So
this
accepts
a
digest,
a
sir
path
and
a
signature,
and
if
it
works,
it'll
print
verified
if
it
does
not
work,
it'll
print
stack,
Trace,
so
in
here
again,
I
have
like
a
little
script,
because
it's
hard
to
type
all
this.
It's
the
artifact,
the
signature
and
the
certificate
verify
and
similar
to
openssl.
It
just
says
verified.
If
we
want
to
let
go
miss
the
artifact
again.
A
We
can
try
verifying
and
it'll
print
keyless
verification,
so
it
says
record
entry
not
found
because
it
locally
generates
the
recore
entry
and
then
tries
to
find
it
on
the
log
and
then
obtain
all
the
information
it
needs.
We
could
probably
do
a
better
job
with
the
messaging
there,
so
this
is
just
the
raw
library,
but
you
know
this
is
not
what
you're
going
to
be
using
every
day.
You
want
to
use
my
vinegar,
Gradle
or
whatever
you're
using.
So
let's
go
to
the
maven
demo.
A
So
in
this
demo
we
have
a
simple
movement
program
that
doesn't
do
anything
and
you'll
see
here.
I
have
this
alt
deployment
repository.
This
is
just
a
local
local
directory.
So
when
I
do
Maven
deploy,
I
can
show
up
locally
instead
of
having
to
go
to
so1.osss,
that's
sonotype.org
and
log
in
and
who
knows
here,
I'm
using
a
snapshot
because
I
made
one
slight
modification
for
the
demo,
but
this
should
work
as
normal
I'm,
ignoring
pgp
signatures,
because
this
laptop
is
new
and
I.
A
A
A
B
A
A
B
B
B
It's
I,
don't
know
if
you've
heard
of
the
open
ssf,
but
it's
a
an
organization
dedicated
to
software
Security
in
open
source
and
yeah.
It's
one
of
the
top
25
Linux
Foundation
projects
and
we've
only
been
around
for
a
couple
of
years.
So
that's
pretty
impressive.
It's
got
1400
members
on
slack.
We
have
regular
Community
meetings
with
maintainers
of
various
ecosystems,
including
python
Ruby,
node
Java.
B
It
does
include
a
bunch
of
projects
like
cos.
The
cosine
CLI
six-store,
like
various
client
libraries,
as
well
as
infrastructure
repos
for
actually
operating
the
services,
which
brings
us
to
kind
of
a
unique
aspect
of
six
door
that
that
we
we
actually
operate
a
bunch
of
Production
Services,
it's
kind
of
similar
to
a
package
manager,
but
we
do
it
kind
of
in
a
Consortium
of
of
members
of
the
open
ssf.
B
B
B
What
we're
working
on
well
there's
about
two
minutes:
okay,
what
we're
working
on
we're
working
on
a
ga,
that's
going
to
be
announced
really
soon.
At
that
point,
we'll
have
24
7.
on
call
and
we
will
be
I
think
we're
already
meeting
our
SLA
a
better
signature
bundle.
You
saw
in
the
examples
that
were
there
were
multiple
files
and
that
there's
kind
of
a
Babushka
doll
of
base64
in
there
and
we're
improving
that
significantly
we're
gonna
have
one
signature
bundle
and
it's
going
to
enable
offline
verification
as
well.
B
Using
the
tough
routes
that
are
bundled
with
the
client,
secular,
tough
client
is
incomplete,
so
working
on
that
six
foot,
Java,
Maven
and
Gradle.
Getting
those
to
1.0
are
a
big
priorities
for
us.
Maven
Central,
like
adopting
six
door,
is
also
a
huge
priority
for
us,
if
you're,
not
so
they're
going
to
do
it
and
ultimately
I
think
it's
up
to
us
to
make
it
work
for
them.
First
in
provenance,
generators
which,
if
you're
curious
about
Providence,
I,
highly,
encourage
you
to
check
out
the
salsa
or
slsa
project.
B
Join
us,
if
you're
into
making
Java
a
safe
ecosystem
to
use,
especially
making
open
source
viable
I
know
it's
already
viable,
but
it
needs
to
be
safe
and
all
these
compromises
are
kind
of
challenging
the
open
source
community
and
the
adoption
of
Open
Source
60.
Dev
is
a
great
website
where
you
can
find
out
about
us
github.com
stores,
where
we
do
all
our
work.
You
can
find
all
our
projects
there
you
can.
If
you
go
to
github.com
store
Community,
you
can
find
a
slack
invite
to
become
part
of
our
slack
community.