►
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 Deep Dive – David Lawrence, Docker & Justin Cappos, NYU, TUF (Intermediate Skill Level)
This talk provides a deep technical dive into two CNCF projects that focus on secure software distribution, Notary and TUF. Specifically, the session will feature a deep-dive into Notary, showing technical advances added beyond the TUF spec that provide additional protections in the cloud. The session will also examine impending improvements to TUF that will increase its security and applicability to different domains.
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
My
product
managers
told
me
I'm
not
allowed
to
talk
about
signing
and
customer
meetings
anymore,
because
people
glaze
over.
So
this
is
where
you
get
all
of
that
extra
information,
the
in-depth
kind
of
how
do
these
things
actually
get
constructed
and
the
first
part
is
going
to
look
at
these
sort
of
file
structures,
let's
support
notary
and
defined
in
the
tough
spec,
and
then
the
other
part
of
this
talk
is
gonna.
A
Look
at
all
of
the
attacks
that
we're
actually
trying
to
protect
you
against
and
sort
of
link
that
back
to
why
certain
things
exist
and
appear
in
those
files
so
just
quickly
who
came
to
the
intro
session
on
Wednesday,
okay,
so
a
couple
of
people
who
feels
like
they
have
a
somewhat
of
a
grip
on
the
update
framework
like
who's
read
it
who's
played
with
notary
they've
played
with
some
other
variation.
Okay,
so
this
is
gonna,
be
really
dense
and
there
may
be
some
bits
that
don't
make
complete
sense,
I
apologize
for
that.
A
We
kind
of
built
this
to
lead
on
from
the
intro
session.
So
starting
off
with
a
little
bit
of
recap,
the
update
framework
is
based
on
a
key
hierarchy.
You
have
a
root
key,
this
anchors,
your
trust,
you
would
provision
this
when
you
download
the
software
or,
when
you
download,
say
the
Linux
distribution
that
might
be
using
the
update
framework
for
its
package
manager.
That
root
key
is
then
used
to
sign
other
keys,
target's
key
snapshot.
A
Key
timestamp
key
are
the
sort
of
key
the
key
keys
they're,
the
main
ones
that
you
have
to
think
about
targets.
Keys,
are
used
for
signing
actual
software
packages.
Snapshot
keys
are
used
for
giving
you
an
overall
view
of
like
where
has
there
been
an
update
within
the
system?
It's
like
which
packages
which
areas
have
been
updated
and
then
the
timestamp
key
just
tells
you.
Has
there
been
an
update
and
there
are
files
associated
with
each
of
these
keys.
A
You
know
like
in
toto
which
is
another
project,
and
maybe
there's
a
group
called
tough,
which
is
responsible
for
signing
packages
related
to
the
tough
project,
and
these
delegations
can
go
any
depth
down.
So
the
tough
project
key
here
could
further
delegate
down
to
members
of
that
project
with
specific
permissions
on
what
they're
allowed
to
sign
so
this
hierarchy,
you
know
this
hierarchy.
Sort
of
is
also
supported
by
a
hierarchy
of
metadata
verification,
and
this
is
really
checksums.
Is
anybody
familiar
with
Merkel
trees,
okay,
few
people
so
Merkel
trees?
A
Are
this
idea
of
taking
a
tree
structure
and
starting
from
the
leaves
you
generate
checksums
and
then,
as
you
go
up,
each
node
contains
a
checksum
essentially
of
the
data
underneath
it
and
by
the
time
you
get
to
the
top
of
the
tree,
you
have
a
single
checksum
that
represents
the
entire
data
structure.
There's
sort
of
TLDR
metadata
verification
in
the
update
framework
is
somewhat
similar.
Starting
from
my
root
file.
A
I
have
my
keys,
and
that
was
pinned
when
I
went
and
downloaded
my
software
updater
through
whatever
mechanism
I
got
that
when
I
then
need
to
go
and
actually
check.
Has
there
been
an
update
within
the
system?
I
start
from
my
timestamp
file,
which
is
a
very
small
piece
of
metadata
that
contains
a
checksum
of
my
snapshot
and
my
snapshot,
which
is
why
it
has.
This
name
contains
a
checksum
of
the
other
files
within
my
update
framework
repository
and
that
allows
me
to
efficiently
go
and
see
where
do
I
need
to
go
and
get
updates.
A
So
one
of
these
files
actually
look
like
every
single
file
has
the
same
basic
structure
has
two
fields:
signatures
and
signed,
and
the
signatures
are
signatures
over
the
signed
section
of
the
file.
Now
to
make
sure
this
is
consistent,
you
have
to
use
what's
called
a
canonical
JSON
encoding,
which
does
things
like
orders
all
of
the
keys
by
the
lexicographical
ordering,
so
that
you
can
reliably
serialize
the
JSON
and
regenerate
the
signature
to
verify
that
it's
correct
within
sorry.
Some
of
the
spacing
got
messed
up
here
within
signatures.
We
have
list
an
array
of
signatures.
A
Each
entry
contains
the
key
ID,
which
is
a
sha-256
of
the
public
key
data.
It
contains
the
method
that
was
used
for
signing
and
it
contains
the
signature
itself
and
within
a
given
implementation
of
the
update
framework,
you
can
decide
what
your
encodings
are
going
to
be.
For
these,
for
example,
notary
is
implemented
in
Go
Go
by
default.
A
Has
a
really
nice
feature
where
any
byte
slices
that
you
put
into
a
JSON
object
automatically
get
base64
encoded,
so
we
use
base64
encoding
for
a
lot
of
stuff
just
because
it's
really
simple
to
do
and
go
like
for
notary,
but
you
could
use
hex
encoding.
You
could
use.
You
know
whatever
happens
to
be
your
choice
there.
A
The
signed
component
contains
a
lot
of
data,
but
in
particular,
every
single
file
contains
these
three
key
fields
contains
a
type
this
tells
us
what
the
structure
of
the
rest
of
that
signed
field
is
going
to
look
like
and
there's
a
type
for
each
of
those
main
four
roles.
We
store
it.
That's
at
the
starts,
there's
a
route
type
of
the
targets
type
and
a
snapshot
type
at
a
timestamp
type.
All
of
the
delegations
that
I
mentioned
they
all
have
the
targets
type,
those
those
files
are
all
structurally
the
same.
A
We
then
have
an
expiry
time.
How
long
is
this
file
valid?
For
at
what
point
should
we
consider
that
I'm
not
going
to
trust
anything
inside
this
file,
and
this
will
be
important
in
some
of
the
attacks
that
get
discussed
later
and
then?
Finally,
we
have
a
version
and
the
version
is
just
an
increment
encounter.
A
Every
time
we
publish
an
update
to
the
file
we
bump
it
up
by
one
and
again,
this
is
to
protect
against
some
specific
attacks
that
we'll
talk
about
later,
but
every
single
one
of
our
files
contains
these
three
fields
under
the
signed
section,
depending
on
what
type
we
have
so,
whether
its
targets
route
snapshot
timestamp,
we
then
have
specific
additional
fields,
so
if
it
is
anything
but
the
route,
we
have
this
target
section,
and
this
defines
other
pieces
of
content
in
the
timestamp
file.
Our
target
section
tells
us
about
the
snapshot
in
our
snapshot
file.
A
The
target
section
tells
us
about
the
other
roles
within
our
repository,
but
in
a
targets
file
or
in
a
delegation
file.
This
target
section
tells
us
about
the
actual
packages
that
we
want
to
go
and
download.
This
would
tell
us
you
know
there
is
an
open,
ssl
package
and
then
from
that
it
gives
us
the
hashes
and
it
supports
multiple
hashes
so
that
you
can
do
clean
upgrades.
A
You
can
sort
of
future-proof
yourself,
but
additionally,
if
you
have
multiple
check
sums
in
there,
the
expectation
on
a
client
downloading
and
verifying
a
package
that
they
verify
all
of
those
check
sums
not
just
one
of
them.
So
that
means,
if
you
have
a
situation
where
you
know
one
particular
checks
like
maybe
tomorrow,
sha-256
has
a
vulnerability
discovered
and
suddenly
it's
really
easy
to
generate
files
that
will
collide
on
a
sha-256
well,
because
I've
got
multiple
hashes
in
there.
I
can
protect
myself
against
a
weakness
in
anyone
hashing
algorithm.
A
Additionally,
you
get
the
length
which
is
the
size
in
bytes
of
the
file
that
you
would
actually
go
and
download
again.
This
is
another
case
of
protecting
you
against
some
interesting
attacks
that
we'll
discuss
in
a
minute
and
then
there's
a
custom
field,
and
the
custom
field
is
really
for
you
to
put
in
whatever
information
you
feel
is
useful.
You
typically
want
this
to
be
a
small
piece
of
metadata.
A
As
an
example,
at
docker
we
did
a
funnel-like
hack
day
projects
where
we
actually
built
an
entire
like
desktop
application,
download
or
an
up
data
based
on
the
update
framework,
and
we
crammed
the
information
for
the
icon
and
you're
like
menu
entry
into
the
custom
field.
So
you
could
go
and
like
get
all
your
tough
data,
get
a
get
a
checksum
of
the
application,
executable
binary
that
you're
about
to
download
and
use
the
data
in
the
custom
field
to
install
the
menu
entries.
So
you
can
kind
of
you
can
put
whatever
you
want
in
there.
A
A
Sorry,
the
formatting
got
all
screwed
up
in
this
again,
so,
depending
on
whether
the
type
is
root
or
targets,
the
keys
appear
in
slightly
different
places,
and
these
are
the
public
keys
right.
These
are
so
they
can
go
to
that
key
hierarchy
and
verify
particular
roles
against
particular
keys.
This
defines
which
keys
I
should
be
using
now
in
the
root
file.
A
These
entries
on
the
right
here,
the
keys
entry
and
the
roles
entry
appear
directly
under
signed,
like
directly
under
our
top-level
signed,
see
I
lost
my
mouse
so
directly
under
this
top-level
sign
field,
but
if
it's
a
target
type
entry,
this
is
where
we're
getting
into
signing
packages.
So
we
want
sort
of
sub,
classify
and
say
they
appear
under
delegations.
These
are
the
keys
that
I'm
delegating
package
signing
to
in
some
capacity
and
when
we
define
them
the
keys
field
just
lists
the
keys
says
this
is
the
key
ID.
A
The
key
ID
is
a
typically
a
sha-256,
but
again
you
could
forgive
an
implementation.
You
could
choose
your
own
hashing
other
algorithm,
but
it's
a
hash
over
this
JSON
structure
that
it
references
so
again
use
a
canonical
serialization
that
ensures
you
have
an
ordered,
reliable
serialization
of
your
JSON
structure,
and
then
you
take
a
checksum
of
essentially
these
key
type
and
key
Val
fields
which
gives
you
look
at
the
type
of
the
key
and
the
public
key
bytes
and
whatever
your
serialization
of
choices,
we
then
reference
those
keys
under
roles
and
in
our
root
file.
A
The
roles
are
going
to
say,
you
know,
root
snapshot,
targets,
timestamp,
it's
going
to
be
those
call
roles
to
my
system,
but
for
my
delegations
these
roles
can
be
anything.
You
know
the
roles
are
going
to
be
David
they're,
going
to
be
Justin.
They're
gonna,
be
the
update
framework
project,
maintainer
z',
it's
just
a
name
for
a
delegation
that
is
easily
identifiable
to
you.
Like
your
niece.
It
should
mean
something
to
you
for
that
role.
We
identify
the
key
IDs
and
in
a
given
file,
you
have
to
have
those
match
so
right.
A
If
a
key
ID
is
listed
under
a
role,
it
needs
to
be
in
the
list
of
keys
in
that
same
file.
You
can't
reference
a
key
that
appeared
somewhere
else
in
the
system
and
you
can
have
multiple
key
IDs
that
allows
you
to
have
multiple
signers
on
a
given
role.
If
you
want
to
collaborate
with
other
people,
you
also
have
a
threshold.
A
Every
single
role
in
the
update
framework
supports
multiple
signers,
so
you
could
have
say
three
Keys
listed
under
the
key
IDs
and
a
threshold
of
two
and
then
you
would
always
require
any
two
of
those
three
keys
to
have
signed
before
the
role
becomes
valid.
Now,
if
you
are
defining
this
under
a
targets
type
file,
you
also
have
this
paths
entry,
and
this
allows
you
to
restrict
the
names
of
packages
that
people
can
sign
for.
A
So,
for
example,
if
I'm
only
meant
to
be
signing
notary
packages,
I
can
put
a
rule
under
the
pass
that
says
for
this,
given
role
that
represents
myself,
David
I
am
only
allowed
to
sign
packages
that
are
prefixed
with
notary
or
even
have
you
know
the
full
name
of
like
notary.
You
know
1.0.0
I
can
either
do
a
sort
of
prefix
with
a
star.
You
know
just
a
simple
like
splat
or
I
can
do
a
full
like
this
is
the
specific
package
name
that
you
can
sign.
A
There
is
another
there's
like
a
hashed
package,
name
version
of
this
that
I
intentionally
left
out,
because
that
gets
to
like
very
easy
Taric.
But
if
you
have
enormous
package
repositories,
you
can
also
restrict
the
actual
hash
prefix
of
the
package
name
and
that
enables
you
to
shard
very
large
repositories
to
make
your
updates
faster
so
that
no
one
of
your
targets
or
delegations
files
gets
too
large.
A
Now
this
all
seems
like
a
lot
of
work
right
package.
Signing
up
to
now
is
being
take
a
GPS
EIN,
something
with
it
throw
the
package
and
the
signature
up
on
the
internet.
Maybe
publish
your
public
GPG
key
on
your
website.
Great
I'm
done
there's
a
lot
of
problems
with
that
a
lot
of
pro.
So
you
know,
why
are
we
doing
this
well
I'm
gonna
hand
over
to
Justin
and
he's
going
to
explain
all
of
the
things
you
should
be
really
afraid
of,
because
you
should
thanks.
B
If
you
have
a
question
or
something
that
you
want
to
talk
about,
and
you
think
it
can
be
kind
of
concisely
answered
in
the
flow
of
the
talk
feel
free
to
raise
your
hand
or
you
know,
say:
hey
wait
a
minute.
What
about
this,
while
I
go
through
these
okay?
So
alright,
there
exists
this
great
attack
vector
that
you
know,
has
all
these
interesting
properties.
Here,
it's
basically
on
every
type
of
device.
It
gives
you
basically
unlimited
privileges,
defenses,
don't
work
very
well!
B
Failed
attacks,
look
benign,
and
it's
used
by
nation-state
actors
to
launch
massive
attacks
and
since
you're
in
this
room
now
you
can
probably
guess
that
we're
talking
about
software
updater
based
attacks
right
and
there
have
been
a
long
history
of
these
I
used
to
have
a
slide.
I
used
to
have
a
slide
that
showed
logos
of
major
tech
companies
and
asked
people
what
do
all
these
tech
companies
have
in
common
and
they
all
have
had
software
updater
based
attacks,
you
know
so
there.
B
This
is
something
that
is
increasingly
happening,
is
increasingly
out
there
and
should
be
a
major
major
concern
to
different
parties.
So
we
absolutely
absolutely
absolutely
need
to
protect
against
these
okay.
So
now
I'm
gonna
kind
of
walk
you
through
and
let's
look
at
some
really
basic
attacks
and
really
basic
scenarios.
So
just
imagine
for
a
moment
that
you
have
some
kind
of
software
repository
where
there's
a
server
there
that's
serving
packages
out,
and
let's
say
that
you
know
you
don't
do
really
anything.
B
One
interesting
attack
is
to
just
send
endless
data
when
somebody
comes
to
request
a
software
update
just
like
keep
sending
them
data,
don't
close
the
connection
doesn't
really
matter
what
you
send
as
long
as
you
match.
If
they
do
some
initial
parsing
or
something
just
you
know,
match
that
format
and
then
just
blast
data,
and
this
seems
really
silly
like
I
mean
who
would
have
an
update
err
that
would
have
problems
if
you
send
it
endless
data.
Well,
there's
a
couple
of
examples
that
are
ones
that
I
found
in
my
research.
B
This
is
that
these
examples
are
about
ten
years
old
by
the
way
they've
all
been
patched
but
apt
had
this
interesting
problem
that
you
know
you
go
and
you
send
it
an
endless
amount
of
data
and
it
would
completely
fill
memory
on
your
system,
and
so
your
server
would
slow
down,
slow
down
and
start
paging
and
then
effectively
just
just
stop,
and
so
obviously
this
is
really
bad.
You
don't
need
to
send
all
that
much
data
over
you
know.
B
If
you
have
a
reasonable
network,
you
don't
need
to
send
all
that
much
data
in
order
to
cause
a
system
to
crash
which
yeah
you
look
at
this.
You
say
this
is
silly.
They
should
have
caught
this,
but
it
wasn't
unique
to
them
so
yum
did
it
as
well
and
instead
of
filling
up
memory,
they
actually
filled
the
disk
and
filling
the
disk
as
root,
which
is
what
yum
usually
runs,
as
is
not
a
good
thing
in
case
anyone's
not
clear
on
that,
you
know.
That's
that's
one
takeaway!
B
You
can
bring
back
when
you
go
home.
So
it
would
download
the
entire
update
first,
writing
it
all
the
disk
and
then
it
would
crash
and
it
would
crash
without
being
able
to
syslog
or
printing
any
output,
or
anything
like
that.
So
you
would
literally
you
know,
because
a
lot
of
times
you
run
yelman
an
automated
way.
You
would
run
it
in
an
auto
Midway
and
all
the
sudden
your
system
would
would
crash.
And
then,
if
you
tried
to
reboot
it,
it
would
have
problems
starting
up.
B
Even
if
you
were
looking
at
the
terminal,
it
didn't
print
anything
it
just
exited,
so
those
yeah,
those
are
obviously
really
bad.
So,
by
the
way
this
this
style
of
attack
is
why
you
need
things
like
you
need
the
size.
You
need
to
know
the
size
of
the
thing
you're
trying
to
download.
So
when
David
was
talking
about
that
before
that's
what
he
was
referring
to,
there's
a
lot
of
other
really
interesting
attacks.
B
That
I
could
like
give
a
whole
interesting
talk
on,
but
there's
attacks
that
relate
to
things
like
zip
bombs,
where
you
give
people
things
that,
oh
sorry,
go
ahead.
Yes,
what
about
Alpine?
We
haven't
gone
and
done
back
like
ten
years
ago,
when
we
were
working
with
the
different
Linux
package
managers
and
others.
We
did
an
assessment
of
the
ten
most
popular
package
managers.
B
We
haven't
redone
that
assessment,
but
the
but
aptiom
you
asked
impact
man
all
used
the
security
model
that
we
recommended
from
my
from
my
dissertation
work
in
the
way
they
did
updates
with
adding
you
know,
hashes
and
signatures
and
timestamps
and
lengths
and
stuff
in
the
right
areas.
I
don't
specifically
know
about
alpine,
but
maybe
david
does.
A
So
what
I
can
say
about
Alpine
is
the
maintainer
works
at
docker
and
we're
talking
to
him
about
getting
notary
implemented
as
the
update
the
signing
system
for
apk.
So
it's
not
that
yet
the
key
requirement
for
him
is
that
we
make
him
a
client.
That's
really
really
tiny.
You
know
in
the
order
of
like
double
digit
kilobytes,
so
I'm,
trying
to
work
out
how
you
make
a
go
binary
that
small
but
we'll
get
there.
B
Thank
you
very
much
yes,
and
by
the
way,
if
you
are
doing
something
like
a
package
manager,
then
you
shouldn't
be
piecemeal,
adding
the
thing
that
I
propose
that
you
add
ten
years
ago,
you
should
actually
be
using
tough
for
annual.
This
will
become
clear
at
the
end
of
the
talk
like
kind
of
the
evolution
and
what
happened.
There's
a
bunch
of
issues
with
zip
bombs
and
there's
actually
a
whole
bunch
of
really
interesting.
B
Issues
like
this
is
one
that
I
like
I
like
to
bring
this
one
up,
because
this
was
I
had
a
student
who
worked
on
tough
and
like
a
month
after
he
left
me
to
go
work
for
Google.
This
vulnerability
became
publicly
disclosed
and
known
from
that.
He
discovered
this
as
part
of
their
so
I
imagine
it
was
like
day
one
and
he
walked
in
and
was
like.
Let
me
try
this
out.
There's
this
really
interesting
thing.
B
B
You
know
you
can
put
foo
and
bar
in
the
same
zip
file,
of
course,
but
you
can
actually
put
a
foo
and
then
you
can
put
another
file
name
foo
in
the
same
zip
file,
and
it
turns
out
that
when
Google
was
checking
signatures
and
the
the
uncompressing
process
were
unpacking
the
files,
the
uncompressed
process,
I
if
I
remember
correctly,
used
the
second
version
of
the
file.
That
was
the
one
that
would
write
to
disk,
whereas
the
verification
would
check
the
first
file.
B
So
you
could
stick
anything
you
wanted
in
and
then
you
know
put
it
in
an
APK
but
yeah.
So
and
then,
of
course,
you
know,
there's
the
trivial
thing
you
can
do
if,
if
they're
not
using
signatures,
as
as
I'm
talking
about
an
example
here,
where
you
can
just
arbitrarily
modify
files,
if
there's
no
signatures,
there's
no
crypto.
This
is,
of
course,
a
big
problem,
but
there's
a
lot
more
interesting
things
you
can
do
when
you
start
to
use
some
encryption.
So
of
course
hey
just
use
encryption.
B
Well,
it's
not
that
easy
as
we'll
see
in
a
minute
so
packages
have
these
things.
And
software
has
this
thing
called
a
version,
as
we
all
know
and
versions
are
actually
a
really
important
thing.
So,
just
for
the
moment
just
to
make
this
talk
like
fit
in
the
allotted
time
and
things
I'll
say
that
I
could
give
an
entire.
B
So
there
are
problems
that
you
can
do
is
you
can
often
go
and
either
revert
packages,
so
a
lot
of
package
managers?
If
you
ask
it
for
a
version
of
a
package,
you
give
it
an
older
one
than
the
one
that's
installed.
It'll
still
actually
install
that
silently.
That
says
this
is
a
surprisingly
common
bug,
but
it's
not
a
hard
one
to
fix.
Let's
say
that
you
you
go
and
you
require
that
the
user
either
specifically
request
an
older
version
or
you
make
sure
the
version
increases.
B
But
this
is
a
very
real
thing:
that's
out
there
in
the
world,
and
is
you
know
so?
This
is
this
is
a
problem,
so
you
at
least
want
to
be
able
to
detect
this
and
alert
users
that
hey.
You
know
your
government
is
stopping
you
from
getting
security
patches
and
I.
Don't
know
what
they
can
do
about
it,
but
you
at
least
want
them
to
know
something's
going
on.
There's
a
nice
attack.
You
can
do
where.
B
Maybe
it's
maybe
it's
easier.
Sorry,
let
me
think
about
how
to
describe
this
a
different
way.
There's
an
attack.
You
can
do
that's
different
than
a
reversion
attack
where
you
get
somebody
to
install
an
outdated
package
and
the
reason
why
installing
an
outdated
package
is
bad
is
because
usually
the
reason
why
software
is
outdated
is
because
it
has
things
like
security
vulnerabilities
in
it,
and
so
the
you
know
the
being
able
to
give
somebody.
An
old
version
of
a
package
is
in
many
ways
equivalent
to
you
know,
being
able
to
root
or
compromised
their
box.
B
You
can
make
it,
for
instance,
if
you
can
rewrite
metadata,
you
can
make
it
so
that,
for
instance,
all
of
the
metadata
from
all
your
packages
depends
on
something
like
an
outdated
version
of
send
mail,
that's
8
years
old,
and
then
with
that,
what
you'll
be
able
to
do
then
is
they'll,
install,
send
mail
as
part
of
their
installation
process
for
the
packages
and
then
you'll
be
able
to
go
in
and
route
their
box,
so
yeah.
So
there's
a
lot.
B
You
can
do
to
do
this,
that
we
we
talk
about
and
we
fix
the
the
all
the
things
that
I've
described
up
to
this
point.
I
know:
I
went
a
little
quickly
through
this.
I
can
go
through
and
talk
about
some
of
these
other
attacks
there
they're
kind
of
cute
and
so
on,
but
they're
much
more
focused
on
people
who
are
doing
things
with
package
managers,
then
on
doing
installation
for
things
like
cloud
environment,
the
real
thing
that
tuff
does
that
goes
beyond
what
these
other
models
do.
B
Is
it
handles
situations
where
you
have
a
key
compromise,
so
the
goal
of
tough
is
to
is
to
assume
that
there's
actually
going
to
be
an
attacker
somewhere
in
your
infrastructure,
they're
either
gonna
steal
a
key
they're
gonna
break
into
a
repository
they're,
maybe
going
to
bribe,
or
even
just
be
one
of
your
developers
or
one
of
your
people.
And
what
can
you
do
to
keep
the
most
security
possible
in
those
kinds
of
scenarios?
B
So
first
I'll
talk
a
little
bit
about
things
that
you
shouldn't
hopefully
be
using
to
do
this,
but
some
people
want
to
try
to
use
something
like
GPG
or
some
other
type
of
asymmetric
key
signing
or
they
just
basically
say
we're
gonna.
Stick
it
up
on
a
server
with
TLS
and
then
yeah
great.
So
the
good
thing
about
using
TLS
is
as
easy
to
setup
the
bad
things
are
numerous,
but
they
you
know
they
don't
say
anything
about
the
security
of
the
server.
They
don't
say
anything
about
the
security
of
the
package.
B
They
just
tell
you
you're
actually
talking
to
that
endpoint.
So
if
an
attacker
breaks
into
your
repo,
as
has
happened
with
you,
know
dozens
of
companies,
then
they
can
go
and
they
can
serve
whatever
software
they
want.
So
this
is
really
bad
and
there's
lots
of
ways.
You
know
lots
of
ways
that
they
can
get
in
and
mess
around
with
either
intercepting
the
connection.
If
you
plug
into
the
traditional
see
a
system
which
has
pros
and
cons
in
this
domain,
then
you
know
they
may
be
able
to
you
know
to
mess
around
with.
B
You
know
at
the
fact
that
you're
trusting,
didja,
notre
CA
or
doing
other
things
like
this
may
be
able
to
to
interfere
that
way,
not
that
you
know
we
would
have
seen
certificates
for
software
update
based
sites
in
the
wild
from
digit,
noter
and
iran,
or
anything
like
that.
You
know,
but
anyway,
so
there's
lots
of
different
ways
to
use
this
to
get
in.
There's
lots
of
different
types
of
attacks,
there's
lots
of
weaknesses
that
people
have
found
in
different
implementations.
B
It
is,
you
know,
very
difficult
to
make
this
code
so
bullet
proof
that
it's
infeasible,
you
know,
I,
don't
think
it's
going
to
be
something
where
security
experts
should
be
comfortable
with
the
fact
that
a
single
problem
somewhere
in
TLS
could
result
in
somebody
being
able
to
basically
route.
You
know
any
computer,
they
like
on
the
internet,
that
they
can
intercept
that
communication,
for
they
software
update
related
communication.
So
this
is
what
you're
using
I
would
strongly
suggest.
Not
not
doing
this.
Please
please
don't
you
can
also
do
things
with
GPG
and
RSA.
B
What
you
do
is
you
sign
things
with
keys
like
you'll,
either
have
a
build
server
or
some
other
type
of
server
that
people
log
into
that
then
has
the
one
true
magical
key
that
everything
is
signed
with,
or
you
have
a
model
where
all
the
developers
that
are
supposed
to
be
able
to
produce
software
have
their
key
in
some
key
ring.
And
then,
if
it's
signed
by
the
one
of
the
developers,
then
you
trust
it
and
there's
a
whole
bunch
of
problems
with
both
of
these
approaches.
B
As
as
you
know,
we've
heard
about
in
the
news
you
know.
So
you
know
there's
like
the
fedora
break-ins
to
their
build
server
where
someone
stole
their
signing
key
and
then
they,
when
they
added
an
HSM
and
then
something
like
six
to
eight
months
later,
someone
broke
in
again
and
this
time
the
attacker
wasn't
able
to
take
the
key
and
run
away
with
it.
This
time
they
had
to
upload
their
malicious
versions
of
OpenSSH
and
other
packages
onto
the
build
server
and
sign
them
on
there,
but
it
didn't
really
solve
the
problem.
B
If
you,
if
you
go
and
let
all
the
developers
who
have
their
keys
sign
it
you're
effectively,
letting
all
those
developers
sign
all
the
packages
that
you
distribute.
So
if
all
of
a
sudden
you
decide,
you
want
to
trust
someone
to
do
the
Polish
language
documentation
for
some
obscure
package,
then
they
can
also
sign
your
version
of
the
Linux
kernel
and
be
trusted
for
that.
So
there's
there's
some!
You
know.
Let
me
just
say
you
know
there
are
some
downsides
to
that
approach.
To
and
handling
key
compromises
is
something
that
doesn't
work.
B
I
think
we
all
know
that
it
doesn't
work
very
well
in
the
web,
handling,
revocation
and
things
like
that,
and
it
also
doesn't
work
well
in
these
models
to
like
what
do
you
do
so
what
people
typically
do
is
they
say?
Hey.
We
just
sent
an
email
out.
We
got
our
key
compromised,
but
you
know
hey.
We
just
signed
a
new
package
that
has
our
new
key.
We
sign
it
with
our
old
key,
so
please
come
try
to
get
it
from
us
soon
before
the
attacker.
B
You
know
signs
a
similar
package
and
gets
it
into
our
infrastructure
or
convinces
you
to
install
it.
So
it's
a
mess
all
right
so
yeah.
So
what
tough
is
all
about
like
the
design?
The
purpose
of
tough
is
to
be
key
compromised,
resilient
and
the
way
I
started
to
think
about
this
is
I
actually
had
some
folks
from
the
Tor
project.
Calm
and
they'd
read.
B
You
know
some
of
the
the
papers
and
followed
some
of
the
work
I've
done
with
securing
the
Linux
package
managers
and
they
said
you
know
we're
really
worried
about
nation-state
actors,
we're
worried
about
a
compromise.
Can
you
help
us,
and
so
they
came
and
they
sat,
and
they
said
you
know
hey.
We
know
not
to
do
this.
So
what
about
this
and
I
kept
kind
of
like
going
back
and
forth
and
asking
questions,
and
they
came
up
with
this
nice
design?
B
They,
you
know
they
spent
a
few
days.
We
worked
on
some
bits
together
and
they
came
back
and
said
we
designed
the
system.
Can
you
do
a
security
audit
of
it
and
we
did
and
we
found
seven
serious
vulnerabilities
in
their
system,
including
several
that
would
have
let
any
man
in
the
middle
root
all
there's
all
of
their
clients,
and
these
were
not
things
like
I
mean
some
of
them.
B
You
know
some
of
the
things
were
design
errors
like
fundamental
design
errors
in
the
way
that
they
had
set
up
the
system
and
what
they
had
made
it
do
where
they
thought
they
were
getting
guarantees
that
they
weren't
getting.
So
at
that
point,
I
worked
with
a
student
of
mine
and
developed
tough.
We
work
to
make
tough,
which
is
supposed
to
be
an
update,
or
that
you
can
go
and
drop
into
your
existing
software.
B
That's
supposed
to
be
have
sane,
secure
default
and
effectively
supposed
to
you
know
make
it
so
you
don't
have
to
go
through.
You
know,
step
by
step
like
do
I
need
version
numbers
where
do
I
need
hashes,
so
we
don't
have
to
sit
and
audit
a
million
different
implementations
of
this
and
keep
telling
people.
Oh,
you
forgot
to
sign
this
this
way
or
do
that
and
as
David
really
eloquently
talked
about,
he
talked
about
the
nice
little
setup.
B
B
You
know
like
in
the
last
hour
that
that
key
you
can
keep
online
in
in
a
less
secure
way
than
one
that
serves
as
something
as
a
root
of
trust,
which
you
might
be
able
to
do,
want
to
do
things
with
and
keep
them
offline
in
safety,
deposit
boxes,
or
you
know
at
least
in
the
desk
drawer.
You
know
a
lock
desk
drawer
that
you're
developing
first
have
access
to
and
the
developers
themselves
might
have
UV
keys
that
they
that
they
will,
you
know,
only
use
where
they
need
to
sign
new
releases.
B
B
So
you
don't
have
to
have
like
a
single
trusted
key
you
can
make
it
so
that
three
out
of
five
Keys
have
to
sign
something
or
whatever
else.
This
also
makes
doing
key
key
rotation
and
similar
functionality
like
that,
a
lot
more
seamless
and
finally,
revocation
was
a
primary
design
goal
from
the
very
beginning
of
everything
we
did
in
tough.
We
thought
very
very
hard
about
this,
and
this
was
not
something
that
was
tacked
on
to
the
end.
B
So
there's
multiple
ways
that
you
can
do
replication
either
explicitly
by
writing
a
metadata
or
you
can
set
metadata
to
expire
at
different
times,
because
once
again,
our
assumption
is
is
that
there
will
be
a
bad
guy
somewhere
in
your
infrastructure.
How
can
we
help
you
recover
from
this
in
the
best
way
possible
and
here's
an
instantiation?
This
graph
is
an
example
about
how
the
Python
community
is
standardized
and
standardized
they're
setup,
for
you
know
in
preparation
for
their
deployment
in
their
new
version
of
their
packaging
index
that
called
warehouse.
B
Talk
of
this
talk
with
is
the
fact
that
building
and
a
secure
software
updater
is
not
trivial.
It's
a
very
subtle
problem.
Okay
and
as
I've
had
other
people
who've,
given
talks
that
that
I
haven't
been
present
for,
say:
Justin
has
spent
a
appalling
amount
of
time.
Thinking
about
this
problem,
I
think
was
the
quote,
so
you
know
try
to
I
would
love
to
help
anyone
to
solve
this
issue.
B
A
Think
one
of
my
favorite
points
could
be
just
on
what
you
mentioned
I.
You
have
spent
an
appalling
amount
of
time.
Think
about
these
problems,
but
I
think
was
very
succinctly
put
by
and
I
feel
bad
I
can't
remember
the
guys
name,
but
one
of
the
maintainer
zuv
cabal,
which
is
the
packaged
up
data
for
Haskell.
A
You
know:
Haskell
was
like
one
of
the
first
languages,
I
learned
in
college,
so
it's
near
and
dear
to
my
heart,
but
the
guy
made
a
very
good
comment
that
was
about
you
know
we
don't
trust
sort
of
ourselves
or,
like
you
know,
developers
to
write
cryptographic,
algorithms.
So
why
do
we
trust
them
to
build
secure
systems
like
we
should
be
applying
the
same
principles
that
you
need?
Experts
who've
spent
a
lot
of
time,
thinking
about
and
researching
any
type
of
system
to
tell
us
how
to
make
it
secure.
A
I'll,
just
repeat
the
question
for
the
recordings:
the
question
was:
how
do
people
get
involved
in
notary
and
tough
and
daca
when
they're,
not
necessarily
crypto
experts
well,
I,
think
we've
actually
a
good
job
of
dogfooding,
our
own
sort
of
security
advice
like
we
haven't
written
any
crypto,
we've
built.
You
know
the
the
Jason
structures
you
saw
at
the
start
or
a
collection
of
files
as
defined
in
the
tough
spec,
and
we
leverage
the
crypto
algorithms
that
already
exists.
A
notary,
a
tolling,
go
sort
of
get
involved
in
notary,
there's
actually
very
little
to
do.
A
On
the
crypto
side,
like
we've,
we've
essentially
wrapped
everything
you
would
need
to
interact
with
there.
So
it's
like
you
need
to
generate
key
just
a
function.
You
call-
and
we've
already
done.
You
know
random
number
generation
correctly
and
when
you
generate
your
signatures
to
make
sure
that
you're
not
gonna,
do
anything
silly,
that's
gonna
result
in
you
know
key
compromise
mean
this
is
all
asymmetric
crypto.
So
it's
not.
We
don't
necessarily
have
problems
like
you
reused,
an
IV
and
AES,
and
now
the
entire
key
is
compromised.
You
know
there
are
their
own
problems.
A
A
Okay,
so
the
question
is
like:
how
do
we
make
it
easy
to
sense,
create
like
an
app
store
for
kubernetes
kind
of
thing,
so
that
you
like
a
one-click,
go
and
install
this
thing
on
my
cluster?
One
of
the
ideas
that
we've
been
investigating
in
docker
is
the
idea
of
signed
spec
files.
So
you
could
go
to
a
some
kind
of
portal
and
there
would
be
like
oh
I
want
to
buy
I,
don't
know.
A
What's
a
good
example,
some
kind
of
like
you
know
massively
complex,
like
s
AP
product
with
ten
different
services
that
all
need
to
come
up
and
talk
to
each
other
and
what
you
would
actually
go
is
you'd
use
something
like
notary
to
sign
the
spec
files.
Those
would
all
be
pinned
to
specific
hashes
of
images
that
you're
going
to
download
and
through
that
you
could
base
like
get
maybe
a
zip
file,
maybe
not
a
zip
file.
You
could
get
some
kind
of
serialized
form
of
the
spec
files
that
assigned
the
signatures.
A
Let
you
confirm
that
they
really
did
come
from
the
publisher
of
that
content
through
all
of
the
systems
that
we've
just
talked
about,
and
there
might
be
some
mechanism
in
kubernetes
to
just
say
like
here
is
a
full
definition
of
multiple
pod
services
security
context.
All
of
it
go
and
deploy
that,
for
me,
I'll,
say:
there's
a
you
can
probably
find
it
under,
like
my
github
account
as
this
really
silly
project
we
built
called
conman
container
manager,
which
was
basically
that,
but
for
your
desktop,
so
we
install
a
scheme
handler
use
notary
to
sign
everything.
A
It's
kind
of
what
I
talked
about
earlier
with
the
menu
entries,
but
it
ultimately
meant
you
had
a
website.
You
could
go
to
and
just
click
a
button
and
using
signed
packages
through
notary
it
would
actually
download
a
container
and
run
applications
like
Spotify,
Adam
chrome
in
a
container
on
a
Linux
desktop.
As
far
as
you
were
concerned,
as
a
user,
you
had
a
completely
native
experience.
I
could
imagine
something
similar
where
it's
like.