►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: TUF/Notary - Justin Cappos, NYU & Justin Cormack, Docker
Software distribution and packaging systems are rapidly becoming the weak link in the software lifecycle. This talk provides an accessible overview of two CNCF projects (Notary and TUF), that provide what has been roundly described as the most secure mechanism for distributing software. Notary, which implements the TUF specification, signs and transparently validates metadata to enable the system to recover from the compromise of servers, theft of keys, insider attacks, etc. Notary / TUF are surprisingly easy to use and used to provide cutting edge security not only across major cloud companies, but a diverse set of adopters, including automobiles. WARNING: Attending this talk may cause (justifiable) fear in the software update mechanism on your devices!
To Learn More: https://sched.co/GrbG
B
A
And
Tufton
notary
just
super
quick,
tough
as
a
specification
for
how
to
do
updates
and
things
securely.
That's
used
in
a
lot
of
different
domains
and
the
main
implementation
that's
used
in
the
cloud
is
notary,
which
is
what
Justin,
Cormac
and
others
a
doctor
did.
So
what
I'm
going
to
be
doing
is
I'll,
start
off
and
tell
you
a
little
bit.
A
Tell
you
a
little
bit
about
tough
and
things
like
that
itself
and
then
we'll
hand
over
a
little
later
on
and
just
in
Cormack
will
show
you
some
cool
demos
and
things
like
that,
all
right.
So
let's
go
ahead
and
get
started.
So
since
I'm,
a
professor
one
of
the
things
that
I
get
to
do
is
I
get
to
give
like
pop
quizzes
right.
It's
one
of
these,
like
kind
of
Rights
that
you
get
along
with.
A
You
know
how
they
issue
you,
the
tweed
jacket
with
like
the
elbow
patches
and
the
pipe,
and
all
that
so
there's
an
attack
vector
that's
used
by
hackers
all
around
the
world.
It
bypasses
network
defenses
like
firewalls,
and
things
like
this
it
you
can
use
it
to
hack,
basically
anything
any
type
of
device,
everything
from
cloud
system
supercomputers,
you
know,
phones,
you
can
use
it
to
hack
little
embedded
devices
cars
like
just
any
of
any
device.
A
You
can
imagine-
and
it's
already
been
used
many
many
many
times
by
the
best
hackers
in
the
world
when
they
want
to
go
and
launch
an
attack
against
actually
an
adversary.
That's
supposed
to
have
good
defenses.
So
anybody
know
what
this
attack
vector
is.
Yes,
it's
not
weak
passwords.
It's
not
people!
It's
updaters,
software
updates.
So
when
you
look
at
it-
and
you
look
historically
at
attacks
that,
if
that
have
happened
for
nation-state
actors
going
after
this,
how
did
allegedly
the
United,
States
and
allegedly
Israel
take
down
the
centrifuges
in
Iran
attacks?
A
The
software
update
mechanism?
How
did
allegedly
Russia
go
and
you
know,
mess
around
an
Emmy
doc
and
bring
down
90%
of
the
companies
in
Ukrainian
cause
a
lot
of
collateral
damage.
Software
update
based
attacks,
how
did
North
Korea
go
and
launch
attacks
on
South
Korea
and
cost
three-quarters
of
a
billion
dollars
of
damage?
A
A
But
if
you
can
just
get
into
their
software
update
infrastructure,
you've
won.
That's
it
all
right.
So
when
some
people
start
to
look
at
this,
they
just
say.
Oh,
but
it's
you
know,
it's
easy.
You
just
sign
things
and
everything
just
works.
Just
like
hey,
you
know:
I
have
a
lock
for
my
bike,
so
I
just
put
the
lock
around
the
bike
and
I,
attach
it
to
something
and
everything's
good
right,
but
that
you
know
that
isn't
actually,
unfortunately,
how
how
things
work
in
the
in
the
first
case.
A
It
isn't
that
for
the
companies
here
it
isn't
that
they
didn't
have
crypto.
So
they
had
they
weren't
doing
the
right
things
with
their
crypto.
They
weren't
protecting
against
the
right
types
of
attacks.
They
weren't
signing
the
right
things,
protecting
keys
in
the
appropriate
way
and
making
it
so
that
they
could
recover.
If
something
went
wrong,
so
does
a
simple
solution:
work.
Could
we
just
you
know,
go
and
you
know,
make
everybody
retrieve
things
over
HTTPS
and
is
that
just
a
solution?
A
So
all
that
this
is
doing,
whether
you
have
pinned
your
certificates
or
whether
you
have
this
plugged
into
the
main
ta
system
is
at
best
it's
saying
you're
talking
to
the
right
server,
okay,
but
it
doesn't
say
that
if
that
server
is
compromised,
that
your
clients
are
safe,
so
if
you
break
into
the
server,
then
all
your
comp,
all
your
clients,
are
now
under
the
control,
the
attacker
potentially.
So
this
is
one
way
some
organizations
have
been
hacked.
A
This
is
to
have
every
developer,
go
and
have
keys,
and
then,
oh,
you
know
well,
it
has
to
be
signed
by
a
developer,
but
then
it
turns
out
that
you
usually
end
up
with,
like
100
plus
developers
that
all
have
the
ability
to
do
this,
because
the
person
who
needs
to
push
the
polish
language
pack
has
to
have
the
ability
to
sign
this
and
so
he's
trusted
to
push
changes
to
the
root
colonel
or
to
the
to
the
colonel.
The
system
Linux
kernel
other
things
like
that.
A
A
Well,
that
will
get
you
on
that
first
page,
as
well
as
as
a
lot
of
the
companies
they're
found,
because
really
then
all
that
has
to
happen
is
someone
can
get
into
your
build
server
and
give
you
something
malicious,
that
you
then
trust
and
sign
and
get
out
there
so
keeping
your
key,
even
if
they
can't
exfiltrate
your
key.
It
doesn't
matter
if
they
can
use
your
key
to
sign
something
malicious,
that's
good
enough
like
who
cares
if
they
could,
you
know
if
they
take
the
key
away?
A
A
Looking
at
security
issues
with
Linux
package
managers
and
some
folks
from
the
Tor
project
read
about
my
work
and
said
our
tour
updater
has
a
lot
of
these
issues
too,
so
they
came
out
and
they
spent
a
few
days
with
me
when
I
was
at
the
University
of
Washington
and
we
jotted
out
rough
design.
They
went
away
and
did
a
design
and
asked
me
and
an
undergraduate
who
I
was
working
with
to
look
at
it
and
we
found
like
seven
serious
security
problems
in
their
design.
So
we
said,
wait
a
minute.
A
You
know
we
can't
just
kind
of
right.
You
know
be
an
academic
and
write
a
paper
and
say
you
need
to
do
these
things.
We
have
to
actually
provide
a
better
way
forward,
so
what
we
did
instead
is
to
come
up
with
a
specification
and
a
reference,
implementation
and
things
that
describe
exactly
how
to
do
updates
in
a
secure
way
across
a
very
wide
variety
of
domains,
and
that's
what
tough
is
all
about.
So
the
goal
of
tough
is
to
be
compromise
resilient.
A
So
this
means
that
an
attacker
goes
and
breaks
into
part
of
your
infrastructure,
and
it
doesn't
mean
that
they
sort
of
have
access
to
everything.
It's
not
like
a
single
server
that
fails
or
a
single
key,
that's
lost.
You
have
to
have
sort
of
a
bunch
of
issues
come
together
to
have
a
serious
impact
of
user.
So
someone
breaks
in
your
server,
your
clients
are
still
okay.
A
A
You
know:
thou
shalt
only
like
have
an
infrastructure
that
looks
the
way
we
say
with
Brand
X
servers
that
are
running
brand
Y
operating
system
and
using
brands
e
crypto
tough
is
instead
describing
like
the
MEK,
the
the
way
in
which
you
need
to
go
through
to
build
and
set
things
up
and
configure
it,
and
one
of
the
things
that
you'll
you'll
hear
about
a
little
bit
later.
Here
is
a
way
that
docker
started.
A
If
you
come
to
the
deep
dive,
you'll
learn
more
about
how
other
companies
like
data,
dog
and
automotive,
vendors
and
others
that
are
using
tough,
have
deployed
it
in
fairly
different
ways
that
all
still
comply
with
the
spec
and
I'll
still
get
the
same
security
guarantees
all
right.
So
in
order
you
know
tough
itself.
The
easiest
way
I
find
to
explain
it
to
people
rather
than
talking
really
technically
about
like
how
what
the
metadata
format
looks
like
or
any
of
those
types
of
things.
I
want
to
talk.
A
First
about
the
design
principles,
the
things
that
went
into
tough,
the
concepts
that
tough
uses
to
make
it
have
security.
So
you
can
understand
at
that
level,
and
then
you
know
we
can
talk
about
things
like
what
do
the
file
like?
What's
the
file
format
look
like
and
how
do
signatures
work
and
things
like
that
so
responsibilities,
separation?
This
is
a
concept
where
what
you
do
is
you
have
different
roles
that
are
trusted
to
do
different
things,
and
so
a
role
might
be
trusted
only
to
do
things
like
say.
A
Has
there
been
an
update
in
the
last
few
hours?
That's
the
only
thing
the
role
is
trusted
to
do
is
to
say
yes,
there's
been
an
update
or
no,
there
hasn't
been
an
update
right,
and
so,
if
an
attacker
can
go
and
compromise
that
role,
that
is
a
very
different
impact
than
a
role.
That's
allowed
to
do
things
like
sign
a
release
of
a
package,
so
you
know
there's
different
roles
that
have
different
responsibilities
in
the
system
and
in
fact
that's
example,
I
just
gave
here.
A
So
let
me
skip
that
and
then
another
thing
to
focus
on
in
tough
is
is
that
if
you
think
about
the
damage
you
can
have
from
a
compromise
in
a
system
the
damage
is
roughly,
you
know
the
probability
of
that
compromise
occurring
times
the
impact
of
that
compromise.
So
if
you
have
you
know
so,
for
instance,
it's
very
unlikely
that
a
massive
meteor
is
going
to
go
and
crash
into
the
earth
in
the
middle
of
this
talk
right,
very,
very
unlikely
at
least
I
hope,
and
but
the
impact
would
be
massive
like
this
would
be.
C
A
Throw
me
off
my
off
my
game
for
a
slide,
or
two
at
least
so,
but
the
expected
damage
from
that
is
vanishingly
small,
because
the
probability
is
very
small,
but
the
chance
that,
like
my
mouth
is
gonna
get
dry
and
I
really
find
I
need.
Some
water,
you
know
is,
is
probably
pretty
probable,
but
the
impact
of
that
is
pretty
low,
I,
just
maybe
sound
a
little
Croker
than
I
should
as
I
give
my
talk
right,
so
you
want
to
make
it
so
that
you
know
things
that
are
likely
to
happen.
A
Keys
that
are
likely
to
be
compromised
in
tough
are
unlikely
to
cause
any
substantial
damage
when
compromising
keys.
That
would
cause
substantial
damage
are
very
unlikely
to
be
compromised.
Talk
about
how
that
works
in
a
moment.
So,
for
instance,
we
have
a
roll
called
the
root
roll.
The
root
roll
is
sort
of
the
the
root
of
all
trust
in
the
system,
and
usually
this
isn't
a
single
key.
In
fact,
I'm
not
aware
of
a
tough
deployment
model
that
that
uses
a
you
know
that
uses
this.
A
It's
basically
organizations
go
and
they
have
a
collection
of
UV
keys
or
other
things
like
this.
They
keep
in
safety,
deposit
boxes
and
you
have
to
you
know
an
attacker
would
have
to
Mission
Impossible
style
break
into
you
know
like
three
or
four
safes,
all
at
once,
spread
around
the
world
and
then
get
those
keys
out
in
order
to
be
able
to
to
you
know
to
compromise
the
route
role,
whereas
you
have
a
key
like
this
time.
You
know
this,
this
roll
that
tells
you
has
there
been
an
update
in
the
last
hour.
A
Well,
that
key
is
gonna,
be
kept
on
a
server
for
sure
it's
it's
gonna
be
there.
It
might
maybe
isn't
an
HSM
or
something,
but
it's
still
gonna
be
in
a
server.
That's
online
and
stills
vulnerable
to
an
attack.
So
if
someone's
able
to
compromise
that
key,
then
they
can
lie
and
say:
oh
there
hasn't
been
an
update
when
maybe
there
has
been
one.
There
was
an
update,
you
know
an
hour
ago,
but
you
can
say
no,
no,
no,
there
hasn't
been
one
okay,
but
that
impact
is
much
less
than
being
able
to
route.
A
All
of
the
users
tough,
also
supports
multiple
signatures.
You
can
have
threshold,
so
you
can
say
that
some
number,
you
know,
T
of
n,
for
whatever
values
of
Tina
and
you
like
I
required
for
trust.
You
can
say
one
of
three.
You
can
say
you
know
nine
out
of
ten,
whatever
makes
sense
for
your
domain,
and
you
can
use
this
in
lots
of
different
places.
So
you
don't
have
to
have
a
single
person
just
like
now,
you
have
the
two
keys
in
the
submarine
that
have
to
be
turned
together.
A
You
set
it
up
for
whatever
makes
sense
for
your
environment
depending
on
how
forgetful
your
users
are,
how
often
they
lose
their
keys
and
how
secure
you
need
to
be
right,
so
I'll
just
go
and
ski
yep
so
and
then
one
thing
that
I
think
you
see
very
common
across
security
systems.
That
is
really
a
telling
thing
about
how
secure
like
how
much
you
should
trust
the
system
is.
How
much
did
people
spend
thinking
about?
Revocation?
A
How
much
did
they
spend
thinking
about
what
happened
when
things
go
wrong?
Okay,
because
there's
there
are
a
ton
of
systems
out
there.
That
sort
of
after
the
fact
someone
said,
oh
yeah,
we
need
to
think
about
this
revocation
problem
that
we
need
to
think
a
lot
harder
than
we
have
been,
but
in
practice,
whether
it's
people
losing
keys
accidentally,
disclosing
key
material
hackers
breaking
in
these
things
happen
right.
So,
if
you're
going
to
have
a
system,
that's
secure.
You
need
to
think
very
carefully
about
that.
So
tough
today
has
two
mechanisms.
Explicit
and
implicit.
A
Revocation
explicit,
revocation
is
the
mechanism
by
which
you
can
go
and
say
like
effectively.
This
key
isn't
trusted
anymore
instead,
trust
another
key,
implicit
revocation
is
a
way
of
saying
that
this
key
will
expire
after
this
date.
So
it's
a
way
of
making
it.
Even
if
you
have
situations
where
you
know
you're
being
blocked
from
receiving
updates
and
by
the
way
this
does
happen
in
some
countries
with
oppressive
regimes,
they
stop
their
users
from
getting
updates.
So
they
can
more
easily
compromise
those
users.
A
A
All
right,
so
tough
itself
has
four
different
roles:
there's
the
root
role
that
serves
as
the
root
of
trust
and
indicates
keys
for
all
the
other
roles.
There's
a
rule
called
the
targets
role
or
the
project's
role
that
goes
and
delegates
in
you
know
it
delegates
to
the
actual
things
you
want
to
install.
So
whether
this
is
software
images
or
packages
or
whether
this
is
something
like
disk
images
for
embedded
devices
whatever
else
it
actually
points
to
those
and
targets
roles
by
the
way
can
further
sub
delegate
out
to
others.
A
So
you
don't
have
to
kind
of
have
one
big
signing
role.
You
can
break
it
down
and
say:
Joe
is
able
to
you
know
there
are
these.
You
know
there's
this
role
for
this
piece
of
software
that
we
produce
with
this
name,
and
this
piece
of
software
can
be
built
by
Joe
and
Sam
and
Sally
and
stuff
like
that,
and
then,
when
Sam
rotates
out,
you
can
replace
Sam
with
Alice
or
whoever
the
new
person
is,
and
they
can't
go
in.
A
You
know
then
pushed
the
Linux
kernel
if
that's
not
part
of
what
they're
supposed
to
be
signing
for.
There's
a
roll
called
snapshot
which
I
can
talk
in
more
detail
about,
but
it
basically
I
will
talk
a
little
more
about
in
the
deep
dive,
but
basically
it
makes
sure
that
no
one
is
kind
of
cherry-picking
pieces
of
metadata
out
of
a
repository.
One
of
the
things
that
I
did
in
some
of
the
early
work
I
did
with
package
manager.
A
Security
was
I,
found
ways
to
convince
clients
that
any
because,
if
somebody
signs
something
they've
signed
it
and
people
don't
rotate
their
keys.
That
often
so
I
found
you
could
take
like
a
four
year
old
version
of
send
mail
and
give
it
to
clients,
and
they
would
think
it
was
like
up-to-date
or
give
them
really
outdated.
Things
like
that,
which
is
really
bad,
so
snapshot
in
tough,
protects
against
that.
It
makes
it
so
that
that
sort
of
issues
can't
occur
and
timestamp
goes
and
determines
when
updates
have
occurred.
A
So
tough
is
used
in
practice
by
a
lot
of
different
groups.
You
can
see
you
know
once
again.
The
company
logo
slide
that
everybody
seems
to
love
to
have
and
one
way
that
we
go
and
we
build
and
we
improve
things
with
tough
is
not
only
through
a
reference
implementation
which
is
used
in
production,
but
is
only
probably
used
in
production
by
maybe
10%
of
the
devices
that
run
tough
in
the
world.
A
C
Yeah,
I'm
I
can
took
by
nature
I'm,
mostly
gonna,
show
you
what
it's
like
to
use
no
tree
as
a
tool
on
its
own,
but
a
bit
of
background.
So
nature
is
a
tough
implementation
that
we
originated
at
docker,
free
off,
three
I
think
and
we
launched
three
years
ago
now
and
it's
written
in
go.
It
has
a
lot
of
maintenance
from
different
companies,
and
it's
basically
designed
I
mean
the
use
case
for
which
docker
built
it
was
to
run
it
at
scale
in
conjunction
with
registry.
C
So
we
run
it
alongside
docker
hub
as
a
public
notary
instance.
Anyone
can
use
for
signing
containers
on
docker
hub,
and
so
so
it's
designed
for
that
kind
of
use
case,
but
it's
in
fact
built
as
a
you
know,
just
to
go
tough
library
that
you
can
use
for
other
use
cases
as
well.
So
it's
it's
pretty
reusable
code.
If
you,
if
you
want
to
do
something
different
with
it,
it's
basically
designed
around
because
it's
designed
to
run
at
scale
it's
it's.
C
C
If
you
and
and
though
you
can
basically
replicate
both
the
SONA
and
servers
they're,
all
there
states
in
the
database
and
then
you
can,
you
can
use
a
scale
out
database,
a
layer
as
well
to
serve
those
so
I'm,
really
just
going
to
show
you
what
it's
like
to
kind
of
run
it
on
your
I'm.
Just
gonna
run
it
on
my
laptop
we're.
Just
gonna
write,
use,
docker
compose
to
bring
it
up
and
I'm
going
to
basically
just.
C
Is
it
yeah
once
that's,
come
up,
I'll
just
switch
this
oops
other
tab
and
then
I'll.
Just
that's
a
I
got
nice
and
big
I,
just
refinished
that
looks
like
everything
might
be
a
yes
yeah,
so
so
we're
just
going
to
basically
do
a
kind
of
really
really
really
simple
demo
of
just
putting
some
stuff
here
and
so
notary
divides
things
into
repositories.
C
So
we're
going
to
create
a
repository
called
test,
and
this
is
going
to
helpfully
tell
us
that
I'm
just
going
to
use
this
to
can't
pay
the
same
password
for
everything
I'm
not
going
to
use
a
secure,
password,
I'm,
just
gonna
use
one
that
you
can
all
read
so
so
this
is
the
route
the
route
signing
key,
which
I'm
just
doing
locally
I'm,
not
using
a?
U
P
key
or
anything.
C
So
it's
kind
of
going
to
be
on
my
disk
I'm,
just
gonna,
give
it
a
real
password
and
then
we're
going
to
create
all
the
other
keys
with
the
same
password.
So
it's
easier
to
do.
The
demo
is
notice
that
there's
no
timestamp
key
here,
because
notary
always
manages
the
timestamps
itself
and
we're
going
to.
We
can
just
naturally
the
notary
tool
itself
has
a
model
where
you
staged
things
locally
and
then
publish
them.
So
we
can.
We
can
publish
tests
up
to
the
up
to
the
actual
server.
C
We
have
to
give
our
passwords
for
the
keys
because
the
keys
are
encrypted
and
then
we've
basically
just
created
an
empty
repository,
no
targets
very
straightforward.
So
let's
I've
got
a
couple
of
files
here:
I'm
just
gonna
I'm,
going
to
add
file
to
test
and
to
as
I'm
gonna
call
this
v1
perversion,
one
oops.
C
C
We
can
also
just
use
this
to
verify
that
this
trial,
so
we
can
basically
ask
notary
to
test
whether
this
file
is
in
fact
the
file
that
we
pushed
and
it
just
passes
through.
But
if
we
notice
that
notary
doesn't
itself
actually
store
the
actual
file
data
at
all,
that's
expecting
you
to
put
it
in
a
registry
or
some
other
storage.
So
nursery
is
just
it's
just.
Basically,
it's
basically
just
going
to
check
against
the
file
that
we've
got
locally,
which
was
the
same
one.
If
I
modify
this
file,
it
will
tell
me
no.
C
C
And
I've
got
a
couple
of
queries
say
it
said
this.
This
query
select
all
the
all
the
files
have
been
stored
and
you
can
see
that
we've
got
the
different
roles
and
each
of
them
has
a
version.
So
every
time
we
push
an
update,
we've
updated
these,
so
we
can
go
and
look,
for
example,
inside
version
3
of
the
targets,
and
we
can
look
at
the.
C
C
If
you
use
it
directly
all
the
kind
of
configuration
of
which
hashes
and
signatures
you
actually
use
as
all
Feli,
all
fairly
configurable
in
the
code,
if
you
want
to
use
different
types
of
types
of
signatures
and
so
on,
and
then
we've
got
the
signatures
on
on
this
on
this
blob
as
well.
So
you
can
see
it's
been
signed
by
this
particular
key
ID,
and
if
we
look
at
the
root
role
here,
we
can
go
and
see
all
the
what
all
the
different
key
IDs
are
again
every
father
signed.
C
So
you
can
validate
that
file.
If
you
download
it
and
then
you
can
see
these
are
all
the
different
keys,
and
here
it
tells
us
what
the
what
the,
what
which
role
each
key
that's
listed
here
has
and
then
we
can
go
and
we
can
rotate
keys
by
hand.
So
we
can
there's
two
options:
when
real
rotation
Keys,
we
can
either
you've
used
the
minus
R
option.
That
says
this
is
a
remote
key.
C
This
is
not
stored
locally,
but
I
want
to
rotate
the
timestamp
key,
that's
on
the
server,
and
we
need
to
obviously
give
the
passphrase
for
our
root
key
so
that
we
can
update
that
and
the
snapshot
key,
and
then
it
will
have
rotated
the
timestamp
key.
And
if
we
refresh
this,
we
you
can
see,
we've
got
a
new
timestamp
roll
has
been
created.
All
the
other
roles
are
still
in
the
database
and
they
get
stored.
So
you
can,
you
can
and
you
can
retrieve
them
by
their
hash
as
well,
depending
on
from
the
content
hash.
C
C
I'm
weak
yeah
and
we
can
rotate
all
the
keys,
so
we
can
rotate
the
we
can
write
the
route
rotate
the
route
key.
This
is
I
got
an.
Are
you
sure
warning
on
it
bit
on
the
command
line,
because
it's
that
is
not
something
you
want
to
do
very
often,
and
then
we
can,
but
we
can
enter
the
passphrase
for
the
new
route
key
and
we
need
to
update
it.
C
C
You
can
also
reach
you,
it's
no,
sir,
just
so
there's
very
straightforward,
REST
API,
so
we
can
go
and
if
we
have
the
right
certs,
we
can
just
go
and
retrieve
these
all
this
directly
from
using
the
REST
API
yeah
when
the
by
default.
What
there's?
No
you
could
just
run
notary
on
its
own,
isn't
have
any
authorization
it
would
normally
if
you're
running
it.
C
C
C
That's
the
actual
sha-256
hash
and
we
can
retrieve
it
was
a
snapshot
key.
So
that
was
sorry.
That
was
the
target
key
and
we
can
retrieve
that
particular
version
of
the
target
tricks.
So
that's
that's
the
way.
So
if
you
know
the
hash
of
the
the
JSON
file,
you
can
actually
retrieve
directly
specific
versions,
so
you
can
get
it,
you
can
get
the
consistence
now
shot,
and
so
this
is
the
particularly
profession
that
that
was
pointing
at
so
and
that's
as
we
can,
we
can
add
in
we
can
add
in
more
files.
C
C
We
can
also
do
things
that
we
can
ask
notary
to
rotate
the
we
can
ask
notary
to
manage
the
snapshot
keys
as
well,
so
we
didn't
have
to
put
them
in
every
time.
So
we
can,
we
can
tell
it.
We
want
remote
snapshot
keys
instead
of
managing
them
ourselves
and
and
so
there
so
which
is
actually
the
default
on
docker
hub
now.
So
if
we
then
had
had
more
things,
we
basically
will
only
be
asked
oops,
we'll
only
be
asked
for
the
targets
key
and
we
won't
be
asked
for
the
snapshot
key
anymore.
C
So
now
that
note
research
emerged
in
the
snapshot
key,
which
is
what
we
do
on
docker
hub.
So
it's
not
the
ability
that
you
can
decide
which
keys
you
want
to.
You
want
to
be
automatically
managed
by
the
notary
server
and
which
ones
you
want
to
manage
locally,
but
the
time
stamp
key
is
always
managed
on
the
server.
With,
with
current
nature,
we
set
up.
A
C
A
Wait
yeah
and
the
targets
you
often
have
a
hierarchy
of
targets
keys
in
there.
The
roles
that
are
are
further
up.
The
hierarchy
are
not
needed
unless,
for
instance,
you
change
the
developers
that
are
allowed
to
release
something
or
you
add
a
new
project,
you're
gonna
release
or
something
like
that,
and
then
you
use
it
once.
A
So
let
me
just
wrap
up
one
quick
second
and
we'll
get
right
to
your
question.
So,
if
you're
interested
in
finding
out
more
about
tough
and
notary,
we
have
a
deep
dive
on
Thursday.
It
also
is
gonna
discuss,
supply
chain
attacks
like
how
to
stop
people
that
go
and
tamper
with
your
git
repository
or
get
into
your
build
system,
or
do
other
things
like
this,
and
if
you
want
to
find
more
information,
you
can
find
us
in
github.com
at
slash
the
update
framework
and
our
email
addresses
are
here.
A
Right
so
the
question
is:
is
that
is
there
any
kind
of
integration
that's
done
with
Jenkins
bamboo
or
CI
CD
pipelines?
So
we
actually
for
the
its
supply
chain,
security
stuff.
We
actually
have
an
official
Jenkins
plug-in
that
works
as
part
of
that
and
you
can't
go
and
trivially
integrate
any
of
the
stuff
that
that
we're
doing
here
into
whatever
your
pipeline
is
tough
and
notary
kind
of
work.
A
At
the
point
where
your
software
is
already
made
and
has
come
out
of
something
like
a
CI
CD
system,
and
then
they
take
it
that
last
mile
securely
and
make
sure
nothing
happens.
So
the
things
you
know,
the
CI
CD
system,
usually
like
the
output
of
that
is
the
input
into
toughened
notary.
But
if
you
want
something
more
holistic
then
come
to
the
deep
dive
event
and
you
learn
more.
C
From
from
Dockers
point
of
view,
all
this
notary
stuff
is
totally
hidden
inside
Darko
we've
now
got
a
whole
set
of
separate
docker
commands
called
docker
trust
which
you
can
manage
all
the
notary
stuff
for
and,
and
so
none
of
this
is
really
visible
for
a
doc.
If
you're,
if
you're
just
joining,
you
know
if
you're
just
signing
containers
and
things
like
that,
it's
you
don't
need
to
you.
C
Don't
really
need
to
understand
all
the
details
of
how
this
works
internally,
it's
all
kind
of
integrated
into
the
registry
and
where
we
and
we
yeah
we
certainly
we
have
Jenkins
integration
for
signing
and
the
containers
that
we
build
and
so
on,
and
the
and
all
the
docker
official
containers
are
all
signed
and
so
on.
So
that's
all
there's
all
integration
with
docker,
rather
than
with
notary
and
tap
directly
and
we've
for
most
purposes.
You
want
to
try
and
integrate
it
at
a
level
where
it's
not
100%,
visible
to
users,
I
think
in.
A
Fact,
I
often
don't
know
who's
using
tough,
sometimes
I
find
out
because
they
had
an
attack
and
tough
perfect
prevented
the
attack.
And
then
it's
like
oh
hey,
cool.
Now
we
can
add
them
to
our
adopters
page,
but
we
had
no
idea
ahead
of
time
for
that.
So,
if
you
are
using
it,
please
tell
me
like
I'd
like
to
like
put
your
company
logo
up
there
and
say
awesome
things
about
you.
So
just
just
let
us
know.
A
C
A
A
A
Okay,
yeah,
it's
a
great
question,
so
the
question
is:
is
that
what
do
you
do
about
situations
where
you
have
a
device,
that's
going
to
be
connected
and
then
maybe
offline
for
a
while
and
then
be
connected
again
like,
for
instance,
a
submarine
or
maybe
a
car?
Maybe
you
go
in
your
park,
your
car,
car
and
storage
for
a
while
and
don't
turn
it
on,
or
things
like
that.
A
How
do
you
deal
with
that
because
maybe
this
timestamp
key
has
been
rotated
so
Institute.
So
the
answer
to
that
is
is
that
in
situations
where
you
go
and
you
do
that
update
you
actually,
once
you
see
something
doesn't
match
with
your
timestamp
role:
you'll
go
and
retrieve
the
root
and
the
root
roll
will
have
a
chain
of
trust
from
the
rule
you
trusted
of
signatures
to
the
new
one
and
that
new
root
rule
will
point
to
the
new
time
stamp.
A
Right,
okay,
so
the
question
is:
is
that
now,
if
we
modify
the
example
that
before
you
go
underwater,
you've
prefetched
the
information,
yet
you
know
so
you
have
like
effectively
a
copy
of
the
repository,
a
copy
of
the
things
you
might
want
install,
but
you
have
decided
not
to
install
them
yet
you're
going
to
do
so
later.
Then
what
happens?
How
does
this
work?
C
C
A
So
there's
so
in
different
implementations
of
tuffets
handled
a
little
bit
differently
for
how
it
warns
you
and
whether
you
have
to
put
a
yes,
yes,
I,
really
know
what
I'm
doing
flag
or
something
like
that,
but
in
general,
if
you're
not
able
to
go
and
contact
the
server
and
do
things
like
that,
then
the
implementations
I'm
aware
of
have
a
mechanism
to
let
you
go
and
handle
the
submarine
case.
Yes,.
A
Yep,
okay,
so
the
question
is:
is
that
let's
say
your
offline
and
then
a
replication
happens?
What
what
is
the
what's
gonna
happen
to
the
client?
Hey,
you
know
what
are
the
concern
you
should
have?
If
a
revocation
happens,
then
you
obviously
won't
know
about
it
right
and
if
you're
telling
it.
This
is
the
danger
of
the
submarine
case.
Saying
yes
go
ahead
and
use
this,
but
but
hopefully
what
has
happened
at
that
point?
Is
you
got
a
good
set
of
information
that
hadn't
been
tampered
with?
A
C
A
C
C
What's
the
status
for
HSMs
in
nursery,
so
on
the
client
side,
we
suppose
you
be
key
and
because
yes
11
for
a
long
time
on
the
server
side,
there's
some
open
PR
in
progress
which
and
we
there's
yeah-
we've-
definitely
seen
a
lot
more
demand
for
doing
server-side
stuff
with
HSM.
So
that's
kind
of
a
progress
IBM
I've
been
working
on
it.
A
Yeah
and
the
reference
implementation
has
Yubikey
support
on
the
client
side
and
I
forget
what
we
have
on
the
server
side.
We
have
yeah,
but
we
we
also
and
other
people
that
are
building
and
are
also
building
the
support
in.
But
it's
not
universe.
It's
not
like
mandated
by
the
spec
that
you
have
to
support
these
HSMs
or
something
any
other
questions.
A
A
So
the
question
is:
how
do
you
learn
about
revocations?
Do
we
use
a
CSP
or
something
like
that?
And
the
answer
is
no:
what
happens?
So--Oh
CSP,
as
I'm
sure
you
know,
has
a
whole
host
of
problems
and
really
any
kind
of
web
replication
is
not
was
not
designed
when
they
designed
this
back.
It
really
came
along
later
and
is
sort
of
bolted
on
in
kind
of
a
weird
way
and
tuff
was
really
designed
with
that
as
being
core.
A
So
when
you
update
your
tough
metadata
initially,
that
process
is
where
you
learn
about
and
and
when
you
update
it
before
you're
about
to
do
an
install
or
whatever
else
that
process
is
where
you
learn
about
explicit,
replications
and
also
the
product.
The
point
at
which
you'll
check
for
things
like
implicit
replications
has
any
key
timed
out,
or
has
anybody
explicitly
revoked
things?
A
In
fact,
if
you're
interested
in
replications
and
you're
interested
in
issues
related
to
that
Maryna,
more
who's,
one
of
my
PhD
students
over
there-
she
and
some
folks
from
the
OU
camel
community
and
myself-
have
been
working
on
I'm,
adding
actually
a
self
replication
and
key
rotation
mechanisms
into
the
tough
spec.
So
we've
got
that
in
a
pretty
good
format.
That's
one
of
our
tabs
tap
eight
that
we
think
is
going
to
make
it
into
the
next
iteration
of
the
tough
spec
in
a
few
months.
A
A
A
There's
folks
in
like
the
automotive
space
that
are
working
in
discussing
it
and
those
communities
are
all
pretty
like
more
vibrant
and
then,
when
things
bubble
up
to
the
level
that
they're
going
to
make
it
to
be
a
tap
where
everyone
might
have
to
care
about
it,
then
we
sort
of
reach
out
and
really
link
back
in
all
the
communities
and
pull
the
people
together.
So
I
would
be
I.
Think,
there's
a
couple
ways
to
do
it
going
to
our
github
and
watching
the
issue
tracker
watching,
what's
happening
with
taps
and
watching
commits
there.
A
It's
very
low,
intentional
I
mean
there's
a
good
thing
for
a
security
spec.
Is
that
it's
low
turn?
You
don't
constantly
have
to?
You
know
make
changes
to
your
to
your
system
because
it's
been
stable
and
tested
and
validated
lots
of
different
ways,
but
I
think
that
engaging
in
one
of
the
other
projects,
like
notary
or
even
just
following
on,
what's
happening
with
tough,
is
a
great
way
to
engage
with
us.