►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Updates from The Update Framework - Lukas Pühringer, NYU & Jussi Kukkonen, VMware
The Update Framework (TUF) is a framework for secure content delivery and updates. It protects against various types of supply chain attacks, and, in contrast to many other systems, provides resilience to compromise. In this talk Jussi and Lukas, both maintainers of the TUF reference implementation and core contributors to the TUF specification, will show why content delivery is such a crucial part of the supply chain, how TUF can be used to protect it, and where TUF is already used in practice. They will talk about how the TUF ecosystem is evolving: what is happening within the various sub projects and how some well-known adoptions and integration projects are proceeding. Finally, some interesting future developments are discussed.
A
Okay,
hello.
Everyone
thanks
for
having
me
thanks
for
coming.
My
name
is
lucas
puringa
and
I'm
a
researcher
and
engineer
at
nyu,
secure
systems
lab
where
I
work
on
supply
chain
security
projects.
One
of
those
projects
is
tough
short
for
the
update
framework,
and
I
should
have
given
this
talk
today
with
my
dear
colleague
yusi
from
vmware,
but
he
had
to
cancel
his
trip
to
valencia
at
the
last
moment.
So
I
will
try
to
cover
for
him.
A
A
A
A
So
you
pull
in
all
these
dependencies,
and
so
you
can't
just
focus
on
your
package
that
you
maintain,
but
you
also
have
to
think
of
the
entire
dependency
graph,
because
again,
one
single
supplied
as
one
single
compromise
somewhere
deep
down
in
the
dependency
graph
has
severe
consequences,
affects
all
the
packages
downstream
and
yeah.
Who
knows
who
who
works
on
this
package?
I
mean:
do
you
know
it
for
all
your
dependencies
as
a
maintainer?
A
Maybe
this
is
a
solo
maintainer
without
two
factor,
authentication
enabled
maybe
he's
or
she's
frustrated
working
for
free
and
everybody
relies
on
that
package.
So
and
not
even
the
maintainer
of
packages
now
know
where
all
their
dependencies
come
from.
So
we
really
can't
expect
the
end
user
to
have
a
good
picture
of
this
entire
dependency
graph.
A
A
A
A
Let's
take
a
closer
look,
tough
uses,
cryptographic
signatures
for
this.
By
signing
the
content
itself,
it
protects
its
integrity
and
by
signing
the
entire
repository,
it
protects
the
consistency
and
it
has
a
multi-tiered
signature
exploration
scheme
to
make
sure
that
the
content
you
download
or
update
is
fresh.
So
that
is
really
the
easy
part
of
of
tough.
A
You
probably
wouldn't
need
your
own
framework
for
this,
but
here
it
gets
more
complicated,
but
also
more
interesting,
so
bear
with
me
this
graph,
you
see
in
the
middle,
defines
the
roles
that
are
or
is
like
shows
the
roles
that
are
defined
by
the
tough
framework
and
the
delegations,
the
trust
delegations-
and
there
are
several
different
mechan
trust
delegation
mechanisms
prescribed
by
tough.
So
first
on
the
top
part
of
this
graph,
you
see
the
root
delegation.
A
This
is
where
we
separate
responsibilities
for
a
repository
by
roles,
so
there's
a
dedicated
role
for
the
freshness
of
the
repository.
There's
a
dedicated
role
for
its
consistency
and
a
dedicated
role
for
the
integrity
of
everything,
and
it
all
goes
back
to
the
root
of
trust.
This
root
role
on
top
and
we'll
see
on
the
next
slide.
While
this
delegation
is
very
helpful
and
the
second
delegation
mechanism
separates
responsibilities
by
content,
so
this
is
the
lower
bottom
of
the
graph
with
the
arrows.
A
The
integrity
role
in
tough
can
itself
delegate
to
more
integrity
roles,
and
by
that
you
can
kind
of
name
space,
your
the
trust
in
your
repository,
you
say
I
only
want
want
this
role
to
provide
signatures
for,
let's
say
in
the
case
of
of
pipeyi
and
python
packages.
I
want
this
role
to
provide
signatures
for
the
django
project,
this
web
framework,
and
I
want
a
different
role
to
provide
signatures
for
the
cryptography
project.
A
So,
for
instance,
the
the
root
role
is
only
responsible
for
delegating
distrust
to
the
other
roles,
and
that
means
I
don't
need
it
so
often-
and
I
can,
I
can
sign
it
with
offline
keys
roles
for
freshness
and
consistency,
on
the
other
hand,
are
in
a
in
a
repository
that
gets
updated.
Very
often
are
high
availability
keys,
so
I
will
likely
use
online
keys
for
this,
and
but
I
I
don't
give
them
any
more
responsibility
that
they
have.
I
don't
use
them
to
get
delegate
trust
to
other
roles,
for
instance,.
A
A
A
So
the
specification
defines
all
those
rows
that
we've
seen
in
the
graph
what
responsibilities
they
have
and,
above
all,
the
metadata
format
that
is
used
to
represent
the
role,
and
it
also
explains
how
to
maintain
manipulate
those
metadata
files
for
the
roles.
In
a
repository
to
some
extent
and
in
great
detail,
it
explains
how
to
consume
that
metadata
on
a
client.
A
Given
that
the
specification
is
very
dependable,
so
a
lot
of
organizations
or
companies
use
stuff,
we
can
just
go,
go
ahead
and
change
it,
but
also
a
living
document
because
new
use
cases
arise.
We
have
this
tough
augmentation
proposal
process
that
we
we
use
to
discuss
new
features
and
slowly
adapt
them
in
the
specification
in
a
responsible
manner,
and
then
the
last
thing
at
the
core
of
the
project
is
the
reference
implementation.
A
It's
a
python
implementation
that
offers
a
client
updater
and
a
metadata
api
client
updater
can
just
be
sticked
into
just
be
stuck
into
into
any
software
updater
and
basically
works
off
the
shelf.
The
metadata
metadata
api
is
more
flexible
for
repository
side
activities.
I'll
talk
about
that
later.
What
that
means
the
reference
implementation
is
very
symbiotic
with
the
specification.
A
So
that's
the
core
of
the
project,
and
then
there
is
more
of
the
project.
There
are
several
libraries
in
different
languages
that
implement
tuff.
There
are
several
organizations
and
companies
that
use
stuff
datadock
uses
it
aws
bottle
rocket,
uses
it
google's
fuchsia
os
uses
it
six
store
uses
it.
I'm
gonna
talk
about
that
later.
Then,
there
is
a
variant
of
tough
called
obtain,
which
is
it
uses
like
a
specification
compliant
but
adds
extra
things
to
work
with
the
requirements
of
the
automotive
industry.
A
So,
let's
dig
even
a
little
bit
deeper.
What
tough
in
practice
means.
I've
already
talked
a
lot
about
client
and
updater
and
also
the
repository
side.
So
this
is
a
notion.
That's
really
important
for
tough
and
yeah.
So
far,
we've
we've
learned
that
tuff
is
mostly
a
collection
of
metadata
files,
metadata
files
that
lists
keys,
list,
keys,
delegation,
relations
and
signatures
of
it.
A
So
in
reality
this
means
that
we
we
need
a
repository
that
somehow
maintains
this
metadata
and
the
client
client.
That
knows
what
to
do
with
it
in
order
to
to
guarantee
all
those
security
properties
that
we
we
discussed
earlier
and
one
problem
in
practice
or
one
yeah.
One
problem
in
practice
is
that
the
repository
the
way
you
you
create
the
layout
the
metadata.
There
varies
a
lot
from
project
to
project,
so
you
can't
just
use
the
tough,
the
tough
code
and
stick
it
in
and
then
it
works.
A
You
have
to
really
think
of
which
rows
exactly
you
mean
you
want
to
use,
but
the
good
thing
is
that
the
client
is
relatively
easy
to
use
and
I
will
show
two
use
cases
where
tough
is
used
or
almost
used.
So
pi
pi
is
the
the
python
packaging
index.
I
don't
know
if
everyone's
familiar
with
it,
that's
where
you
get
usually
get
your
code
when
you
do
pip
install
and
we've
been
trying
to
integrate
tough
with
pybi
for
a
while.
A
Hello,
the
first
one
only
signs
content
in
the
repository
that
gives
you
the
freshness
and
consistency
and,
of
course,
integrity,
properties
that
come
with
tough.
It
also
allows
you
to
like
gives
you
a
mechanism
to
rotate
keys
with
a
safe
route
route
of
trust
in
band,
but
it
doesn't
give
you
the
fine-grained
namespaces
for
different
projects,
and
it
also
doesn't
allow
you
to
have
offline
keys
for
for
the
for
the
content
signatures,
because
content
gets
uploaded
loaded
every
second,
so
these
keys
need
to
be
online
to
sign
it
as
soon
as
they
are
uploaded.
A
A
This
has
a
bunch
of
usability
problems.
How
developers
manage
the
keys,
how
the
trust
negotiation
between
the
repository
and
the
developers
gets
established
in
the
beginning,
so
we're
still
trying
to
figure
this
out
and
community
repository.
That
means
repositories
where
code,
where
packages
get
uploaded
by
random
people,
are
really
a
hard
use
case.
A
A
A
It's
actually
used
in
production,
but
there
is
still
more
more
to
come,
like
they're,
trying
to
expand
that
lower
part
of
the
delegation
tree
with
tough
and
that
there
we're
almost
at
the
end
of
the
talk
I
wanted
to
like.
There
are
many
things
happening
in
the
near
future.
Two
of
them,
I
wanted
to
point
point
out,
are
the
repository
playground.
This
is
something
that
you
see
who
couldn't
come
today
is
spearheading
it's.
Basically,
the
attempt
to
to
create
a
new
prototypical
community
content,
repository
with
real
workflows
and
best
practices.
A
That
can
then
be
easily
adopted
by
by
real
life
repositories
like
pypi
or
mpm,
because
the
problem
of
repositories
like
pipi
or
npm
is
that
they
they
are
relied
upon
by
many
many
many
people.
So
they
are
not
so
happy
with
experimenting
with
things,
and
we
can't
really
do
pathfinding
life
in
the
repository.
A
So
we
try
to
make
prototype
that
can
then
be
adapted,
maybe
by
by
several
several
content
repositories,
and
that
prototype
should
mostly
be
based
on
tough,
because
tough
really
solves
a
lot
of
these
problems
already,
but
not
exclusively,
and
another
project
which
is
related
to
six
store
is
the
attempt
to
use
ephemeral,
keys
that
are
connected
to
oimdc
identities,
which
are
identities
from
email
addresses
to
use
those
for
developer.
Signing
of
of
the
tough
targets
metadata,
because
at
the
moment
the
target's
role
delegates
normal
local
key
pairs
and
yeah.
A
The
there
are
many
ways
to
get
engaged
with
the
tough
community.
There
are
many
ways
to
reach
out
to
us.
If
you
have
questions,
if
you
think
that
some
of
these
ideas
are
good
for
your
project,
we're
happy
to
to
help
brainstorm
storm,
how
it
can
really
be
used.
As
I
said
it
is
being
used
in
many
places.
A
A
B
A
A
A
So
I
can't
really
give
a
recommendation,
but
what
cosine
does
looks
really
cool
the
the
problem
with
cosine
and
and
sig
star
in
general
is
that
it
doesn't
have
this
fine,
grained
truss
delegation
I
was
talking
about,
so
you
can
name
space,
a
name
space
who
you
trust
for
providing
what,
like
you,
can
tie
everything
back
to
a
certificate
authority,
but
you've
got
a
yeah.
You
have
a
signature
for
a
container.
You
see
that
it
is
in
some
transparency
log.
A
It
ties
back
to
a
root
of
trust,
but
you
don't
really
know
if,
if
that
signature
was
allowed
to,
like
you
have
to
to
do
that
separately,
you
have
to
somehow
check
the
email
address
and
see
if
it
looks
like
the
person
attached
to
the
email
address
seems
like
someone
who
should
provide
a
signature
for
that
container,
but
yeah.
I
think
I
mean
it's.
A
super
cool
tool
and
ephemeral
keys
solve
a
lot
of
the
ux
problems
with
signing,
but
I
think
it
needs
more
especially
about
this
trust
name,
spaces.