►
From YouTube: Using TUF and in-toto to Tighten the Release Process. - Santiago Torres-Arias & Justin Cappos
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Using TUF and in-toto to Tighten the Release Process. - Santiago Torres-Arias, NYU & Justin Cappos, NYU
As enterprise companies move to Cloud Native, the supply chain has become a very attractive target for attacks. An attacker who compromises a project's supply chain can greatly increase the blast radius of their attack to all users of the system. In some cases the exploit is an unintended bug (e.g. Equifax); in others, it is more insidious. In this talk, Santiago and Justin will show you how you can use TUF and in-toto to create a tightly-secured software supply chain. Starting from secure container delivery using TUF, and moving towards the left to tools like build farms, vulnerability scanners, and version control systems. The talk will be grounded in real business delivery values by pointing out common software supply chain misconfiguration pitfalls and through an integration example on one of the largest open source operating systems.
https://sched.co/Uagm
A
So
as
I
as
I
said,
I
am
a
university
professor
and
professor
at
NYU,
and
one
thing
that
professors
love
to
do
is
we
love
to
give
quizzes
and
so
I
have
a
pop
quiz
for
the
audience
here.
No
cheating,
if
you
saw
this
same
quiz
yesterday
but
there's
an
attack
vector,
that's
used
by
you,
know
some
of
the
best
hackers
in
the
world.
It's
completely
invisible
and
isn't
protected
by
different
network
defenses,
like
your
firewalls,
your
IDS's
things
like
that.
A
It's
something
that
impacts
and
can
impact
basically
every
device
just
about
every
device
in
the
planet.
So
almost
everything
can
be
hit
by
this
attack
vector
and
it's
it
gives
you
usually
things
like
root
access
on
the
devices
you
get
on
and
it's
already
been
used
to
great
effect
by
nation-state
actors
around
the
world
and
the
which
are
the
best
hackers
in
the
world
use
this
over
and
over
and
over
again
to
do
some
of
the
most
damaging
attacks
that
we
read
about
in
the
news
and
we're
like.
A
Oh
my
gosh,
that's
terrible
all
right
and
then
I'll
just
go
ahead
and
kind
of
give
you
the
answer
here.
There's
many
victims
to
this
type
of
attack
all
of
these
companies
here
these
are
I.
Think
companies
like
you,
know,
Google
and
Microsoft
and
others
that
you
would
think
of
as
having
some
of
the
best
security
teams
and
some
of
the
best
security
postures.
A
Yet
they've
all
been
been
hit
by
this
and
this
attack,
as
you
would
know,
if
you
understand
what
session
you're
in
is
actually
attacks
that
deal
with
software
updates
and
attacks
through
software
updater.
So
there's
this
massive
risk
and
vulnerability
here
and
so
there's
this
question
of
well,
it's
easy
right.
We
just
use
crypto,
just
like
hey,
you
know,
I
have
a
bike.
I
want
to
lock
up
here
and
I,
just
put
my
lock
on
the
bike
and
then
everything's,
okay,
like
no
one,
could
possibly
steal
this
bicycle.
A
You
know
what
we
need
is
we
need
a
solution
and
sometimes
a
simple
solution
doesn't
always
give
you
the
properties
you
want
and
in
this
case
one
simple
solution.
That
is
the
reason
why
some
of
those
companies
ended
up
on
that
first
slide
was
basically
what
they
said
is
we're
going
to
just
use
TLS
protection
you're
going
to
have
x.509
certificate.
You
go
to
the
site,
you
know
you're
talking
to
the
server.
So
if
you
know
you're
talking
to
the
server
what
can
possibly
go
wrong?
A
Well,
what
can
possibly
go
wrong
if
you
know
you're
talking
to
this
server
here,
that's
responsible.
Is
that
someone
breaks
into
the
server
and
then
when
they
break
into
the
server
you
know
you're
talking
to
the
server,
but
you
don't
you
know
the
server
could
be
sending
you
any
kind
of
malicious
software
or
doing
anything
like
that.
And
you
know
this
is
something
like
a
web
server
that
has
you
know
a
web
server
on
it
right.
So
it
has
complicated
software.
A
It's
running
a
full
stack,
it's
you
know
and
tell
us
itself
has
had
a
lot
of
historical
issues
and
problems
over
time.
So
this
is
not
I,
think
the
only
line
of
defense
you
want
to
have
in
a
system
like
this,
the
other
solution
that
people
have
taken
historically
is
they
use
something
like
a
key,
often
something
like
maybe
GPG
or
something
like
that
that
might
live
on
a
server.
And
maybe
what
happens?
A
So
you
might
be
the
developer,
whose
main
thing
is
you
do
the
translation
of
some
of
the
documentation
into
Bulgarian,
but
you
could
still
sign
the
Linux
kernel
package,
because
your
key
is
in
the
keyring
and
its
trusted
and
that's
bad
because
then,
if
any
of
these
developers
are
hacked,
potentially
all
the
users
can
be
compromised
and
so
one
way
that
some
environments
try
to
protect
against
this.
Is
they
have
this
server
like
maybe
a
build
server,
or
something
like
that?
A
That
has
a
key
on
it
and
hey
the
build
server
will
sign
things
and
do
stuff,
but
then
you
break
into
the
build
server,
as
we've
seen
happen
time
and
time
again,
and
people
are
hacked
okay.
So
now
we've
kind
of
talked
about
how
you
know
all
of
those
you
know
like
the
models
that
people
have
commonly
used.
That
has
ended
up
with
them
being
on
that
kind
of
slide
of
shame.
I
had
earlier
on
so
now,
let's
look
at.
A
Is
it
even
possible
to
do
something
better
than
these
simple
designs
where,
if
something
goes
wrong,
you're
in
a
world
of
hurt-
and
it
is
so-
we
started
with
the
goal
of
doing
this
back
in
2009
2010
I
had
some
had
done.
Some
work
on
vulnerabilities
and
problems
inside
of
Linux
package
managers
and
had
written
some
papers
and
work
with
the
major
Linux
package
managers
to
fix
those
those
issues
like
the
design
flaws
in
in
with
what
they
were
signing
and
how
they
were.
A
A
So
if
experts
who
are
like
world-class
security
researchers,
you
know
there's
nuances
in
this
problem,
they're
not
seeing,
then
maybe
the
right
solution
isn't
to
go
around
and
tell
everybody
you
need
to
fix
these
37
things.
The
right
solution
is
to
build
like
a
common
framework
that
just
sort
of
does
it
right.
Just
like
we
don't
go
around
and
tell
everybody
to
do
all
the
right
sorts
of
things
for
like
TLS,
etc.
A
You
use
libraries
that
people
have
written
that
basically
handle
your
communications
and
give
you
confidentiality
and
integrity
and
authenticate
who
you're
talking
to
and
so
on.
So
what
tough
does
in
what
the
goal
is.
Is
that
you
have
a
situation
like
you
have
before,
where
you
have
some
server
that
maybe
gets
hacked,
but
your
users
are
not
at
any
real
risk
from
this,
so
what
I'm
going
to
talk
about
briefly,
is
how
tough
does
this?
How
tough
makes
this
happen
and
one
of
the
other
design
goals
inside
of
tough?
A
Besides
this
idea
of
being
able
to
be
resistant
to
compromise
like
don't
just
assume
you're
going
to
be
operationally
perfect,
the
other
one
of
the
other
things
tough
does?
Is
it
tries
to
support
use
cases
that
you
have
because
the
real
world
looks
like
this
in
many
cases,
and
so
tough
is
not
something
where
it
says:
thou
shalt
have,
you
know
fingerprint
readers
on.
A
A
Alright,
so
there's
four
main
things
that
I'm
going
to
talk
about
with
respect
to
toughs
design,
to
try
to
give
you
a
sense
of
how
it
provides
the
properties
it
does.
The
first
one
is
called
responsibility
separation.
So
the
idea
here
is:
is
that
what
you
do
is
you
have
different
roles
that
different
parties
in
the
system
will
do
and
will
provide?
A
A
Okay
and
I
just
talked
through
this
example,
so
I'll
skip
that
one
of
the
other
things
tuff
does
is
the
design
principle
is
it
tries
to
make
it
so
that
the
overall
risk
you
have
in
the
system
is
as
low
as
possible?
So
you
can
think
roughly
about
the
expected
damage
to
happen
in
a
system
as
being
the
probability
of
an
event
times
the
impact
if
that
event
does
occur?
Okay,
so
there
are
certain
things
where
you
know
the
you're
able
to
go
and
make
the
probability
needs
to
be
very
high.
A
A
So,
if
you
have
a
high
impact
role,
then
highly
secure
you,
we
make
it
so
it's
operationally,
like
you
know,
it's
not
operationally
burdensome
to
have
highly
secure
keys
and
online
keys
things
that
you
have
to
keep
online.
We
make
the
impact
very
low
in
the
system.
Another
thing
that
we
do
is
we
have
this
notion
of
multi
signature
trust.
So
you
I
alluded
to
this
before
in
my
example,
but
you
don't
have
to
have
a
single
party.
That
is
the
one
trusted
true
source
of
truth.
A
You
can
have
a
situation
where
there's
two
parties
like
a
and
B
that
both
are
required
to
sign
a
document
or
sign
a
package,
and
you
can
set
up
these
these
thresholds.
However,
you
want
to
set
it
in
your
system
and
then,
if
you
know
a
gets
compromised
in
in
a
situation
here,
there's
no
risk
to
clients,
there's
no
damage.
If
a
is
compromised,
you
have
to
have
both
a
and
B
get
compromised
and
after
a
is
compromised.
Well,
what
do
you
do?
A
You
handle
the
last
part
here
which
is
dealing
with
revocation
in
the
system,
so
when
we
first
did
the
design
of
toth
remember
the
the
goal
of
tough
was
to
protect
in
situations
where
your
servers
compromised.
That
was
like
goal
number
one.
How
do
we?
How
do
we
do
this
so
revocation
is
very
much
built
into
and
was
a
primary
concern
when
we
were
designing
tough.
If
anyone
here
has
ever
dealt
with,
revocation
in
like
revoking
in
the
x.509
CA
world
or
revocations
inside
of
GPD,
you
know
that
that
is
not
the
case.
A
For
those
systems,
revocation
is
really
messy
and
clunky
and
doesn't
work
well
and
doesn't
it
just
doesn't
behave
in
a
way?
That's
sane
and
logical,
and
because
this
was
a
focus
of
our
system,
revocation
is
actually
very
simple
and
very
seamless
inside
of
tough
and
isn't
some
weird
out-of-band
channel
that
happens.
A
Okay
in
TUF
TUF
has
four
main
roles.
Tuff
has
the
root
role,
which
serves
as
the
root
of
trust
for
the
system.
This
is
these
are.
It
was
the
example
of
the
keys
you
have
spread
apart
in
safety,
deposit
boxes
that
only
get
brought
out
when
something
goes
wrong,
or
only
got
get
brought
out
every,
maybe
three
to
six
months
to
make
sure
that
a
large
number
of
them
haven't
been
lost
or
ceased
to
operate.
You
know,
because
you
know
I,
don't
know
if
somebody
spilled
their
coffee
in
the
desk
or
something
like
that.
A
There's
something
called
targets
or
projects
role
depending
on
when
and
how
tough
is
used.
The
names
for
this
differ,
but
this
is
basically
the
developer.
That's
going
to
go
and
say
this
is
a
valid
version
of
this
thing
that
I'm
creating
okay.
This
says
this
is
a
valid
package
and
this
is
in
practice
it's
basically
always
done
by
somebody
either
having
something
like
a
UV
key
or
by
going
and
on
their
device
having
their
GPG
or
whatever
key
that
they're.
A
Using
so
think
of
this,
as
the
same
sort
of
you
can
in
fact
use
the
same
key
you
might
use
for
your
get
signing
or
for
other
operations
like
that
that
you
do
it
just
now
is
plugged
in
here
the
snapshot,
role,
I'm
gonna
skip
for
just
a
moment
and
explain
it
in
a
sec.
The
timestamp
role
lives
on
the
repository
and
says
when
the
last
update
has
happened
in
the
system
and
the
what
the
snapshot
role
does.
A
Is
it
handles
it's
used
to
handle
a
very
special
or
a
very
useful
attack
case
that
otherwise
would
go
on
handled,
and
this
attack
case
deals
with
situations
where
so,
okay,
so,
for
instance,
if
you
go
to
like
a
Linux
tree,
bution
and
you
say,
give
me
package
X
and
what
you
get
back.
Is
you
get
that
package
back
and
you
check
to
see
if
it's
signed?
You
have
a
big
problem
in
there
because
the
signatures
that
are
done
are
often
with
keys
that
are
quite
old
and
older
keys
still
tend
to
be
trusted.
A
So
what
you
can
do
is
in
attacker's.
You
can
do
something
like
provide
someone
with
an
8
year
old
version
of
send
mail
in
some
cases,
or
some
other
thing
like
that,
and
they
don't
have
a
way
to
know
that
this
isn't
current
valid.
So
what
the
snapshot
role
does.
Is
it
effectively
manages
letting
clients
that
come
to
get
updates
know
what
the
latest
version
of
all
the
software
on
the
system
is
according
to
the
targets?
A
Okay,
so
it
isn't
it's
not
allowed
to
sign
this,
but
it's
it's
allowed
to
tell
you
that
the
latest
version
of
the
metadata
about
the
packages
are
these,
and
so
this
prevents
a
huge
class
of
attacks
that
are
very
hard
to
prevent
in
other
ways.
Ok,
so
tough
is
not
a
hypothetical
thing,
as
you
might
realize,
of
course,
we're
seeing
CF
project
and
incubating
and
were
think
one
vote
away
from
graduation.
So
if
you
know
a
toc
member
that
hasn't
voted
for
us
yet
then
tap
them
on
the
shoulder
in
the
hallway.
A
I
saw
Joe
bata
out
there,
as
I
was
walking
so
tough
a
lot
of
the
early
things
that
happen
with
tough
is
we
worked
with
the
Python
community
very
early,
and
it's
been
standardized
in
that
community
through
a
couple
of
peps
they're
doing
integration.
Now
they
actually
just
redid
their
or
they've,
received
money
for
integration
and
have
picked
people
that
are
doing
this
and
are
in
the
process
and
so
on,
but
they
redid
their
PI
pi,
and
so
it's
taken
them
a
little
longer.
It's
quite
used
inside
the
cloud.
A
Google,
Amazon
and
Flynn
have
all
created
their
own
implementation
stuff
that
they've
open-sourced
and,
in
addition
to
that
there's
an
automotive
variant
of
tough
called
obtain
obtain,
is,
is
widely
used
in
automobiles,
because
the
automotive
industry
is
extraordinarily
secretive.
I
have
to
be
a
little
careful
about
what
I
say
in
this
public
forum,
but
there
are
multiple.
A
There
are
multiple
OMS
in
the
United
States,
multiple
OEMs
in
Japan
and
multiple
OMS
in
Europe
that
have
adopted
obtain,
and
some
of
the
projections
that
we
and
others
have
have
done,
show
that
about
one-third
of
new
cars
on
us
roads
in
three
years,
we'll
be
using
obtained
as
a
way
to
deliver
over-the-air
updates.
So
it's
had
a
lot
of
impact
in
that
space
as
well.
A
Obtained
itself
is
also
standardized
both
by
I
Triple,
E,
isto
and
under
the
Linux
Foundation's
JDF,
so
we're
currently
being
hosted
under
that
and
now
I
want
to
just
very
briefly
talk
about
what
happens
when
something
goes
wrong
in
tough,
and
this
diagram,
I
think
is,
is
a
pretty
easy
way
to
see
this.
So
if
someone
breaks
into
your
repository,
then
they
probably
steal
these
two
keys.
It
slightly
depends
on
your
setup.
A
So
in
the
case
of
someone
breaking
into
a
repository
breaking
into
a
developer,
only
then
there's
no
ability
to
install
malicious
updates
and
they
can't
securely
recover
if
they've
compromised
a
developer
key
and
they've
either
tricked
or
broken
into
the
repository,
and
they
can
do
this,
but
only
for
whatever
project
the
developer
has
access
to.
So
you
know
it's
not
like
you
know.
If
you
steal
one
Debian
developers
key,
then
all
all
Debian
packages
are
suspect.
It's
just
whatever
that
developer
is
able
to
do
and
you
have
a
secure
way
to
recover.
A
If,
if
you
know
they
try
to
do
that
mission,
impossible
ocean,
11
thing
and
break
into
all
those
desk
drawers
for
your
root
Keys,
then,
if
they
don't
steal
a
threshold
of
them,
then
you
can
rotate
out
securely
and
there's
not
a
problem,
but
if
they
do
manage
to
get
you
know
the
the
Acrobat
stuffed
into
the
little.
You
know
tray
thing
and
all
the
other
stuff
like
that
and
do
a
threshold.
Then
yes,
you
do.
You
do
actually
have
a
problem
in
the
system.
A
B
B
You
may
be
wondering
how
that
package
made
it
there
and
in
this
case,
I,
want
us
to
look
at
a
very
cartoonish,
very
simplified
version
of
the
software
supply
chain.
You
probably
have
code
and
a
version
control
system
you'll
probably
put
that
code
in
a
build
farm
that
builds
the
source
code.
Then
it
pushes
it
out
into
a
packaging
infrastructure
that
probably
ends
up
hosting
that
package,
so
the
users
can
get
their
updates
or
their
new
packages.
You
may
also
even
have
a
CI
CD
system.
B
That's
constantly
running
tests
on
the
packages
that
you
are
updating
and
your
programming
with.
So
you
wouldn't
be
surprised-
and
this
is
a
like
security-
talk
that
there's
there
can
be
compromised
data
in
the
same
way
that
the
repository
compromised
can
happen
can
happen
in
other
level.
Other
stages
of
the
software
supply
chain,
you
have
things
like
tampering,
would
get
metadata
or
people
that
break
into
the
version,
control
system
and
change
source
code
as
state
is
checked
in
or
after
it's
checked
in.
If
it's
on
sign,
this
is
not
a
theoretical
attack.
B
This
has
actually
happened
many
times
there
was
a
very
prominent
attack
on
the
Juniper
firewall,
in
which
somebody
broke
into
the
Juniper
fire
wolf
source
code
and
changed
the
pseudo-random
steen
in
such
a
way
that
the
whole
IPSec
stack
was
decrypt,
able
people
even
point
fingers
to
state
Nate
nation
state
agencies.
The
whole
story
is
actually
a
little
bit
disputed
and
there's
many
questions
about
what
actually
happened.
But
again.
B
This
is
not
an
isolated
incident
that
there's
been
many
Tarr
many
people
that
have
been
targeted
on
the
source
code
level
and
in
the
same
way
that
can
happen
to
a
version
control
system.
It
can
happen
to
a
build
form.
There
was
there's
a
big
Turing
Award
lecture
about
backdoor
in
compilers,
but
there's
also
a
very
practical
attack
that
happened
or
over.
A
very
actual
situation
that
took
place
was
execute.
B
Ghost
is
anyone
familiar
with
Xcode
ghost
well
execute
ghost
was
back
during
version
of
the
Xcode
SDK
was
published
in
a
couple
of
servers,
people
downloaded
it
and
any
iOS
app
that
was
built
using
this
version
of
Xcode
ghosts
have
a
backdoor
in
it.
This
iOS
apps
eventually
made
it
to
the
App
Store
and
eventually
made
it
to
users,
and
if
we're
thinking
about
blast
radius,
just
think
about
how
much
people
you
can
attack
by
using
these
attack
vectors,
the
same
thing
happened
to
the
fedora
infrastructure.
Freebsd
again,
this
is
not
an
isolated
incident.
B
I
am
NOT
trying
to
shame
anybody,
but
this
is
the
reality
of
the
situation.
We
already
spoke
about
packaging
infrastructure
I'm
going
to
skip
fast
through
this,
but
I
want
to
make
a
quick
PSA.
If
you
are
a
user
of
Manero
or
know
anybody
that
uses
mineiro
and
have
downloaded
the
wallet
in
the
last
20
days,
there
was
a
compromise
on
Bernero
software
on
the
24th
of
october,
and
many
people
have
downloaded
it
and
have
their
phone
stolen
or
will
have
their
phone
stolen
as
soon
as
they
open.
Yet
this
is
real
and
recent.
B
Now
the
same
thing
can
happen
even
in
at
levels
of
compliance,
there
was
instances
of
Windows
updates,
buggy
Windows
updates,
making
it
to
the
users,
because
the
QA
team
or
the
release
manager
wasn't
able
to
sign
up
or
didn't
or
they'd
sign
off,
and
people
weren't
able
to
enforce
this
sign
of
appropriately,
and
this
means
that
the
users
have
to
pay
the
cost
of
flaky
ways
of
enforcing
compliance.
Now.
I
am
sure
that
probably
many
of
you
saw
there's
like
stylized
software
supply
chain,
this
very
simplistic
model
and
thought.
B
Well,
we
actually
do
things
more
complicated
than
this,
or
why
are
you
telling
me
this
such
a
cartoonish,
simplified
idealistic
way,
but
even
in
this
four
stage,
like
very
even
primitive
software
supply
chain,
there's
many
avenues
of
compromised
and
I've
wagered
that
in
sixth
of
the
nine
six
of
it?
Yes,
six
of
the
eight
they
result
in
full
compromise
of
all
of
the
user
surveys
of
your
software
product.
So
how
can
we
address
this
now?
B
Finally,
we've
spoken
about
tough,
but
even
if
you
use
TLS
and
GPG
that
that
may
even
be
a
bump
in
security
on
what
sometimes
the
status
quo
in
many
of
the
projects
out
there
now,
even
with
point
solutions-
and
you
may
not
be
fixing
the
whole
problem
now,
I
took
the
liberty
of
deleting
some
of
the
Devils
on
the
picture
that
have
eight
levels,
and
now
we
are
down
to
roughly
five.
Am
I
camping
right
six
six
levels?
B
This
is
because
there's
a
question
of
gaps
between
steps,
even
if
you
have
a
point
solution
in
place.
How
are
you
able
to
know
that
this
point
solution
was
a
followed
and
be
that
the
result
of
the
security
measures
on
this
point
solution
were
actually
considered
in
later
steps
down
the
line?
So
we
have,
we
have
point
solutions
and
we
are
not
trying
to
remove
this
point
solution.
We're
trying
to
make
it
so
that
you
can
comply
and
enforce
the
dissapoint
solutions
are
in
place.
B
So
we
came
up
with
a
in
toto
in
toto
is
a
very
simple
way
to
define
a
what
point
solutions
or
what
needs
to
happen
in
each
individual
step
in
software
supply
chain
B
who
can
take
or
can't
partake
in
the
actions
in
this
image,
individual
step
in
the
software
supply
chain
and
C
to
ensure
that
there's
integrity
as
this
artifacts
or
source
code
or
images
or
packages
flow
down
the
chain
into
different
into
further
steps
down
the
chain.
So
we
do
this
with
two
pieces
of
information.
B
The
first
one
is
called
an
total
layout
if,
if
you
are
familiar
with
Jenkins
files
or
make
files,
you'll
probably
find
this
similar.
It
is
not
a
declarative
or
a
executable
piece
of
information,
but
it
does
describe
what
we
were
talking
about
just
here.
It
says:
well,
these
are
the
steps
that
need
to
happen.
It
defines
the
operations
in
software
splattering.
It
also
defines
the
actors
that
need
to
or
can
partake
in
the
operations
in
software
supply
chain.
You
have
Dave,
which
is
running
the
Travis.
B
Ci
infrastructure
probably
has
a
private
key
and
can
sign
for
these
operations.
So
you
are
sure
that
Dave
is
the
one.
That's
actually
running
everything
on
Charlie
CI.
You
also
have
a
mechanism
to
register
or
comment
on
what
are
the
artifacts
that
are
created
and
consumed
throughout
the
chain
when
I
say
artifacts
I
mean
I
mean,
for
example,
the
version
control
system.
B
B
We
want
to
have
a
signature
over
this
piece
of
information,
so
we
know
that
either
the
project
owner
or
manager
or
the
or
the
I
don't
know
PD
FL
of
a
open
source
project.
It's
the
one,
that's
telling
us
what
needs
to
happen
now
that
we
now
that
we
know
what
needs
to
happen.
We
also
need
evidence
of
what
happened,
so
we
can
compare
it
and
make
sure
that
this
is
actually
what
happened.
So
we
have
this
other
piece
of
information.
We
call
this
in
total
links.
B
Finally,
when
we
have
all
of
this
information
collected,
you
can
essentially
run
a
verification
routine
that
takes
this
layout
and
this
pour
in
this
policy
language
and
compares
it
against
the
evidence
in
the
linked
metadata
and
make
sure
that
everything
is
following
that
followed.
According
to
the
letter,
there
is
many
users
of
in
total
already
out
there.
There
is
Dana
dog,
which
is
the
data
dog.
It's
protecting.
Many
of
you
probably
are
using
services
on
that
box,
and
you
are
thereby
protected
by
in
toto
there's
other
users
that
are
using
in
toto
in
different
ways.
B
The
nature
of
in
total
that
lets
you
represent
different
supply
chains
in
a
very
flexible
and
rich
way,
makes
it
so
that
it's
easy
to
implement
in
many
in
many
of
their
different
ecosystems.
I
am
actually
because
I've,
given
there
most
of
other
things
today,
I
will
try
to
make
one
of
the
quickest
demos
in
the
world,
but
a
Debian
has
a
is
working
very
hard
in
the
reproducible
builds
project
and
something
really
cool
that
you
can
do
within
toto
is
there's
your
builder
organizations.
B
One
of
them,
for
example,
is
Microsoft
another
one
is
saying:
well
you
there's
University
of
Bergen.
There
are
basically
monitoring
what
Debian
is
building
and
pushing
out
in
their
official
repositories,
and
then
there
they
are
pulling
out
this
information
that
they
are
rebuilding
this
packages,
and
then
they
are
publishing
in
total
agreement
of
data.
This
evidence
I
was
talking
about.
B
Then
there
is
a
layout
that
I'll
show
you
in
a
second
that
says:
well
all
of
the
people
who
rebuilt
this
of
this
different
organization
that
we
trust
needs
to
agree
on
the
result
of
the
of
each
individual
package
that
you
were
downloading,
so
I'm
going
to
go
ahead
and
do
this.
We
are
pretty
much
in
line
so
I'll
try
to
be
quick.
B
So
probably
yeah
so
I'm
going
to
spin
up
a
little
cluster.
Is
this
text
readable?
It's
probably
better?
We
have
a
malicious
mirror.
We
have
to
rebuild
errs
that
are
rebuilding
our
demo
package.
Then
we
have
a
client
and
then
we
have
a
yeah,
the
malicious
mirror,
one
malicious
mirror.
One
client,
one
good
mirror
and
Torrie
builders
that
are
rebuilding
our
demo
package,
so
I'm
going
to
quickly
jump.
B
Here
and
if
I
didn't
screw
up,
I
should
get
a
shell.
Did
I
get
a
shell?
Oh
yes,
okay
do
I
have
Bosch
just
so
we
okay
cool,
so
we're
here.
All
of
what
I
have
to
do
is
is
make
this
little
edit
and
right
now,
I
have
HTTP
mirror.
Okay,
Debian
I
am
going
to
change
this
to
in
toto,
then
I'm
going
to
app
get.
B
So
what
this
is
going
to
do
it's
going
to
there's
about
things
that
went
on
here,
but
is
this
blue
I
think
it's
blue?
Basically
it
downloaded
the
Debian
metadata
that
it
downloaded
a
bunch
of
had
stations.
That
said
all
of
this
package,
all
of
the
package
that
you
downloaded
was
rebuilt
by
enough
people
so
that
you
can
trust
that
it
was
reproducible
built
and
by
the
people
that
you
trust.
So
this
is
very
uneventful.
So,
let's
try
to.
B
And
then
we're
going
to
do
the
same
I'm
going
to
remove
this
guy.
Yes,
what
we
can
install
it
again
and
then
we're
going
to
install
it
again.
The
the
malicious
mirror,
of
course,
was
being
malicious.
It
actually
replaced
the
one
of
the
one
of
the
packages
with
a
malicious
version
of
it,
but
even
though
it
was
signed
by
the
right
people
on
the
Debian
side,
hearing
of
injected
the
rebuilders
didn't
agree
with
that
result.
B
So
we
were
told
that
there
was
not
a
threshold
of
people
that
are
green
on
the
reproducibility
of
this
package,
and
thus
you
are
not
going
to
install
it.
There's
of
course,
questions
that
we
can
address
about
the
usability
of
this
tool.
I
think
it's
a
little
bit
rough
on
the
edges
right
now,
but
you
can
do
things
like
this,
but
such
an
expressive
mechanism,
so
just
to
close
up.
This
is
not
the
work
of
just
me
and
Justin.
There's
many
people
involved
and
working
very
hard,
and
it
should
be
well.
It
would
be
great.
A
B
B
First
of
all,
fully
full
software
software
hardware
secured
software
supply
supply
chains
purely
using
internal
in
such
a
way
that
you
can
use
taint
analysis,
information
and
carry
through
this
add
stations,
and
you
can
have
a
hardware
accelerated
in
total.
A
secured
piece
of
hardware
I
think
that's
pretty
cool.
That's
actually
some
work
that
we're
trying
to
do
with
the
SP
DX
and
the
Saffir
project,
which
is
a
real-time
operating
system,
that's
being
used
in
like
many
different
environments,
there's
also
work
on
the
Debian
side
on
making.
B
Not
only
this
metadata
available
by
different
may
differ
rebuilders,
but
this
rebuilders
gossiping
a
transparency
law
in
such
a
way
that
you
can
have
a
high
availability
case
for
holding
total
minute
data
and,
finally,
we're
trying
to
find
the
sketchy
cases
of
these
software
supply
chain.
Compromises
like
the
Monaro
that
I
just
spoke
about,
we've
been
finding
that
there's
many
deep
supply
chain
dependencies
that
can
be
used
to
cause
and
wreak
havoc
on
users,
yeah.