►
From YouTube: TUF / Notary Project Intro – David Lawrence, Docker, & Justin Cappos, NYU, TUF (Any Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
TUF / Notary Project Intro – David Lawrence, Docker, & Justin Cappos, NYU, TUF (Any Skill Level)
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 a secure (compromise resilient) 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, Notary / TUF are surprisingly easy to use and are deployed 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!
About Justin
Justin Cappos is a professor in the Computer Science and Engineering department at New York University. His research includes the TUF project (which is hosted by the Linux Foundation / CNCF), which provides a compromise-resilient mechanism for the secure distribution of software. His research advances are adopted into production use by Docker, git, Python, VMware, Cloudflare, Digital Ocean, most Linux distributions, and many automobiles. Due to the practical impact of his work, Cappos was named to Popular Science's Brilliant 10 list in 2013 recognizing him as one of 10 brilliant scientists under 40.
About David
Lay security developer that has learned a lot of mistakes the hard way. David started off building authentication systems, moved on to encrypted cloud storage for a few years, and is now working on the Security Team at Docker, presently focused on securing software distribution.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
Kind
of
set
things
up
in
this
talk:
we
want
to
kind
of
go
over.
Why
does
this
thing
even
exist?
What
are
the
problems
were
trying
to
solve
and
an
overview
of
sort
of?
What
does
the
update
framework
do
and
very
briefly
talk
about
notary
if
you
want
to
get
into
the
Nitty
Gritty
come
to
the
deep
dive
on
Friday
and
I've
got
the
information
for
that
at
the
end
of
the
presentation.
So,
ultimately
you
know:
do
you
know
what
you
downloaded
last
night
right,
that's
the
problem.
A
This
is
one
of
my
favorite
devices
from
sort
of
pre
digital
signing.
This
is
an
autopen.
It's
used
to
forge
signatures,
typically,
the
signatures
of
the
US
president
on
less
than
official
documents.
So
it's
a
tool,
that's
specifically
designed
for
creating
a
fake
signature.
That's
indistinguishable
from
the
original,
but
going
on
to
what
we're
really
here
to
talk
about
signing,
is
based
on
asymmetric,
cryptography
and
quick
show
of
hands
who's
already
familiar
with
the
idea
of
asymmetric
cryptography.
A
Okay,
that's
better
than
normal,
there's
still
a
few
hands
down
so
for
those
that
aren't
familiar
asymmetric
cryptography
relies
on
the
idea
that
you
can
generate
an
asymmetric
pair
of
keys,
so
a
pair
of
keys
where
they're
different
in
some
way
and
they
can
essentially
perform
the
inverse
of
each
other's
operation.
So
if
you
encrypt
with
one
you
decrypt
with
the
other
one,
if
you
sign
with
one
you
verify
with
the
other
one
one
of
these
keys,
you
keep
private
and
keep
it
to
yourself.
Maybe
you
store
it
on
hardware.
A
You
probably
want
to
store
it
somewhere
secure,
so
maybe
a
laptop
that
you
don't
bring
online.
Very
often
I
have
mine
in
a
Yubikey,
which
is
a
little
hardware
device
that
I
have
to
plug
into
my
computer.
If
you're
in
a
large
enterprise
environment,
you
might
use
a
hardware
security
module
which,
like
a
dedicated
box,
that
you're
gonna
plug
into
your
infrastructure,
the
public
key,
you
then
share
with
everybody.
It
doesn't
matter
who
knows
the
public
key.
A
Other
people
are
going
to
use
that
public
key
to
encrypt
things,
to
send
to
you
that
only
you're
going
to
be
able
to
decrypt
using
the
other
half,
which
is
the
private
key,
say.
One
of
the
most
common
ways
to
make
use
of
asymmetric
cryptography
is
GPG
the
ganoub
privacy
guard.
Now
this
doesn't
actually
implement
any
cryptographic.
Algorithms,
it's
a
tool
chain.
Serialization.
It
gives
you
all
of
the
other
stuff.
You
need
around
the
actual
cryptographic
ciphers
to
be
able
to
do
those
signing
and
encryption
operations.
A
So
if
you're
sending
signed
emails,
you'll
probably
install
if
you're
on
a
Mac
it'll
be
GPG
suite
and
that
has
integrations
into
mail
and
you
can
just
check
a
box
to
say
yep
sign
my
emails
for
me,
you
can
import
other
people's
keys
into
that
other
people's
public
keys
when
they
send
you
a
signed,
email
you'll
be
able
to
verify
those
people
sent
it
to
you.
So
this
really
is
just
their
sort
of
ease
the
whole
use
of
cryptography,
but
it
has
a
lot
of
problems.
A
A
Gpg
does
a
reasonable
job
with
the
tampering
like
if
you
trust
the
key,
you
have
a
way
to
verify
that
you
know
the
package
hasn't
been
tampered
with
since
it
was
signed,
but
there
are
issues
with
how
you
actually
manage
those
keys
and
we'll
talk
about
those.
So
that's
authenticity
do
I,
know
who
actually
owns
this
key.
Do
I
know
what
this
key
was
actually
approved
for
now
with
GPG,
we
use
the
web
of
trust.
A
The
web
of
trust
relies
on
the
fact
that
say
you
know:
I've
met
somebody
in
this
room,
I've
verified
their
identity
and
I.
Take
my
private
key
and
I
actually
sign
their
key
to
say.
Yes,
I
have
verified
that
person's
identity
and
then
somebody
else
who
wants
to
consume
content
that
that
person
published
will
look
at
their
web
of
trust
and
they'll
say
you
know,
I
trust.
A
Anyone
who
has
three
degrees
of
separation
from
me,
so
if
I
can
hop
through
and
within
three
hops,
get
to
that
other
person,
I'll
trust
the
fact
that
they're
actually
in
control
of
their
key,
that's
a
very
tenuous
connection
right.
If
your
key
is
compromised,
maybe
that
can
be
used
to
sign
other
people's
keys.
So
it
looks
like
you
trust
them,
but
you
don't.
If
that
person's
key
has
been
compromised,
there
aren't
really
good
mechanisms
for
them
to
inform
you
that
it's
being
compromised,
particularly
if
you
don't
know
them.
A
You
know
if
your
one
degree
of
trust
they
might
email.
You
say
hey.
My
key
has
been
compromised.
Don't
trust
anymore
here
as
my
new
key
and
if
you
miss
that
message,
you're
gonna
continue
to
trust
the
old
one.
So
again
another
failure
point
in
our
system,
but
if
you're
multiple
degrees
of
separation
away,
you
might
not
get
a
notification
at
all
like
a
good
example
of
that
is
many
of
the
Linux
distributions
have
had
their
package.
A
Signing
keys,
compromised
and
they've
had
to
send
out
emails
to
their
users,
saying
you
know
really
sorry,
this
server
got
compromised,
it
had
keys
on
it.
We
actually
don't
know
if
the
keys
were
compromised,
but
in
case
they
were
stopped.
Trusting
the
old
key
and
here's
the
new
one
to
trust,
and
if
you
don't
get
that
message,
you
never
update
your
service.
Even
if
you
do
get
the
message,
maybe
you
miss
a
server
like
it's
very
easy
here
for
you
to
not
get
the
update
and
to
continue
to
trust
keys
that
you
shouldn't
trust
anymore.
A
Leading
on
from
that,
we
have
the
issue
of
revocation,
like
I
said:
how
do
you
actually
communicate
to
somebody
that
the
key
should
no
longer
be
trusted?
Certificate
authorities
have
at
least
a
solution
to
this
right.
We
have
certificate,
revocation
lists,
so
you
can
go
and
query
and
get
back
a
list
of
all
the
stiphu
kits
that
have
been
blacklisted,
not
fantastic,
because
you
have
to
make
those
lists
pretty
large
to
contain
every
key
that
hasn't
expired,
that
shouldn't
be
trusted
anymore.
A
So
then
they
invented
OCSP
I,
which,
if
I
remember,
is
online
certificate
status
protocol.
This
is
rather
than
querying
for
an
entire
list.
You
query
for
a
specifics,
difficut
and
asked
this
difficulty.
Is
this
certificate
still
trusted?
But
again
you
have
to
go
and
do
that
on
every
single
request.
If
you
can't
reach
the
stiff
get
Authority,
how
do
you
fail
on
that?
Revocation
is
also
very
painful
process
in
our
existing
systems.
A
Now,
in
addition
to
these
signing
problems,
there
are
additional
things
that
we
want
to
solve
right,
we're
not
just
looking
to
build
something.
That's
nicer
to
use
we're
actually
looking
to
build
something
that
solves
problems
that
are
unique
to
software
distribution
and
updating
your
software,
so
software
gets
old
right.
We
all
know
this.
A
The
longer
a
piece
of
software
sits
out
in
the
wild
things
go
wrong
with
it
and
not
necessarily
because
you
know
it
literally
bit
rots,
but
we
discover
problems
more
edge
cases
are
found
and
in
particular
we
discover
vulnerabilities
right
when
a
new
piece
of
software
is
deployed.
It
looks
perfect
over
time.
We
realize
there
are
buffer
overflows.
We
didn't
handle
some
particular
piece
of
input
properly.
A
Maybe
you've
got
a
sequel
injection
in
there
and,
as
these
vulnerabilities
are
discovered,
they
get
patched
and
as
they're
patched,
we
want
to
install
newer
versions
of
software
and
now
how
do
we
actually
know
that
we're
getting
a
newer
version
of
the
software?
A
good
case
that
was
seen
I,
think
in
in
Justin's
research
was
there
was
a
mirror
in
Eastern
Europe
for
Red
Hat,
right
lots
of
enterprises,
a
trusting
red
hat.
This
mirror
was
reporting
to
the
Red
Hat's.
Oh
sorry,
this
mirror
was
reporting
to
a
bun
twos
sort
of
checker.
A
So
we
need
to
be
able
guarantee
that
now
there's
additionally,
some
interesting
distribution
properties.
Just
how
do
I
get
my
software
from
A
to
B
the
first
thing
to
be
aware
of
a
lot
of
people
assume
that
you
know
if
I've
got
a
TLS
connection,
great
I'm,
secure,
not
the
case
at
all.
Tls
is
only
connecting
your
computer
that
you're
downloading
from
to
the
server.
That's
serving
that
content.
A
I
think
the
slide
order
out
of
date.
Okay,
we
have
to
jump
back
slide
in
a
second.
It's
really
interesting
to
highlight
that
that
protection
is
not
enough,
because
there
have
been
a
large
number
of
compromises,
essentially
against
the
points
of
distribution
and
against
the
supply
chain.
That
builds
your
software.
So
this
is
a
relatively
small
list.
If
you
go
and
read
the
papers
associated
with
the
update
framework
there's
a
much
larger
list
than
this,
but
these
are
all
compromises
that
happened
over
the
last
nine
years
against
distribution,
centers
and,
in
particular,
transmission
in
2016.
A
Twice
it
was
compromised
both
of
those
times
it
was
actually
signed,
and
when
you
installed
it
on
your
Mac
OSX
was
like
great.
This
is
signed
I'm,
going
to
install
it
with
no
warnings
and
both
times
it
was
installing
a
remote
access
tool,
one
of
my
favorite
ones,
that
I
think
I
actually
emitted
from
this
slide.
I
was
in
the
mid-2000s,
where
the
CIA
is
actually
a
software
vendor
for
other
government
agencies,
so
they
send
agents
into
you,
know
the
FBI,
NSA
I,
guess
I'm,
not
sure
which
agencies
trust
them
there.
A
We
want
a
way
to
actually
detect
if
a
mirror
is
out
of
date.
It
expired
it's
serving
you
old
content,
it
might
be
malicious.
It
might
just
be
that
you
know
the
script.
That's
meant
to
be
pulling
down
the
updates
broke,
but
we
want
to
be
able
to
detect
that
and
we
want
No.
So
how
do
we
solve
many
of
these
problems,
if
not
all
of
them
I'll
hand
over
to
Justin's
that
have
given
overview
of
how
the
update
framework
actually
works?
Thank.
B
You
very
much
I
think
you
also
trust
the
CIA
a
lot
more
than
I.
Do
maybe
it's
part
of
my
suspicious
nature,
but
I
don't
know
that,
regardless
of
who
I
was
I
trust
them
as
a
software
vendor
great.
So
the
real
goal
of
the
update
framework,
the
overarching
goal
of
it,
is
to
be
compromised
resilient,
and
what
that
means
is
is
that
you
should
expect
that
an
attacker
is
going
to
be
able
to
break
into
servers.
B
They're
gonna
steal
some
of
your
keys
they're
going
to
be
somewhere
in
your
infrastructure,
and
you
still
want
your
system
to
be
as
secure
as
you
could
plausibly
make
it
in
that
scenario.
So
it's
not
something
of.
Let's
have
some.
You
know,
plan
B
or
more
likely,
plan
Z
or
something
about
how
we
recover
from
a
compromised.
Let's,
let's
make
that
a
core
part
of
our
system
design,
so
that
when
a
compromise
occurs,
we
know
exactly
how
to
handle
it
and
we
can
degrade
in
security
very
gracefully.
B
So
one
of
the
things
that
tough
does
in
order
to
do
this
is
it
has
a
bunch
of
different
roles
that
different
keys
or
different
groups
of
keys
play
with
in
tough
and
the
reasons
for
this
will
become
clear
in
a
minute,
but
just
as
an
initial
overview,
if
you'll
bear
with
me
for
a
slide
or
two
I'll
explain
what
these
roles
roughly
do.
So
we
have
a
root
of
trust.
The
root
role
is
the
role
that
says
these
are
the
keys
for
the
other
roles.
It's
the.
B
It
also
has
the
ability,
because
it's
determining
which
keys
are
used
for
which
other
roles.
That
also
is
the
thing
that's
used
to
revoke
trust
in
other
keys
in
other
parts
of
the
system.
There's
a
targets,
role,
that's
used
to
actually
indicate
what
packages
or
containers
or
whatever
is
we're
distributing
our
valid.
So
this
is
the
thing
that
I
think
you
typically
think
of
when
you
think
of
I'm
signing
my
software
with
a
key
that
action
is
actually
done
via
the
targets
role.
B
The
target
role
says
this
is
a
valid
copy
of
this
particular
piece
of
software.
The
snapshot
role
tells
you
information.
Like
you
know,
the
the
latest
version
of
Apache
is
whatever
the
latest
version
is
right.
The
latest
version
of
Firefox
is
this.
The
latest
version
of
my
sequel
is
that
and
so
on,
so
it
gives
you
information
so
that
you
can't
have
older
versions
of
software
be
played
back
to
you
and
finally,
there's
the
timestamp
role.
B
That,
basically
just
says,
has
the
has
any
software
on
the
repository
been
updated
recently
and
once
again,
we'll
see
a
little
bit
why
these
are
separated
out
in
a
minute.
So
but
first
you
know
how's
this
information
disseminated
well.
This
is
disseminated
via
a
route
JSON
file
that
contains
information
for
all
these
keys,
which
is
itself
signed
using
the
root
keys.
So
the
root
Keys
signed
information
that
that
described
is
because
they
are
the
fundamental
root
of
trust
on
the
system.
B
So
when
we
want
to
do
something
like
rotate
out
a
key
like,
let's
say,
for
instance,
that
we
want
to
change
out
the
timestamp
key.
All
we
need
to
do
is
go
and
generate
a
new
file
here,
a
new
key
for
timestamp.
You
see,
that's
changed,
sign
it
with
the
root
key
and
then
that's
fine.
If
we
want
to
rotate
out
the
root
key
itself,
we
generate
a
file
that
has
a
new
root
key
in
it
and
sign
it
with
both
the
new
and
the
old
root
keys,
and
now
it's
trusted
within
the
system.
B
So
you
can
rotate
out
any
of
the
keys
that
you
like,
as
as
you
go
through
and
use
the
system.
One
other
important
feature
of
the
way
that
tuff
works
is
remember.
We
have
the
root
role
that
has
targets
and
targets
are
going
to
sign
all
the
data.
That's
all
the
software
that's
being
created.
So
if
you
had
to
have
everyone
share
and
use
that
same
key,
that
would
be
very
problematic.
B
So
instead
we
can
have
different
either
people
or
organizations
that
go
and
sign
for
parts
of
their
software
using
different
keys,
so
David
and
I
may
each
you
know
have
some
software
that
we
sign
as
part
of
this
repository
as
made,
for
instance,
the
spiffy
project
and
the
night.
One
of
the
things
that
that
tuff
lets
you
do
is
something
called
selective
delegations
where
we
can
actually
also
say
that
David.
B
If
there's
a
notary
package,
David
is
the
one
who
has
to
sign
for
it
and
if
a
tough
package
then
I'm
the
one
who
has
to
sign
for
it
and
if
there's
a
spiffy
or
aspire
package
or
something
like
that,
then
the
spiffy
group
signs
for
it,
and
you
can
also
sub
delegate
off
of
here
so
that,
for
instance,
you
could
have
Evan
and
Andrew
and
Emiliano
and
and
all
the
spiffy
people
have
their
own
keys,
be
delegated
off
of
this.
The
spiffy
role.
B
So
it
it
sort
of
streamlines
the
you
know
the
trust
model
and
they
can
all
be
sub
delegated
with
different
privileges
and
so
on.
So
one
of
the
reasons
why
we
have
this,
which,
if
you
really
want
to
know
in
deep
detail
about
why
tough
does
all
this
and
how
this
works,
we
do
have
the
deep
dive
session,
but
to
just
give
you
a
little
taste
of
it.
These
keys
that
you
have
in
a
system
get
used
with
different
amounts
of
frequency,
so
you're
using
something
like
your
timestamp
key,
which
is
saying.
B
When
is
the
last
time
there's
been
an
update,
it
has
to
be
use
for
every
update.
This
is
something
that's
that's
going
to
be
refreshed.
Very
it's
going
to
be
used
very
frequently
in
in
some
cases,
it's
effectively
almost
to
the
point
where
every
client
that
comes
gets
get
something
fresh
signed
by
the
timestamp
server
and
some
deployments.
The
snapshot
role
is
used
whenever
a
version
of
something
gets
changed
and
targets
keys
are
used
whenever
a
person
who's
signing
for
that
specific
type
of
target
goes
to
sign
something
so
think
of
it.
B
So
there
are
things
what
I
mean
by
that
is.
Is
that
they're
not
like
physically
plugged
in
not
even
an
HSM
or
something
like
that
in
a
server
they're,
physically
disconnected
from
from
internet?
So
the
things
like
you
bikies
that
developers
will
go
and
plug
into
their
laptop
when
they
need
to
use
them
and
the
root
Keys
may
in
some
deployments
at
least
or
even
kept
in,
like
safety
deposit
boxes.
B
The
US
government
may
come
to
you
and
tell
you
that
they
have
to
have
your
signing
keys
or
they'll
shut.
You
down,
I
mean
not
that
that
would
ever
happen.
You
know,
but
suppose
that
were
the
case.
One
thing
you
could
possibly
do
is
keep
different
parts
of
your
root
keys
in
the
system
or
even
different
parts
of
your
target
keys
in
different
countries
or
in
different
jurisdictions
or
in
different
areas
to
make
it
harder
for
a
single
person
or
a
government
or
another
entity
to
compel
you
to
to
do
something
like
that.
B
This
isn't
this
isn't
something
where
you
know
I.
There
are
other
approaches,
including
some
of
the
revocation
list,
approaches
and
things
that
are
very
blacklist
based
or
are
very
susceptible
to
you
being
fed
and
given
outdated
information.
So
the
way
we
use
whitelisting
protects
against
a
lot
of
those
types
of
concerns.
One
thing
that
I
think
is
quite
surprising
to
a
lot
of
people
that
first
take
a
look
at
the
sorts
of
things
that
they
seen
here
with
Toth.
Is
they
look
at
it
and
they
say
my
gosh
there's
a
lot
of
keys
here.
B
This
has
got
to
be
a
big
problem
to
have
like
to
use
in
production,
and
one
of
the
things
that
we've
had
people
time
and
time
again
tell
us
is
so
surprising
is:
is
that
I
didn't
realize
how
easy
it
would
be
to
actually
do
this?
Because,
basically
it's
like
you
generate
some
keys
on
startup
when
you
set
up
your
system
and
then
you,
you
know
if
you
are
like
a
developer,
has
to
sign
something
you
just
sign
it
with
your
key.
B
Just
like
you
would
do
design
to
GPG
sign
something
or
whatever,
and
and
that's
it
like
you
know,
you
don't
have
to
think
or
worry
or
do
anything
about
here.
It's
just
something
that
gets
plugged
into
your
architecture.
It's
like
a
one-time
cost
and
then,
after
that,
it's
it's
seamless
for
you
and
it's
it's
absolutely
transparent.
Your
end-users.
B
Don't
even
know
about
it,
even
to
the
point
that
the
way
that
we
found
out
that
several
of
our
adopters
were
using
tough
is
because
they
let
a
key
expire
or
forgot
to
do
something
and
then
an
end
user
complained
about
it
and
in
the
error
log,
it
said
like
tough
bla,
bla
bla.
So
you
know
like
this:
big
provider
has
tough
outage
and
we're
like
oh
wow
they're
using
tough
and
no
one
even
knew
so
yeah
you
do
have
to
keep
on
top
of
things.
I
mean
that's.
The
thing
is,
is
that
you?
B
You
can't
you
know
it's.
The
system
is
designed
to
try
to
be
smart
about
making
sure
that
you
do
things
correctly.
We
have
multi
signature
trusts,
that's
well
supported
throughout
the
system,
so
you're
not
relying
on
a
single
key
to
be
kept
secure.
You
don't
have
to
put
all
your
eggs
in
one
basket.
You
can
divide
things
up
and
and
use
appropriate
mechanisms
for
this.
You
never
need
to
share
keys
in
tough.
B
If
you
ever
think
that
two
people
should
have
the
same
key
because,
oh
you
know
well
we're
gonna
sign
the
same
packages
or
something
you
can
just
delegate
to
both
of
them.
It's
super
easy
to
do
what
even
one
of
you
can
just
delegate
to
the
other.
It's
it's
very
to
do
very
straightforward
and
you
always
want
to
do
that.
Revocation
is
absolutely
a
first-class
thing
in
tough.
B
It
was
a
primary
design
choice
and
a
lot
of
the
fundamental
ways
that
we
do
this
and
for
anybody,
who's
had
to
do,
revocation
in
like
GP
GP,
GP
based
system
or
in
the
web.
You
know
that
this
was
not
a
first
class
design
decision.
This
was
not
something
that
was
like
the
first
thing
they
were
thinking
about
when
they
designed
these
systems.
It
was
something
that
was,
you
know,
item
like
37
B.
B
B
To
forget
to
prevent
against
situations,
for
instance
like
people,
replaying,
old
metadata
or
freezing
you
on
a
certain
old
piece
of
metadata,
and
one
last
kind
of
interesting
point
about
tough
is
tough,
is
not
just
something
that's
only
used
in
docker
and
only
used
in
CNC
F
and
in
the
cloud
it's
used
in
a
lot
of
other
domains.
It's
used
in
programming
languages.
There
are
even
cars.
B
A
Right,
so
you
know,
docker
is
like
say
we
democratized
containers
as
part
of
that
we
want
a
way
to
distribute
the
images
that
we
use
to
instantiate
containers
securely.
So
when
it
came
time
to
look
at
how
we're
going
to
do
you
know
signing
and
trusted
distribution
for
containers,
we
chose
the
update
framework,
but
at
the
time
there
wasn't
a
sort
of
production
grade
version
of
tough.
You
know
there
was.
There
was
a
proof-of-concept
implementation.
A
It
was
a
suite
of
Python
tools,
you
fired
the
Python
interpreter,
you
import
I,
want
to
say
about
20
different
packages,
and
then
you
run
a
lot
of
manual
commands
like
open
file.
Read
file
sign
file,
modify,
it
was
kind
of
painful.
In
addition,
there
wasn't
any
way
to
deal
with
all
the
online
hosting
of
that
content
and
you
know
pushing
updates
getting
updates
from
the
server.
A
So
what
we
built
a
docker
was
notary
which,
as
you
all
know,
because
we're
here
at
Cube,
slash
cloud
native
con
is
a
member
of
the
CNC
F,
along
with
the
update
framework
itself
and
notary
is
fully
open
source.
It
has
been
from
the
start
and
it's
a
it's-
a
vanilla
implementation
of
the
update
framework
like
even
though
we
built
in
docker,
even
though
we've
integrated
it
into
docker.
As
this
thing
called
docker
content.
Trust
notary
itself
has
no
knowledge
about
docker.
It
has
no
knowledge
about
images
or
containers.
It
just
cares
about.
A
You've
got
a
chunk
of
digital
content.
You
want
to
sign
it.
You
want
to
push
it
up
to
some
metadata
server
and
you
want
to
tell
people
they
can
go
and
download
it
from
there.
So
the
architecture
is
a
client,
that's
the
notary,
CLI.
We
also
have
a
library
that
you
can
use
in
go
at
least
to
implement
notary
into
your
own
applications,
and
we've
defined
an
actual
go
interface
for
the
library,
so
it
should
be
reasonably
clear
by
now.
A
What's
there
for
use
versus
what's
kind
of
internal
for
a
long
time,
we
didn't
have
that
interface
and
nobody
could
work
out
how
to
use
it
properly
as
a
library,
so
I
hope
that
helps
the
client
talks
to
a
server.
It's
a
straight
HTTP
server
has
a
URL
structure
that
is,
and
this
is
maybe
the
one
place
where
darker
does
kind
of
show
up.
The
URL
structure
was
designed
to
be
compatible
with
the
docker
registry.
But
if
you
didn't
know
about
the
docker
registry,
it's
still
a
sensible
URL
structure.
A
It's
essentially
like
repository
name,
slash
and
then
like
the
normal,
tough
sort
of
path
structure.
So
yeah,
it's
not
overly
important.
Anyway.
The
server
deals
with
metadata
signed
metadata.
It
never
sees
any
private
keys,
it
receives
updates.
It
verifies
that
updaters
correct,
particularly
you've,
already
got
some
previously
existing
version
of
the
repository.
You
want
to
make
sure
that
anybody
that
already
has
seen
that
old
version
when
they
go
and
download
your
next
update,
it's
actually
going
to
successfully
successfully
download
and
validate.
A
So
the
server
does
all
those
checks
for
you
to
make
sure
that
a
user
is
actually
going
to
be
able
to
download
your
update
and
then
it
goes
and
talks
to
this
back-end
service
we
created,
which
call
it
the
signer.
The
signer
holds
your
timestamping
key.
The
reason
for
that
is
just
timestamp
thing,
like
we
said,
is
meant
to
happen
very
frequently.
A
It
certainly
needs
to
happen
on
every
single
update,
and
particularly
if
you
have
a
repository
with
lots
of
collaborators,
you
don't
want
to
have
to
delegate
like
a
timestamp
key
for
every
single
one
of
them.
Additionally,
I
think
if
you
come
on
Friday
we'll
talk
a
little
bit
about
what
happens
when
certain
keys
get
compromised,
there's
very
little.
You
can
actually
do
when
a
timestamp
key
is
compromised.
A
B
A
The
signer
itself
has
a
secret
that
you
inject
runtime
that
secret
is
used
to
encrypt
all
of
the
private
keys
before
it
stores
them
in
a
database
for
persistence.
Importantly,
we
implemented
mechanisms
to
be
able
to
rotate
that
secret,
so
that
you
know,
if
you
think,
for
some
reason,
the
secrets
being
exposed.
You
can
change
it
and
you
can
force
the
signer
to
go
and
Riaan
crypt.
All
of
those
keys,
that's
kind
of
all
of
the
components
of
Notary
like
it's.
A
It's
not
horribly,
complicated,
I
think
there
are
some
things
that
we
would
like
to
do
with
it.
Some
additional
features
we
want
to
build
in
the
seiner,
particularly,
but
also
the
client,
would
benefit
from
integrations
with
hardware
security
modules.
We
have
a
Yubikey
integration
in
the
client
which
uses
pkcs
11
and
only
works
for
root
keys.
Some
weird
reasons
behind.
A
Why
that's
the
case
and
we
never
got
around
like
expanding
it,
to
be
used
for
sort
of
developer
keys
essentially,
but
the
hardware
integrations
would
really
sort
of
make
this
an
enterprise
product
for
a
lot
of
use
cases.
A
lot
of
organizations
require
that
any
online
private
key
sitting
on
HSM
we'd
also
like
local
file
based
repo
management.
Essentially,
the
client
requires
that
there's
a
server
and
there
are
some
people
who,
like
I,
just
want
to
do
things
locally
and
I'll
worry
about
the
server
myself
all
the
capabilities
to
do
that
are
inside
notary.
A
We
can
consume
them
quite
happily,
and
we've
got
the
tests
to
make
sure
that
all
of
that
works.
What
we
had
issues
with
is
the
whole
user
experience
on
the
signing
side,
so
it's
like,
if
just
then
I
both
need
to
sign
something-
and
maybe
there's
a
third
member
of
our
team
that
we
also
work
with,
and
this
requires
two
out
of
three
signatures
like
if
I
produce
a
new
piece
of
content
and
I
sign
it
and
I
send
it
to
just
and
say:
hey
Justin.
Can
you
please
sign
this?
A
For
me,
the
third
person,
the
team-
might
be
doing
the
same
thing
at
the
same
time
and
that
creates
contention,
and
we
don't
really
have
a
good
way
of
dealing
with,
like
the
human
user
experience
of
dealing
with
that
contention.
So
if
anybody
has
any
ideas
about
that,
if
anybody's
worked
on
similar
problems,
we'll
also
talk
about
more
like
why
this
is
the
case
and
why
the
contention
exists
in
the
deep
dive
on
Friday,
because
it
dives
into
like
the
actual
data
structures
and
how
tough
solves
problems
on
sort
of
the
very
I
guess
implementation.
A
Specific
level
yeah
would
be
very
interested
in
having
discussions
on
that.
If
interests
and
learning
more
like
I
said
we
have
the
tough
notary,
deep
dive
on
Friday
at
11:55
in
B
for
m1,
which
is
somewhere
on
this
side
of
the
building
I
highly
recommend.
You
read
the
tough
specification
if
you're
interested
it's
not
that
long,
even
if
you're,
just
flying
somewhere
close
in
Europe
I'm,
pretty
sure
you
can
read
it
on
your
plane
flight
and
it's
actually,
it's
very,
very
clear.
A
I
would
say
it's
one
of
the
easiest
specifications,
I've
actually
read
and
then
obviously
there's
the
notary
repository
and
we
have
more
documentation
in
there
on
specifically
how
notary
works
under
the
docs
folder.
If
you're
interested
I'm
also
proud
to
say
that
when
I
had
a
new
developer
start
on
the
team
at
docker,
I
got
them
to
install
notary
as
their
first
project
to
show
how
awesome
both
go
and
docker
are,
because
you
can
literally
just
go,
get
the
repo
CD
into
it.
A
Docker
compose
up
and
the
go
get
will
have
installed
notary
the
dark
compose
up,
brings
everything
up
and
you
have
a
completely
working
local
environment.
So
if
you
want
to
play
with
it,
notary
is
really
simple:
to
get
up
and
running,
that's
what
we
had
I
think
we
have
a
little
time,
yeah
about
five
minutes
or
so
for
QA.
B
B
Question
is:
what's
the
difference
between
a
target
and
snapshot.
So
target
is
a
way
of
saying
that
this
specific
instance
of
this
software
is
a
valid
piece
of
software.
So,
if
you
think
about
like
GPG
signing
a
package
that
equivalent
action
is
putting
a
line
in
your
targets,
file
that
says
I
say
this.
Secure
hash
of
this
file
is
valid,
and
then
you
sign
that
whole
file,
the
snapshot
role,
is
effectively
a
global
way
that
an
entire
repository
says
the
latest
version
of
package
a
is
1.0.
B
The
latest
version
of
package
B
is
3.2
and
so
on.
So
this
is
a
file,
that's
that's
not
generated
by
the
individual
developers,
but
is
collectively
trying
to
prevent
you
from
having
like
a
repository.
That's
taken
over.
Tell
you
oh
yeah,
you
know
oh
you're
looking
for
send
mail.
Well,
the
latest
version
is
0.1.
B
B
Okay,
it
signs
basically
a
hash
over
the
you
know
over
everything
and
the
reason
why
timestamp
like
there's
a
couple
reasons
why
they're
separate,
but
one
of
the
reasons
why
they're
separate
is,
is
that
in
some
deployments,
people
who
do
things
like
have
mirrors
will
give
the
mirrors
the
timestamp
role,
but
not
the
snapshot
role,
because
there's
only
sort
of
you
know
the
like
the
global
signing
operation.
You
know
in
collection
of
data.
That's
coming
comes
through
a
single
source
that
then
snapshot
signs.
A
A
Just
sat
a
talk
from
IBM
who've,
just
opened
saw
sign
called
porty
eros,
which
is
essentially
their
version
of
they.
Actually
they
took
notary.
It's
the
version
of
a
client
that
the
signature
validation
when
you
deploy
onto
a
kubernetes
cluster
as
far
as
I
understand
that
it
only
works
in
like
bluemix
cloud
or
something
there's
also
collide,
which
do
like
a
commercialized
OS,
query
type.
You
know
hosts
monitoring
scanning
type
thing.
They
implemented
notary
for
the
software
updater
of
like
OS,
query
on
your
hosts
and
then
there's
see
all
of
the
automotive.
A
B
I'm
all
Haskell,
there's
there's
a
bunch
of
them
and
even
our
reference
implementation
David
is
completely
right
that
it
wasn't
production
ready.
It
has
gotten
a
lot
better
to
the
point
that
we're
gonna
have
a
very
serious
deployment.
That's
that's
using
it
very
soon
yeah.
So
there's
there's
a
lot
of
choice
out
there
and
if
you
are
looking
for
an
implementation
that
has
certain
properties
or
does
certain
things
that
the
that
notary
or
the
reference
implementation
don't
and
just
reach
out
to
us,
and
we
may
be
able
to
connect
you
with
the
right
people.