►
From YouTube: When the Going Gets Tough, Get TUF Going! [I] - David Lawrence & Ashwini Oruganti, Docker
Description
When the Going Gets Tough, Get TUF Going! [I] - David Lawrence & Ashwini Oruganti, Docker
Software distribution and packaging systems are rapidly becoming the weak link in the software lifecycle. In this talk we will look at the security landscape of existing software update systems and signing strategies. We will then introduce The Update Framework (TUF), a new signing framework that looks to address many of the challenges found in existing systems and more.
TUF provides protections against data tampering, rollbacks, key compromise, and other more esoteric attacks. We will investigate how it achieves these protections and show you how to start using it today.
While TUF is a general signing framework, we will also address use cases specific to the Cloud Native Ecosystem. These include how to use TUF signing to de-privilege cluster managers and attach metadata to images and containers in a decentralized manner which can be leveraged for policy management.
About David Lawrence
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
About Ashwini Oruganti
Ashwini is a Security Engineer at Docker and an open source developer. She is the author of pyca/tls, a pure-python TLS 1.2 implementation with opinionated and secure APIs. In the past, she has worked on Twisted - an asynchronous event-driven networking framework, and Hippy - a PHP implementation in RPython.
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
Welcome
everybody.
This
is
great.
I
did
an
identically
titled
talk
with
different
slides
18
months
ago,
and
there
were
like
10
people
in
the
room,
so
this
is
fantastic
that
you
all
turned
up
today.
So
we're
gonna
talk
to
you
today
about
when
the
going
gets,
tough,
get
tough,
going
and
we'll
find
out
more
about
what
that
acronym
is
as
we
go
along.
My
name
is
David
Lawrence.
My.
A
Both
security
engineers
at
docker,
so
today
we're
going
to
talk
about
sort
of
where
are
we
coming
from
with
signing
like?
Let's
have
a
little
look
back
at
what
signing
used
to
be
where
we
are
with
the
state
of
digital
signing
some
specific
challenges
in
software
distribution,
because
a
lot
of
what
we
talk
about
in
terms
of
signing
things
has
added
requirements
and
properties
that
we
want
to
achieve.
A
B
The
way
to
pass
like
nice
or
messages
was
that
the
kings
of
the
kingdoms
would
take
a
message,
write
it
down
on
paper,
seal
it
and
give
it
to
a
messenger,
and
the
messenger
would
then
get
on
a
horse
or
carriage
or
whatever
was
the
norm
at
the
time
and
pass
it
around
to
the
right
recipient.
Now
there
are
two
assumptions
that
were
made
here.
The
first
one
was
that
we
implicitly
trusted
the
messenger
to
do
the
right
thing
and
not
mess
with
the
message.
B
The
second
one
is
that
the
seal
that
I
mentioned,
that
the
gains
put
on
the
messages
were
worried
special.
So
the
king
seal
was
sort
of
like
a
mark
of
the
king
or
the
Empire,
and
a
good
protection
around
making
sure
that
the
integrity
of
the
messages
remained
constant
was
that
you
would
just
imprison
or
punish
or
whatever
the
criminal.
At
the
time
the
the
people
who
tried
to
copy
the
seal,
and
it's
it's-
it's
actually
a
very
real
problem.
B
It
was
then,
and
it
still
is
now,
how
do
you
tell
if
a
stamp
is
real
or
a
stolen
one
or
a
last
one?
That's
a
random
person
found
so
moving
on,
though
we
translated
the
concept
of
seals
to
signatures
in
the
modern
world,
and
we
evolved
to
this
idea
of
asking
people
to
sign
documents
associating
someone's
signature
as
a
mark
of
their
identification.
B
But
this
also
is
not
a
perfect
solution,
because
what,
if
I
sign
your
name?
How
can
we
tell
if
it
was
in
fact
your
signature
and
you
yourself
signed
it
and
that
sort
of
bradda
bother
the
need
for
witnesses
and
a
witness
is
basically
a
second
person
who
could
witness
you
signing
a
document,
thereby
sort
of
establishing
that
you
made
your
mark
and
the
integrity
of
the
signature
is
valid,
but
wait?
How
do
you
trust
the
integrity
of
a
witness?
B
Witnesses
can
be
bought
and
a
witness
could
just
be
a
friend
that
you
asked
to
say
something
in
court
so
that
establish
the
need
for
notaries.
Notary
public
is
basically
a
person
that
we've
entrusted
to
be
a
witness
and
we
implicitly
distrust
them
to
be
good.
At
being
a
witness
and
doing
the
right
thing,
I'll
hand
it
over
to
David
to
tell
us
what
happened
when
we
all
started
using
computers.
B
A
In
between
you
know,
notary
publics
and
people
just
signing
documents.
We
actually
these
really
interesting
machines
up
on
the
top
left,
that's
an
autopen,
famously
used
by
presidents,
and
it's
literally
a
device
for
forging
signatures.
So
you
know
you
want
the
president
to
sign
some
legislation.
If
you
can
get
access
to
his
auto
pen,
you
can
get
whatever
you
want
past,
but
signing
in
the
digital
world
really
came
into
its
own
and
really
didn't
exist
before
we
developed
asymmetric
crypto.
A
So
just
quick
show
of
hands
who
really
you
know,
has
a
good
handle
on
asymmetric
crypto.
Okay,
that's
good!
That's
probably
half
the
room,
so
the
idea
with
asymmetric
cryptography
for
those
that
aren't
so
familiar.
You
generate
a
key
that
is
actually
a
pair
of
data
points.
One
of
these
you
make
public,
and
one
of
these
you
keep
private
and
secure
as
best
as
you
possibly
can.
Any
operation
done
with
one
of
those
keys
can
be
reversed
with
the
other
key.
So
you
want
to
encrypt
something
to
somebody.
You
take
their
public
key.
A
A
The
decryption
operation
match
the
two
pieces
of
data
and
confirm
that
you
then
actually
had
possession
of
the
private
part
of
the
key
and
the
most
well-known
signing
or
I
should
say
asymmetric
crypto
implementation
is
probably
GPG
new
privacy
guard,
and
this
gives
us
a
number
of
very
desirable
properties.
Confidentiality,
as
we
said,
we
can
use
these
keys
to
encrypt
things,
but
in
the
world
of
signing
encryption
isn't
specifically
what
we're
interested
in.
That
may
be
a
requirement
for
a
specific
use
case,
but
we're
not
going
to
address
that
explicitly.
A
More
importantly,
though,
we
get
integrity,
we
can
check
that
a
message
hasn't
been
tampered
with
by
using
GPG
signing
through
the
web
of
trust.
We
also
get
some
degree
of
authenticity
now.
The
idea
of
the
web
of
trust
is
that
you
meet
people,
you
verify
their
identity
and
you
use
your
private
key
to
sign
their
keys
and
in
doing
so,
somebody
can
then
determine
that
there
is
a
trusted
relationship
between
you
and
that
person,
at
least
as
far
as
identity
is
concerned.
A
You
know
the
more
people
that
have
verified
your
identity
by
signing
your
keys,
but
more
likely
that
that
identity
is
legitimate
to
a
random
person
who
looks
up
your
key
in
a
directory
online.
Of
course,
this
is
transitive.
So
if
I
have
no
connection
with
somebody
who
sends
me
a
message,
but
maybe
Ashwin,
he
does
I
have
to
decide
if
I
trust
that
person
based
both
on
my
relationship
with
Ashwini
and
also
maybe
asking
actually
hey,
you
know
how
well
do
you
know
this
person
should
I,
actually
trust
them.
A
So
you
know
authenticity
isn't
perfect
here,
but
we
do
have
some
mechanism
for
getting
trust
between
two
parties
who
don't
necessarily
know
each
other
directly
in
the
real
world,
and
then
we
also
have
non-repudiation,
which
in
classical
signing
is
a
highly
desirable
property.
This
means
that
somebody
can't
come
later
and
say:
no,
no
that
wasn't
me
I
didn't
sign
that
thing.
A
Of
course,
as
we
mentioned
with
losing
seals,
you
can
also
lose
your
GPG
keys
and
the
lost
prot
the
lost
stamp
or
the
lost
key
problem
is
a
real
issue,
because
yeah
I
may
not
be
able
to
repudiate
the
signature
itself,
but
I
can
say
like
no,
no
I
lost
my
key,
like
whatever
was
sent
to
you,
then
it
wasn't
me.
Somebody
else
had
my
key
and
the
main
problem
with
this
is
revocation.
Revocation
around
keys
in
general
is
frequently
based
on
black
lists.
Black
lists
are
bad.
A
It's
straight-up
bad,
like
there
may
be
cases
where
you
have
to
use
one,
but
you
should
always
prefer
white
lists.
The
reason
for
this
is
because
black
lists
are
fail
open.
If
you
fail
to
get
an
update
to
the
black
list
or
something
doesn't
go
into
the
black
list
in
the
first
place,
you
continue
to
trust
something
you
should
not
be
trusting
anymore.
B
Software
is
very,
very
special
and
has
some
very
interesting
properties.
For
example,
software
I
got
too
old.
If
I
find
an
email,
it
will
still
have
the
same
meaning
years
later,
but
software
needs
constant
updates
because,
as
a
software
ages,
we
usually
find
vulnerabilities
and
when
their
abilities
require
fixes,
which
these
fixes
are
then
usually
released
as
a
new
version
and
as
people
download
the
new
version
and
update
their
installations.
B
We
have
to
deal
with
incompatibility
issues
and
the
thing
about
complex
software
systems
is
that
trying
to
update
one
component
might
lead
to
you
getting
a
chain
of
dependencies
that
subsequently
require
updating.
So
this
brings
us
to
you
interesting
distribution
properties,
because
once
you
worked
on
updating
your
software,
releasing
it
and
pushing
those
updates
to
consumers
is
in
itself
a
big,
complex
task
and
as
a
user
downloading
and
updating
software
confidence
securely
is
not
very
straightforward.
B
So,
for
example,
even
if
I'm
downloading
an
update
over
TLS
and
I've
secured
the
handshake
works,
and
everything
is
great,
it
doesn't
protect
me
from
compromised
servers,
so
risk
compromised
all
the
time.
So
do
you
all
see
the
picture
on
the
right
side?
That's
Fargo
stagecoaches,
where
the
TLS
of
the
Wild
West
they
protected
money
in
transport,
but
there
was
nothing
from
stopping
an
evil
bank
manager
putting
fake
money
on
the
on
the
coat.
B
A
As
the
title
of
the
talk
said,
let's
get
tough
going
and
tough
is
the
update
framework
developed
by
Justin
Kappas,
who
is
somewhere
in
the
room
here.
Excellent
work
and
his
team
at
NYU
Tandon
School
of
Engineering,
will
get
the
name
right.
The
update
framework
is
a
holistic
solution
to
securing
the
distribution
of
your
software
updates
and
really
any
digital
content
over
the
internet.
So
you
know
what
is
it
at
its
core
and
strap
in
because
is
where
we
get
into
like
the
nitty-gritty
stuff?
A
Traditionally,
we
would
sign
individual
Edge's.
If
you
look
at
something
like
the
Python
package
index,
they
still
do
this.
Every
single
publisher
of
a
package
is
expected
to
sign
that
package
themselves.
This
creates
an
enormous
headache
for
consumers.
If
I
have
a
hundred
dependencies
that
I'm
managing
from
the
Python
package
index,
if
I'm
fortunate,
they
will
all
be
signed.
In
reality,
only
about
5%
of
the
packages
in
there
are
actually
signed,
but
assuming
they
all
are
signed.
A
I
have
to
go
and
find
every
single
public
key
of
every
single
publisher,
and
there
is
no
standard
way
for
them
to
get
those
to
me
so
that
I
can
install
those
onto
my
CI
systems
or
my
production
servers
to
verify
every
single
piece
of
content
I'm
going
to
go
and
download.
Now
some
people
have
already
improved
on
this
by
having
the
actual
repository
manager
sign
the
packages,
sometimes
as
an
additional
signature
and
sometimes
like
with
Apple
Apple
Apple
iOS
applications.
A
Apple
just
replaces
the
signature,
but
you're
still
typically
signing
individual
packages
so
going
beyond
this
again.
What
tough
does
and
what
some
of
the
more
forward-thinking
packaging
managers
have
done
is
starting
to
sign
the
entire
collection
and
know
you
know
we
mentioned
black
lists
earlier.
If
I
had
a
bad
package
in
this
world,
I
might
have
to
blacklist
a
key
or
blacklist
a
package
when
I
sign
the
collection.
I
now
have
a
white
list
only
packages
that
should
be
in
that
collection
actually
do
get
signed
in
now.
A
What
tough
does
that's
really
useful
is
I,
sometimes
still
want
to
get
the
signature
from
the
publisher,
so
in
tough
I
can
define
what
it
called
delegations
which
allow
me
to
segment
out
part
of
the
namespace.
Within
this
repository
and
say
you
know
what
I
have
a
different
person
if
I
want
to
be
responsible
for
this
little
group
of
packages
here
and
adding
to
this
white
list,
I'm
actually
going
to
take
that
person's
key
and
sign
it
in
and
now,
as
a
consumer
you're
no
longer
going
in
getting
a
random
key
off
the
internet.
A
Even
though
you
don't
know
the
person
that
manages
this
subset
of
packages,
you
can
generally
assume
that
there's
probably
a
reasonably
trusted
relationship
between
the
person
that
owns
the
repository
and
the
person.
That's
publishing
the
packages
like
it
may
just
be
an
online
account,
but
that's
more
than
you
just
going
to
a
random
website
based
on
somebody's
name
and
finding
a
public
additionally,
because
I
have
a
whitelist
I
can
remove
things
like
I'm
no
longer
tied
to
you.
No
out-of-date
servers,
possibly
continuing
to
serve
bad
metadata.
A
You
should
be
going
to
get
now.
These
four
keys
are
taken
and
put
into
a
file
that
we
call
the
root
Jason
and
all
of
these
roles
here
have
JSON
files
associated
with
them
that
take
their
their
namesake
keys.
The
root
Jason
is
itself
signed,
self-referential
e
with
the
root
key.
This
starts
to
give
us
a
hierarchy.
We
trust
this
root
key
because
we're
going
to
we're
going
to
bootstrap
this
root
Jason
in
some
manner
and
from
the
root
key
and
that
signed
root.
A
Jason
I
have
transitive
trusts
on
my
target
snapshot
and
time-stamping
keys,
my
delegation
keys
all
chained
as
a
tree
that
can
be
arbitrarily
nested,
underneath
my
targets
key.
So
I
may
say
that
you
know
I
have
a
delegation
key
in
a
role
ashwin.
He
has
a
delegation
key
in
a
role.
Jane
Doe
has
a
Dell
in
a
role.
We
may
be
restricted
into
only
signing
certain
packages
within
the
broader
repository,
and
we
can
also
further
delegate
this
tree
can
go
any
level
down
now
that
I
have
this
hierarchy.
A
We
can
use
this
to
also
treat
our
keys
as
a
whitelist.
If
I
need
to
change,
one
of
these
keys,
I
can
just
change
it
at
that
point
in
the
tree
sign
in
a
new
record
with
the
parent
key
that
I'm
chaining
that
trusts
off
and
eventually
this
goes
all
the
way
back
up
to
my
root
key.
So
rookie's
interesting
because
obvious
I
don't
have
any
implicit
chaining
of
trust
down
on
to
my
root
key.
So
how
would
I
go
about
changing
that?
Well,
tough
defines
how
to
do
this.
I.
A
Take
my
existing
root
file
that
I've
already
got
bootstrapped
I
generate
a
new
root
file.
I
generate
a
new
key
to
replace
the
old
one.
I
then
sign
my
new
root
file
with
both
my
old
key
and
my
new
key,
and
this
gives
me
a
chain
of
trust
from
the
data
I
know
to
the
data
I'm
trying
to
acquire
the
keys
here
have
different
security
profiles
so,
as
you
might
guess,
the
the
frequency
with
which
you
need
to
use
the
key
dictates
sort
of
where
you're
going
to
have
to
store
it.
A
But
it's
gonna
need
to
be
time,
stamping,
you
know
automatically
on
a
regular
basis,
so
this
has
the
weakest
security
properties
at
the
other
end
of
the
scale,
your
root
key,
you
should
need
very
infrequently.
You
typically
only
need
this
to
resize
your
root
jason
root,
JSON
file
when
it's
about
to
expire
or
when
one
of
your
other
keys
has
been
compromised.
A
So
you
can
store
this
somewhere
like
a
bank
vault
and
ideally
put
it
on
to
signing
Hardware,
something
like
a
UB
key
to
bring
it
online
when
you
actually
need
to
do
signing
operations
with
it.
Furthermore,
if
you
want
to
add
additional
protection
on
top
of
this,
tuff
supports
a
really
cool
idea
of
thrush
holding
for
any
of
the
roles
in
my
system.
I,
don't
have
to
trust
simply
one
key
I
can
define
a
set
of
keys
and
then
have
some
subset
of
them
be
required
to
actually
create
a
valid
piece
of
data.
A
So
imagine
you
were
worried
about
our
situation
earlier,
where
maybe
the
owner
of
the
repository
can
be
compelled
to
publish
bad
data.
I
could
maybe
generate
10
keys
for
signing
a
given
role,
distribute
them
to
ten
different
countries
around
the
world
and
require
say
four
of
them
have
to
sign
to
make
any
piece
of
data
valid.
This
makes
it
very
difficult
for
somebody
to
be
compelled,
or
even
if
one
person
doesn't
implement
good
security
practices.
The
compromise
of
their
individual
key
is
not
enough
to
publish
bad
updates
so
for
people
who
need
high
security
environments.
A
This
is
an
incredibly
powerful
feature.
Now
we
talked
about
how
we
get
the
initial
bootstrapping
of
trust
and
much
like
how
you
get
your
CA
certificates.
There's
like
a
single
download
point
that
you
just
you
trust
that
one
point
in
time
you
download
it
over
TLS
whenever
you
download
something
that's
going
to
use
the
update
framework-
and
this
is
purely
an
example
here.
As
far
as
I
know,
canonical
is
not
using
tough.
A
When
you
go
download
your
abun
to
ISO,
you
would
get
an
initial
route
JSON
file
as
part
of
that
download
and
every
subsequent
update
you
do
to
your
tough
repository,
you
bootstraps
with
this
initial
route.
Jason
that
you
downloaded.
So
let's
have
a
look
at
what
that
actual
update
flow
looks
like
from
my
pinned,
root,
Jason,
I'm,
gonna,
go
and
download
my
time
stamp
file
and
I.
A
Don't
have
any
other
information
about
my
time
stamp
file
other
than
it
should
be
small,
so
I
limit
how
much
data
I'm
gonna
download
that
I
verify
that
it's
signed
with
my
time,
stamping
key
that
I
have
from
my
root
or
Jason.
Now
my
time
stamp
file
contains
a
checksum
of
my
snapshot.
Remember
my
snapshot
is
my
inventory
of
everything
else.
That's
in
the
repository,
so
for
my
time,
stamp
I
go
and
download
my
snapshot
and
verify
the
checksum
to
make
sure
I
have
integrity.
A
I
then
also
verify
the
signature
of
the
snapshot
based
on
my
route.
Json
file
from
my
snapshot.
First,
I'm
gonna
make
sure
that
my
route
Jason
is
up-to-date,
because
my
snapshot
will
tell
me
if
there
has
been
an
update
to
the
route
Jason.
If
there
has
been
I'm
gonna,
go
and
download
the
updated
route
Jason
run
through
that
key
rotation
check.
That
I
had
see
if
any
keys
have
changed
and
then
replace
my
existing
pinned
route
Jason
with
the
new
one
and
start
this
update
flow
again.
A
So
when
I
eventually
get
back
to
my
snapshot
file
again
I
then
look
up
the
checksum
of
my
targets.
File
go
and
download.
It
verify
the
integrity
based
on
the
checksum
and
verify
the
signature
of
my
target's
file
and
then
using
that
key
hierarchy.
We
had
my
targets.
File
is
going
to
tell
me
which
delegations
I
have
and
which
keys
are
associated
with
those
delegations.
A
B
The
expired
mirrored
problem
that
I
mentioned
earlier
were
the
the
server
you
were
asking
for.
Updates
room
didn't
really
know
what
the
latest
version
was
and
was
giving
you.
The
answer
that
is
thought
was
right,
but
it
wasn't
really
right.
All
the
mirrors
and
servers
can
be
expected
to
have
the
latest
updates
for
the
consumers.
So
now
that
we've
talked
about
what
tough
is
and
how
it
works,
you
might
be
thinking
how
can
I
use
it.
B
So
it
is
true
that
the
update
framework
needs
a
lot
of
work
from
the
spec
to
signing
to
get
to
the
state
where
you
can
just
sign
things,
but
here's
the
good
news.
We've
done
all
the
hard
work
for
you.
The
the
screen
you
see
is
basically
notary,
golang
implementation
that
we
a
docker
built,
and
it
was
recently
accepted
as
a
cnc.
If
project
it's
open
source
and
it
is
ready
for
use,
let
me
quickly
go
through
the
architecture
of
notary
to
get
an
idea
of
how
it
all
comes
together.
B
So
notary
has
a
client
library
for
integration,
with
your
use
case,
as
well
as
a
CLI,
this
CLI
or
client
a
talks
to
a
notary
server
which
deals
with
storing
and
serving
the
sign
metadata,
and
it
validates
an
update
when
it
is
published
to
make
sure
it
doesn't
break
anything.
The
signer
does
time,
stamping
and
time
stamping
involves
signing
keys
and
those
keys
are
encrypted
and
stored
in
a
database
and
well
that's
a
lot
of
like
high-level
overview.
Words
actually
see
this
in
a
demo.
A
B
A
A
Totally
trustworthy
and
yeah:
that's
not
not
what
I
expected!
Fortunately,
this
this
is
my
website.
I
keep
a
backup
of
it,
but
before
I
run
an
update,
let's
actually
initialize
a
tough
repository
sign
the
correct
copy
into
the
tough
repository
publish
that
verify
that
it
now
blocks
the
download
of
the
bad
data
and
then
do
our
update
and
verify
that
we're
getting
the
correct
script.
So
we
have
this.
Notary.
A
If
we
have
larger
amounts
of
data,
we're
dealing
with
to
make
sure
that
something
is
good
and
as
we
expect
so
we're
going
to
initialize
a
repo
and
we're
going
to
call
it
trustworthy
calm,
because
that's
the
website
we're
gonna
initialize
it
for-
and
this
is
going
to
ask
me
for
some,
so
notary
will
attempt
to
reuse
a
root
key
by
default.
You
can
also
give
the
CLI
flags
to
tell
it
to
use
specific
root
keys
and
then
it's
going
to
go
and
generate
those
targets
and
snapshot
keys
that
we
had
in
the
slides.
A
A
I
wish
okay,
it's
gonna
ask
me
for
my
targets.
Key
so
I
can
actually
sign
in
that
new
package
or
that
new
script
into
my
list
of
targets
that
I
want
to
be
available,
and
then
it's
going
to
ask
me
for
the
snapshot
and
key
so
I
can
update
the
inventory
note
that
the
notary,
server
and
signer
also
support
rotating
the
snapshot
and
key
to
the
server,
which
is
really
useful
in
the
case
that
you
have
lots
of
delegations
that
you're
having
to
manage
all
right.
A
A
A
And
then
just
run
this
again,
so
it
printed
the
script.
Obviously
we
can
actually
pipe
the
end
of
this
to
bash
and
it
will
execute
bash,
gives
a
really
unpleasant
error
message
in
the
case
of
notary
denying
the
script
so,
but
if
we
can
pipe
it
to
bash
and
it
runs
my
script
and
it's
done
a
verification.
It's
made
sure
that
the
data
we
downloaded
matched
from
the
trustworthy
comm
repository
the
awesome
Sh
target
that
we
were
trying
to
download.
Now
you
can
extend
this
out.
A
There
is
an
integration
called
docker
content,
trust
built
into
the
docker
CLI
that
does
uses
notary
for
signing
docker
images
that
can
be
used
against
any
docker
registry.
If
you
happen
to
be
at
Daka
enterprise
customer
that
comes
with
instances
of
the
notary,
server
and
signer
that
you
can
already
operate
against
and
also
comes
with
policy
management.
So
you
actually
use
these
signatures
to
gate
deployments
going
out
to
production,
sure
all
useful
features
for
high
security
environments,
all
right,
so
wrapping
up
and
I
think
we
will
have
a
minute
questions.
Sorry,.
B
So,
as
I
mentioned,
notary
is,
is
an
open
source
library.
It's
part
of
the
CN
CF
and
if
you
all
thought
that
this
looks
really
cool,
we
invite
you
to
come
contribute.
There
are
a
bunch
of
things
that
we're
looking
into
for
the
future
of
notary,
and
it
would
be
great
to
see
you
all
tomorrow,
at
11:10
and
in
meeting
room
for
a
indict.
A
But
it's
we
actually
I,
like
pat
myself
on
the
back
I
feel
like
we
did
a
reasonably
good
job
of
like
abstracting,
the
ciphers
we
support
from
the
rest
of
the
code
base.
So
it's
if
anybody
wants
to
add
additional
ciphers.
It
is
relatively
straightforward
and
I
think
the
certain
bits
of
the
command
line,
like
the
key
generation
commands.
Definitely
let
you
configure
like
which
cipher
to
use
and
then
you
can
use
those
to
then
like
tell
it
to
use
specific
keys
for
specific
things.
A
A
A
Helps
so,
fortunately
docker
images,
at
least
which
I
believe
still
conform
to
the
OCI
spec
and
are
intended
to
are
actually
a
Merkle
tree,
so
every
the
manifest
or
the
multi
arch,
manifest
now
sometimes
called
the
manifest
list
contains
check
sums
of
the
layers,
the
layers
that
are
files
that
you
go
and
download.
So
it's
we
sign
in
whatever
the
top
level
item
is
whether
it's
a
multi
arch,
manifest
or
a
single
architecture
manifest
and
from
there.
You
have
checked
sums
of
everything
else
that
you
need
to
go
download
specifically.