►
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
Deep Dive: TUF / Notary - Justin Cappos & Lukas Puehringer, NYU
When repositories are compromised, TUF and Notary provide protection so that users are not at risk. This talk focuses on some of the key innovations that make this possible, including self-revocation, key rotation, and integration into supply chain validation software such as in-toto.
https://sched.co/MPkF
A
All
right
so
welcome
everybody
to
the
tough
notary,
deep
dive,
I'm
Justin
capitals,
a
professor
at
NYU,
and
this
is
Lucas
hi.
Everyone
Lucas
is
a
developer.
Who
works
with
me
and
we're
gonna,
be
talking
about
tough
notary
and
a
little
bit
about
a
project
called
in
toto.
So
I'll
go
ahead
and
kick
us
off
all
right.
So,
first
off
because
I
am
a
professor
I
get
to
do
things
like
give
pop
quizzes.
So
there
is
an
attack
vector
that,
when
exploited
lets,
attackers
do
basically
anything
with
your
device.
A
A
If
you
try
to
attack
this
vector,
a
failure
to
do
this
often
seems
like
there
was
just
some
accident
or
some
error,
and
this
has
been
used
by
the
absolute
top
hackers
in
the
world
to
go
after
targets
that
they
really
really
care
about,
that
they
want
to
cause
massive
damage.
So
does
anybody
know
what
this
attack
vector
is
in
the
back?
Yes,
I
saw
yes,
software
updates.
Yes,
thank
you.
Somebody
came
to
the
intro
session.
That's
great
and
this
attack
vector
is
super
super
effective.
There
are
many
many
victims
of
this.
A
This
slide
could
have
a
hundred
logos
on
it
easily.
But
one
thing
to
notice
about
this
is
that
all
these
companies
who've
had
their
users
attacked
through
a
software
update
as
a
vector.
These
are
also
companies
that
you
would
think
about
as
having
some
of
the
best
security
teams
in
the
world
right
so
they're.
You
know
you
one
one
should
think
about
this
and
be
concerned
and
worried
about
this
as
a
potential
area.
Can't
you
just
use,
crypto
doesn't
crypto
just
work,
hey
I,
have
a
bike
lock,
isn't
my
bike
secure?
A
No
one
could
possibly
just
pick
the
bike
up.
You
know,
lift
the
lock
part
over
the
fence
and
just
over
the
pole,
and
run
away
with
it.
It's
not
that
simple
and
the
real
attack
vector
that
I
think
you
need
to
think
about
in
this
space.
Is
somebody
getting
in
and
breaking
in
and
getting
into
a
server
a
repository,
an
area
that
has
something
like
a
key
in
it?
Okay,
so
don't
think
of
it
as
we're
really
gonna
protect
our
key.
You
know
that's
a
little
bit
like.
A
Oh
we're,
just
going
to
be
kind
of
careful
with
our
with
our
basket
that
we
stuff
all
of
our
eggs
into
right.
People
motivated
attackers
have
shown
time
and
time
again
they
can
get
into
seriously
protected
infrastructure.
If
you
have
a
single
point
of
failure,
and
so
you
need
to-
and
this
is
in
fact
many
of
these
incidents
have
happened
in
situations
where
companies
have
had
something
like
an
H
s
ound
and
had
really
good
procedures
around
it.
A
You
know
part
of
an
infrastructure
that
that
the
company
had
spent
a
lot
of
time
trying
to
protect,
but
was
unsuccessful.
Okay,
so
what
tough
does
is
tough
is
designed
specifically
to
try
to
protect
against
attacks
and
attackers
that
do
something
like,
let's
say,
would
break
into
a
large.
You
know,
like
software
repository
like
something
like,
maybe
docker
hub
if
docker
hub
was
broken
into
and
if,
thankfully
it
didn't
happen
in
this
in
the
case
of
the
recent
incident.
A
But
if,
in
that
case
an
attacker
had
had
write,
access
to
sensitive
parts
of
docker
hub
tuff
would
have
provided
very
serious
guarantees
for
any
users
using
it,
and
you
wouldn't
have
had
things
like
people
being
able
to
push
bad
images.
You
might
have
had
people
being
able
to
do
things
like
tell
you
that
there
hadn't
been
an
updated
image
when
in
fact,
there
had
or
similar
and
toughest
built
on
the
so
the
first
principle
is
be
compromised
resilient.
A
The
second
principle
is
to
do
key
management
and
to
do
it
correctly
so
deal
with
things
like
revocation
of
keys,
be
able
to
have
people
be
able
to
go
and
delegate
trusts
to
each
other
and
manage
all
of
that
securely
and
make
sure
that
you're
you're
handling
key
management
and
you're,
really
thinking
about
how
you
provision
and
get
keys
out
there
in
a
secure
way.
The
third
principle
is:
support,
don't
judge,
so
we
want
to
work
inside
the
infrastructure
and
the
environments
that
everybody
already
has.
A
A
Our
integrators
that
have
gone
and
done
this
have
found
that,
basically,
it's
just
them
doing
something
to
add
signing
to
steps.
They
were
already
doing
as
part
of
their
processes,
and
so
there's
sort
of
this
one-time
initial
cost.
You
pay
to
set
up
tough,
but
then,
after
that,
it's
as
basically
invisible
protection
in
your
system.
Okay,
so
send
us
is
a
deep
dive.
I'm
not
gonna,
go
very
quickly
through
I'm,
not
gonna,
go
in
a
slow
way
through
the
high-level
stuff
I'm
gonna
get
through
this
I.
A
Imagine
most
of
you
have
had
some
experience
with
tough.
Is
that
true,
at
least
been
to
an
intro
session
or
something
who
has
been
to
an
intro
session
or
you
stuff,
or
looked
at
anything,
okay
good.
So
most
of
you,
so
I'm
gonna
go
a
little
quickly
through
this
I
am
happy
to
answer
questions
and
talk
about
things,
but
we
want
to
minimize
damage
from
an
attack
contain
the
impact
of
successful
attacks.
A
Our
goal
was
to
be
able
to
do
key,
revocation
and
you
know
recover
from
compromises,
because
because
compromise
resilience
is
our
goal
now,
if
you
look
at
things
like
GPG
and
you
look
at
how
x.509
certificates
are
done
in
the
context
of
the
web,
you
can
definitely
tell
that
the
mechanisms
for
revocation
were
kind
of
bolted
on
later
on
as
sort
of
well.
You
know
we
need
to
have
this
later.
Let's
add
this
in
and
with
tough
they're
very
seamless,
and
they
work
very
well
in
the
context
of
what
you're
doing
so.
A
A
So
I
already
just
kind
of
talked
about
this,
a
little
bit
where
the
risk
is
minimized
by
sorry.
The
way
that
roles
are
used
in
tough
is
designed
to
minimize
risk.
So
you
have
roles
that
can
do
things
like
serve
as
the
root
of
trust
or
assign
packages
and
inside
of
tough.
If
you're
managing
things
like
your
route
of
trust,
practical
deployments
when
they
do
this,
they
have
typically
three
five.
A
You
know
locked
desk
saves
at
no
installations
around
the
world
to
be
able
to
compromise
and
get
in
to
situations
like
that,
and,
of
course,
you
know
you
configure
it
for
whatever
makes
sense
for
your
organization.
You're
not
forced
to
do
this
in
any
way,
but
for
something
like
on
the
scale
of
a
docker
hub,
or
you
know
like
some
of
the
automotive
makers
that
use
tough
and
tough
variants.
A
They're,
you
know,
obviously
want
to
are
willing
to
have
a
procedure
like
that
in
order
to
protect
the
route
of
trust,
but
then
those
keys
only
have
to
be
used
very
infrequently
like
when
there's
a
major
compromise
or
every
you
know
every
so
often
to
make
sure
that
you
know
that
they
have
a
bunch
of
them
haven't
been
lost.
Online
keys
only
are
used
to
in
situations
where
you
want
to
do
something
like
say.
A
Has
there
been
an
update
recently
or
some
other
thing,
where
the
loss
of
that
key
does
not
pose
a
major
security
risk
to
your
to
your
users?
The
exposure
of
that
key,
you
know,
isn't
sort
of
like
a
game
over
scenario
where
you're
gonna
be
on
the
front
page
of
the
New
York
Times
they'll
just
be
a
little
notice
you
put
out,
hopefully
without
a
lot
of
hullabaloo.
A
Tough
supports,
multi
signature,
trust
as
I've
said
a
couple
times.
So
as
a
result,
you
end
up
with
a
series
of
roles
inside
of
tough
there's
root,
roll
timestamp
snapshot
and
a
projects
or
targets
role,
and
then
this
delegates
out
to
the
different
projects
that
get
signed.
So
you
can
do
things
like
say
that,
for
instance,
I
can
have
someone
come
work
for
me
and
be
an
intern,
and
the
intern
is
only
able
to
build,
is
able
to
build
versions
of
tough
but
only
able
to
build
versions
of
tough.
A
That
hat
like
our
labeled
alpha
or
something
like
that
or
labeled.
You
know
testing
or
something
so
you
can
go
and
sub
delegate
all
this
out.
It's
much
more
complicated
to
look
at
on
this
slide
than
it
is
to
actually
integrate
into
your
system.
It's
one
of
the
pieces
of
feedback
we've
had
is
is
that
it
looks
complicated,
but
then
we
tried
it
and
it
was
super
easy
and
your
users
don't
know
about
any
of
this
right.
A
You
don't
have
to
worry
about
if
you're
as
you're
driving
down
the
road
in
your
new
model
car
that
it's
going
to
come
up
and
put
up
this
diagram
and
ask
you
a
question
about
something:
it's
just
not
the
way
that
tuff
works.
If
everything
goes
well,
it's
completely
invisible.
We've
had
folks
that
have
deployed
it
in
cloud
scenarios
that
didn't
talk
to
us
or
tell
us
they
were
applying
it
and
we
didn't
find
out
later
until
they
had
a
and
ended
up
having
an
error
message.
A
That
said
something
about
tough
in
their
error
log
that
was
public
to
their
users,
and
then
we
were
like.
Oh
hey,
that's
kind
of
bittersweet.
We
just
found
out
using
tough,
but
you
know
it
was
because
there
was
an
error
message
that
was
in
your
log,
related
to
it.
So
what's
coming
in,
what's
new
with
tough,
so
tough
itself
has
evolved
a
bit
over
time.
It
is
a
specification,
so
it
is
quite
stable.
A
There
aren't
a
lot
of
major
changes
that
have
happened
to
tough,
but
there
are
four
other
little
changes
that
I'm
going
to
talk
very
quickly
about
today.
So
one
is,
we
are
adding
functionality
for
key
rotation
directly
into
tough.
You
could
already
rotate
keys
in
tough,
but
the
way
that
tough
worked
is
that
when
I
did
a
delegation
I
delegated
to
a
key,
so
I
would
delegate
effectively
to
like
Lucas
with
Lucas's
key
or
Sarah
with
Sarah's
key,
and
the
problem
was:
is
that
what
happens
if
Sarah
loses
her
key
or
Sarah's
key
is
compromised?
A
A
Don't
trust
my
my
old
file
anymore,
trust
this
new
one
or
just
sign
a
file
that
says,
don't
trust
my
old
file
anymore,
okay,
so
that
allows
her
to
go
and
do
things
like
rotate
to
a
new
key
and
all
of
us
that
delegate
to
her
don't
have
to
update
our
delegations
or
she
can
self
revoke.
Ricky,
say:
don't
trust
this
key
anymore
and
then
none
of
the
users
who
use
this
will
end
up
trusting
her.
A
We
also
have
made
more
explicit
the
way
that
you
should
manage
different
versions
of
tough
itself,
like
your
tough
clients,
your
tough
updaters,
because
you
know
as
folks,
deploying
and
running
into
scenarios
where
they
want
to
add
functionality
that
can
be
breaking
in
some
cases.
We
want
this
to
be
completely
seamless,
so
the
you
know
the
way
this
works
is
fairly
simple.
You
check
the
Tough
version
before
an
update
you
go
and
you
update
the
tough
client
itself
before
updating
metadata
and
the
repository
just
stores
a
small
amount
of
extra
metadata.
A
This
lets
you
have
non
backwards,
compatible
changes
and
also,
as
part
of
this
tap,
which
is
very
minor.
We're
also
standardizing
the
semantic
versioning
that
that
is
the
way
you
should
do
it.
Everybody
who
is
using
tough,
that
I'm
aware
of
was
already
doing
this,
but
we
want
to
just
make
it
part
of
the
spec
to
say
like
hey,
you
really
really
should
do
this.
A
There's
another
thing
that
we're
adding
as
into
tough
as
part
of
the
specification,
is
different
people
who
deploy
tough
for
a
bunch
of
reasons
like
legacy
reasons,
and
just
because
of
the
way
they
had
done
things
in
some
cases
wanted
to
do
all
the
things
tough
told
them
to
do,
but
wanted
to
use
things
like
a
different
wire
line.
Format
where
one
group
might
want
to
use
XML.
Another
group
might
want
to
use
so
I'm,
really
tight,
like
de
rber
or
encoding.
A
Someone
else
might
use
JSON,
and
the
thing
is
is
that
they
we
want
them
all
to
be
sort
of
compliant
with
tough
and
do
all
the
right
things
in
all
the
right
cases.
But
if
we
went
and
said
in
order
to
use
tough,
you
have
to
use
JSON
or
you
have
to
use
this.
You
have
to
use
that
people
would
effectively
rebel
and
say
well.
We
can't
do
that.
So
this
is
our
way
to
try
to
strike
a
balance
where
you
can
get
legacy
support
where
people
can
have
different
formats.
A
A
But
your
tough
client
should
not
need
to
change
as
part
of
this,
and
with
these
changes
being
integrated
in
which
our
plan
is
to
have
this
done
over
the
next
few
weeks,
we
will
be
at
a
1.0
milestone
for
four
tough,
but
now
that
we're
we've
talked
about
how
to
get
to
the
1.0
milestone
for
tough
Lucas
is
going
to
come
and
talk
about
how
we
get
beyond
tough.
What
we
protect
against
Thanks.
B
Thanks
Justin
does
the
microphone
work,
so
the
key
takeaway
from
what
Justin
said
is:
go
you
stuff?
If
you
manage
software
updates,
you
should
use
to
have
to
protect
it
because
Justin
and
a
bunch
of
other
bright
people
spend
a
lot
of
thought
on
how
to
do
this,
and
so
that
not
everyone
has
to
do
it.
Do
it
by
themselves
and
I,
get
to
tell
you
now
that
protecting
your
software
updater
won't
do
it.
B
It
won't
be
enough,
because
what
is
with
all
the
things
that
are
happening
before
that
which
are
generally
referred
to
as
the
software
supply
chain.
So
in
order
to
create
software,
it
runs
through
various
through
a
series
of
steps
where
you
produce
the
code.
You
check
it
into
your
software
in
your
source
code
repository.
Then
you
build
it
somewhere
on
a
build
farm
or
in
your
CI
CD.
You
run
tests
over
it
either
before
or
after
building
you
can
do
static
tests,
dynamic
tests.
You
can
run
CVE
scanners
over
it.
B
Then
you
somehow
package
it
in
the
container
space.
You
would
create
an
a
container
image
and
you
put
it
in
an
image
repository
and,
finally,
you
want
to
use
it
as
a
user
or
deploy
it
in
your
kubernetes
cluster.
So,
as
you
can
imagine,
and
as
I
said,
tough
only
protects
the
outcome
of
the
entire
software
supply
chain,
but
all
of
the
other
parts
are
protect
should
be
protected
as
well.
So
this
is
a
huge
tag
surface
where
any
of
the
steps
or
your
product,
your
software
in
transit,
can
be
compromised
and.
B
Yeah,
that's
bad,
and
this
is
just
a
very
silly
small
software
supply
chain
example.
For
the
sake
of
this
talk,
and
in
order
to
talk
about
how
we
deal
with
this,
but
imagine
if
this
happens
to
a
real
world
software
supply
to
you,
where
you
have
a
lot
of
different
places
and
they're
all
somehow
interconnected
and
a
lot
of
people
are
do
different
things
in
your
supply
chain.
So
you
really
want
that
that
you
can
provide
integrity
of
all
these
steps
because
attacks
are
happening
all
the
time,
especially
in
the
last
couple
of
years.
B
B
So
how
can
we
fix
this
I'm
going
back
to
this
simple
software
supply
chain?
For
this
talk,
there
are
already
a
lot
of
very
sensible
point
solutions
for
different
parts
in
your
software
supply
chain.
You
can
sign
your
get
commits
you
can
even
use
Yubikey,
which
makes
it
a
little
more
unlikely
for
your
keys
to
get
compromised.
You
can
use
something
to
even
make
get
signatures
better,
which
was,
incidentally,
also
developed,
and
why
you
it's
called
reference
state
lock
for
the
build
process.
You
can
use
trusted
platform
modules
or
HSM.
B
You
can
take
advantage.
It
advantage
of
reproducible
builds
for
testing,
as
I
said
earlier.
Testing
itself
is
a
way
of
protecting
the
software
supply
chain
by
running
security,
linters
over
your
code
by
scanning
for
CVS
and
so
on,
but
in
reality,
testing
is
also
just
another
series
of
steps
in
your
supply
chain,
because
you
want
to
know
if
your
code
was
tested
or
when
your
code
was
tested,
the
code
that
was
tested,
it's
also
the
code
that
gets
into
your
final
product
and
for
distribution.
B
We
said
we
can
do
things
about
the
individual
steps,
but
what
about
the
product
in
transit
like
the
gaps
in
between
the
steps
and
what
about
compliance?
How
do
you
know
that
the
steps
we're
performed
according
to
how
you
intended
them
to
be
performed,
and
that's
where
we
design
in
toto
in
toto
is
the
next
big
tough
in
toda
is
a
framework
that
can
be
used
to
verifiably
define
all
the
steps
or
those
are
the
goals
and
that's
what
we're
trying
to
do
with
in
toto.
B
We
want
to
verify
we
define
all
the
steps
in
the
supply
chain.
We
want
to
verifiably
define
who's
supposed
out
these
steps
and,
lastly,
we
want
to
guarantee
that
only
the
things
in
our
definition
happened
and
nothing
else.
So
now
in
toto
works,
you
have
a
project
definition,
we
call
it
a
layout
and
it
defines,
as
I
said,
the
steps
of
the
supply
chain,
like
your
let's
say,
get
release
tab,
then
your
build
step,
your
various
testing
steps
and
your
contour
containerization
or
distribution
step.
B
B
B
According
to
definition,
the
functionaries
which
are
the
actors
in
your
supply
chain
have
to
produce
or
provide
evidence
when
they,
when
they
perform
their
respective
steps
and
in
total,
provides
tooling
for
that.
So,
whenever
you
run
your
usual,
get
tag
command
or
your
make
command
or
whatever
command
you
use.
You
just
wrap
it
in
an
in
total
command
and
that
records
all
the
hashes
of
the
files
that
went
into
your
activity
and
that
came
out
of
your
activity
and
it
signs
it
and
propagates
it
for
later
verification.
B
B
B
We've
come
quite
a
way
within
toto,
so
there
are.
We
have
a
lot
of
tooling.
We
have
our
main
reference
implementation,
which
is
in
Python,
but
have
partial
implementations
of
and
hang
they
are
used
for
plugins
for
a
champions
plugin
that
can
be
used
to
provide
link
metadata
for
your
supply
chain.
We
also
have
a
cube
control
plug-in
to
verify
containers.
B
We
are
being
used
in
the
Debian
community
there's
a
collaboration
with
the
reproducible
builds
folks
so
and
when
you
do
absence,
apt-get
install
you
run
in
total
in
order
to
verify
whether
a
pro
the
package
you're
trying
to
install
is
reproducible,
we
are
using
using
it
indoor
for
our
own
projects.
We
have
in
total
metadata
for
in
todo
itself.
We
have
it
for
other
projects
of
at
nyu,
and
one
of
the
big
sponsors
here
at
cube.
Con
is
actually
using
in
todo,
together
with
tough
to
protect
their
entire
supply
chain
and
infrastructure.
B
B
A
A
B
A
A
E
A
Yeah,
that's
that's
such
a
great
question.
So
that's
that's
a
feature
of
the
presentation
format
so
usually
when
you
talk
about
Alice
and
Bob
and
they
have
their
little
keys
and
they're
signing
things,
it's
not
really
an
alice
but,
like
certainly
Alice,
doesn't
have
like
an
abacus.
You
know
manually,
counting
things
up
and
doing
that.
So
in
this
case,
these
parties,
these
functionaries
as
we
call
them,
can
all
be
completely
automated
as
well
and
are
in
many
cases
completely
automated
parties.
A
E
A
It's
what
what
you've
done?
Okay,
so
in
toto,
is
like
tough
in
that
it's
not
judgemental.
If
you
choose
for
your
environment,
it's
just
easier
to
make
these
be
like
literally
keys
on
disk,
and
then
you
trust,
you
know
you're
saying.
Well,
then
we
know
if
our
team
goes
and
wants
to
pretend
that
this
verification
step
happened,
then
that's
sort
of
okay.
You
could
set
it
up
that
way.
You
can
have
HSMs.
You
can
have
something
in
between
there's
there's.
A
You
know
different
ways
to
manage
and
do
this
that
get
used
in
different
environments
for
people
who
are
doing
this,
but
at
least
you
know,
even
if
you
just
stick
it
as
a
key
on
disk
at
least
now.
You
actually
know
that
someone
went
and
ran
it
through
there,
or
at
least
someone
had
access
to
your
keys
to
go
and
sign
off.
To
say
this.
This
process
went
okay,
and
today
you
don't
you,
don't
really
you
don't
have
no
way
of
knowing
that.
B
I
didn't
mention
is
that
there
are
thresholds
that
you
can
use,
so
you
can
have
your
seat
see
ICD
pipeline,
you
can
replicate
it
and
say:
I
need
an
or
k
out
of
n
functionaries,
which
can
be
people
cut,
but
can
also
be
automated
steps.
I
need
k
out
of
n
to
provide
link
metadata
for
my
step,
so
you
reduce
the
likelihood
of
compromise
if
the
impact
of
the
compromise
right.
F
A
A
Here
there
there
communicating
here
with
like
their
registry-
and
this
is
the
step
that
tough
already
handles
for
them,
so
by
kind
of
putting
tough
and
in
toto
together,
you
get
benefit.
But
that
is
not
you
know
of
the
major
different
deployment
models.
That
is
not
a
pervasive
deployment
model.
It
is
it's
our
community's
fairly
evenly
split,
a
third,
a
third,
a
third
between
different
ways
that
they
use
in
toto
and
what
they've
done
and
there's
a
third
that
does
not
use
tough.
As
part
of
the
process.
F
E
So
is
there
any
integration
with
other
built
systems
like
not
Jenkins?
Well,
because
you
yeah
in
this
area,
you
would
have
to
define
your
pipelines
twice
once
for
the
actual
execution
and
once
for
tough,
as
a
verification
of
that.
So
maybe
is.
There
is
something
where
I
can
input
a
gitlab
CI
file
and
just
have
a
top-up
and
in
total
file.
So
I
don't
have
to
write
this
again
and
keep
the
difference.
Okay,.
A
So
I'll
answer
the
first
part
of
the
question
and
then
either
we
I
don't
know
if
I
can
answer
all
the
second
part,
because
I
haven't
I'm,
not
that
familiar
with
the
with
the
second
system
you
mentioned,
I
didn't
quite
catch
the
name
either,
but
in
in
terms
of
integrating
into
other
build
systems.
Absolutely
it's
actually
very
trivial
to
do
that.
Jenkins
was
hard
because
of
like
the
hosted
server
model
that
they
use,
but
we
actually
did
Travis
integration
like
before.
A
We
did
anything
with
Jenkins
and
things
like
that,
and
we've
integrated
into
a
bunch
of
things.
It's
super
super
simple
to
do
it's
the
kind
of
thing
where,
if
you
have
your
own,
whatever
you
know,
talk
to
us
and
you're,
probably
done
in
an
afternoon
the,
but
in
general,
if
you
already
have
information
about
what
your
layout
or
your
pipeline
is.
A
The
philosophy
we
have
now
is
that
people
should
take
that
information
and
should
be
able
to
write
that
very
easily
as
a
layout
in
in
toto,
and
you
actually
get
a
lot
of
benefits
from
doing
that.
One
thing
that
that
might
not
have
been
apparent
from
this,
and
one
thing
that
kind
of
surprised
me
in
a
very
positive
way
about
this,
is
we
had
written
in
a
very
normal
way.
You
write
these
layouts
and
you
link
the
metadata
you
get
together
and
you
know
stuff
like
this.
Like
Lukas
was
talking
about.
A
So
you
have
all
this
stuff
that
links
together
and
you
can
even
do
things
after
install
so
like
are
in
the
process
of
installation,
and
so
one
really.
It
is
that
if
you
look
at
packages
like
Debian
packages
or
rpms,
or
whatever
else,
they're,
basically
just
zip
files
and
so
the
the
sort
of
rules
that
we
wrote,
we
wrote
these
rules.
That
basically
said
well.
A
There
was
an
android
APK
attack
where
they
put
multiple
copies
of
the
same
file
into
an
APK,
and
then
the
signature
verification
was
over
the
wrong
instance
of
the
file,
the
different
instance
than
the
one
that
was
put
on
disk,
and
so
you
have
like
also
a
lot
of
historical
vulnerabilities,
buffer
overflows
and
other
things
like
that
and
those
kind
of
decompression
routines,
and
so
the
the
nice
thing
about
that
is
just
a
very
normal
natural
way
of
writing.
This
in
total
metadata,
provide
you
with
all
this
additional
security,
validation
and
coverage.
A
G
A
Notary
is
the
most
popular
implementation
of
tough
for
the
cloud.
That's
thing
number
one.
So
if
you're
looking
for
great
like
if
you
wanted
to
play
something
like
tough
notary,
is
a
as
a
nice
go.
Implementation
of
tough
notary
also
was
the
very
first
implementation
of
tough
to
really
have
widespread
use
and
as
a
result
that
tough
itself
hadn't
been
used
by
a
lot
of
communities
at
that
point,
and
so
notary
made
some
opinionated
decisions
about
ways
to
do
certain
things
within
tough.
A
Some
of
these
were
very
good
things
that
we
ended
up
integrating
back
into
tough.
Some
of
these
are
things
that
maybe
we'll
be
changed
in
the
future,
but
we're
very
understandable-
and
you
know
whatever
and
and
make
you
know,
made
made
sense
at
the
time,
and
you
know
yeah
so
I
think
that
if
you're
looking
for
a
good
cloud
native
implementation,
you
want
something
easy
to
integrate.
A
A
Is
a
specification
it's,
it
also
has
a
reference
implementation
that
is
used
in
the
cloud.
In
fact,
there
was
a
nice
talk
by
data
dog
about
how
they
use
tough
in
the
last
CN
CF
meeting,
and
there
are
other
implementations
of
tough
available.
Tough
is
actually
a
variant
of
tough
called
obtain
is
actually
used
pretty
widely
in
the
automotive
space
and
there's
about
half
dozen
to
a
dozen
different
implementations
there.
So
there
are
other
implementations
available.
Some
of
those
are
open-source
in
different
languages.
A
H
That's
just
one
more
I
mean
notaries,
also
productions,
server,
metadata
server,
implementation
designed
to
be
run
alongside
a
registry
as
well
as
the
the
client-side
implementations,
and
that's
something
that
you
know.
We've
been
running
it
in
production
for
many
years
of
docker
without
you
know,
and
it's
been
highly
reliable
and
so
on.
So
that
part
of
it
is
something
that,
if
you
want
to
preserve
the
metadata
with
a
registry,
that's
kind
of
your
any
option
at
the
moment
as
well.
Right.