►
From YouTube: TAG Security Supply Chain WG 2022-02-10
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
Yeah
yeah,
how
was
he,
how
was
the
response
to
that
git
bomb
meeting.
A
It
went
really
well.
The
meeting
itself
went
well,
I'm
actually
in
the
process
of
marshalling
out
an
email
pointing
to
the
meeting
minutes
to
the
mailing
lists,
we're
getting
good
traction
on
the
slack
channel,
including
which
folks
wandering
in
we
got
lots
of
good
responses
to
the
initial
tweet.
So
you
know
we're
getting
traction.
It
looks
like
one
of
the
more
challenging
things
at
this
point
is
going
to
be
sort
of
balancing
email,
people
versus
slack
people
in
terms
of
keeping
the
communications
flowing.
A
We've
got
a
couple
folks
who
brought
up
tools
at
the
the
community
meeting.
The
various
parks
have
been
in
progress
apparently
and
they're
they're
sort
of
rough
and
ready,
but
they're
trying
to
sort
of
get
some
of
them
out.
I've
got
some
on
my
end,
where
I'm
clearing
them
through
our
open
source
process
to
get
them
out
so
yeah
hitting
the
ground
running.
B
Good
yeah,
it's
exciting,
I
think
you
know
we
got
a
little
bit
of
work
to
do
on
the
explaining
exactly
what
it
does
it
seems,
but
that
will
come
in
time
right.
We
got
to
figure.
A
B
So
I
haven't
been
to
these
lately
is
andre
still
leading
it
or
what's
going
on.
D
D
Yeah
this
they
don't
allow
zoom
on
my
work
laptop
anymore,
so
it's
browser
hell
all
the
time.
D
D
D
Okay,
I
think
michael
should
be
coming
on
soon.
I
know
our
interest
is
out.
E
E
Okay,
okay,
yeah,
so
yeah.
Just
as
a
reminder,
you
know
this
meeting
falls
under
the
cncf's
code
of
conduct
and
also
this
meeting
will
be
recorded
and
will
be
put
up
on
youtube.
E
E
We
took
it
down
from
52
53
pages
down
to
about
33
pages
and
and
without
actually
really
removing
any
valuable
content,
mostly
just
trying
to
either
push
specific
details
that
are
not
really
related
to
the
architecture,
either
citing
them
to
the
best
practices
paper
or
just
putting
that
in
supplementary
material,
or
you
know
linking
to
supplementary
material.
E
So
now
and,
as
you
know,
celeste
as
many
of
you
know,
celeste
is
no
longer
at
the
cncf.
So
she's
not
reviewing
the
paper
a
second
time,
but
we
do
have
somebody
who
should
be
reviewing
the
paper
I'm
going
to
try
and
follow
up
with
them
shortly.
D
Well,
so,
michael,
I
think
I
think
if
we
we
should
wait,
probably
for
do
the
rsc
and
then
do
a
second
review.
Yeah.
E
Yeah
sounds
good
to
me,
so
maybe
you
and
I
can
sync
up
after
this
meeting
just
to
kind
of
I
don't
remember
all
the
exact
details
of
of
how
to
make
that
statement
and
and
make
sure
that
it's
it's
all
good,
but
yeah
cool,
so
yeah
so
and
then,
while
that's
going
on
yeah
nate
wadding
will
eventually
come
in
and
give
a
second
sort
of
pass-through
of
the
paper
and
yeah.
That's
that's
about
it.
E
E
D
I
see
that
kind
of
like
still
like
some
edits
here
and
there
at
least
on
the
on
the
dock.
Is
that
something
that
we
still
need
to
discuss
as
a
group?
Or
is
this
all
the
added
kind
of
minor
things
that
we
think
we
can?
You
know
we
can
just
go
through,
accept
everything
and
then
be
ready
for
rvc.
E
Let
me
just
double
check
and
look
through
here.
I
think
most
of
these
are
stuff,
we've
already
addressed
and
should
probably
kind
of
figure
out,
or
you
know,
they're
they're,
relatively
minor,
okay,.
D
Cool
yeah
yeah,
then
then
we
can
figure,
we
can
just
go
through
these
offline
and
then
we
will
we'll
get
it
we'll
get
rfc
started
and
everyone
should
retweet
it
for
your
friends
and
all
in
that
one.
E
Yeah,
I'm
just
gonna
accept,
there's
a
couple
of
alex
floyd
marshall's
things
which
were
just
some
last
minute,
cleanups,
which
I
forgot
to
click
the.
D
Button
on
yeah
and
we
may
end
up
creating
a
copy
of
the
document
for
rc
for
permission
issues.
So
just
take
note
of
that
in
case
you
you're
looking
at
the
wrong
document
yeah.
I
think
that's
it
for
me
so
cool!
Oh,
yes,.
B
All
right
well,
thank
you
all
very
much.
I
know
mikhail
and
I
haven't
been
to
a
lot
of
these
working
groups
lately,
but
we've
been
really
busy
writing
a
lot
of
code,
so
we're
excited
to
kind
of
show
you
what
we've
been
working
on
over
the
past
few
months,
we've
recently
released
witness
under
open
source
apache
2.0
license.
There's
a
github
repo
at
github.com
testify
witness
where
everything's
available.
B
B
All
right,
so
really,
what
we're
doing
with
witness
is
we're
creating
a
framework
for
an
attestation
based
security
model
right,
and
I
got
this
little
artifact
here
from
the
salsa
website
right.
So
your
your
artifacts,
you
create
attestations
for
those
artifacts
right.
You
can
feed
those
into
a
policy
engine
and
feed
your
policy
into
that
policy
engine
and
on
the
other
side,
you
get
a
decision.
So
this
is
where
we
are
at
with
witness
right
now.
B
We've
implemented
this
as
a
cli
tool
and
as
a
library,
so
that
library
can
be
implemented
in
any
number
of
downstream
tools
right
now,
we're
working
on
an
emission
controller,
which
is
probably
the
most
the
the
easiest
use
case
here.
So
how
do
we
actually
do
this
right?
So
any
piece
of
evidence
that
we
have
along
our
software
delivery
life
cycle
can
be
attested
to
in
this
image.
I'm
showing
about
commands
static,
testing,
build
automated
testing
right.
We
can
create
attestations
for
all
things.
B
The
other
thing,
too
is
we
can
create
attestations
for
just
about
anything
right
in
an
enterprise
environment.
We
have
a
lot
more
things
that
we
have
to
worry
about
when
we
bring
that
software
into
that
production
environment
right,
we
want
to
know
where's
the
country
of
origin
for
the
company
that
made
it
right.
We
want
to
know
the
background
financials
for
that
company
and
a
bunch
of
other
things.
B
Those
are
also
things
that
we
can
bring
in
to
create
attestations
about
and
bring
it
into
the
decision
cycle,
the
automated
decision
cycle,
and
that
way
we
only
have
verified
software
that
makes
it
into
the
execution
environment.
We
know
that
it's
only
verified
because
we
actually
have
a
policy.
That's
cryptographically
signed
that
says:
hey
make
sure
that
these
attestations
exist
and
these
the
stations
have
certain
attributes
or
selectors
on
them
that
we
we
select.
B
So
what
does
that
actually
look
like
in
practice?
Actually,
I'm
gonna
go
over
to
the
github
repo
and
kind
of
talk
about
this
life
cycle
here,
we'll
talk
about
the
attestation
life
cycle
first,
so
we've
separated
these
testers
into
two
separate
categories.
We
have
our
pre-attestors
and
we
have
our
post-it
testers,
the
material
command
run
and
product
testers.
Those
are
internal
testers
to
the
framework
right
and
they
run
in
a
defined
order.
The
pre-attest
is
always
run
before
the
command
run.
B
You
know
within
that
at
the
station
context
of
the
other
testers,
then
we
pass
all
that
context
down
to
the
command
runner
tester.
The
command
runner
test
is
what
we
actually
wrap
the
process
that
you
specify
with
right.
So
that
allows
us
to
a
lot
of
special
things.
We
have
some
alpha
tracing
support
that
we
collect
every
file
intermediate
file
every
every
every
sys
call
right
that
that
that
process
makes
we
can
grab
and
inspect
and
record
and
create
an
attestation
lot.
That's
pretty
pretty
early
right
now.
B
We
have
some
basic
support
for
that.
So
then
we
go
into
our
product
assessor
right.
Anything
that
didn't
exist
in
that
context
beforehand
will
now
be
considered
a
product
and
we'll
calculate
the
chassis
off
of
that
and
calculate
the
mime
type
pass
that
down
to
the
posted
tester,
where
we
can
then
make
it
at
the
station
and
normalize
any
of
that
output
data
right.
B
So
once
we
get
all
those
at
the
stations,
we
bundle
them
together.
What
we
call
an
attestation
collection
and
we
shove
them
into
an
envelope-
and
we
assign
that
envelope
right
now.
The
envelope
that
we
support
is
dsse,
really
easy
to
use
and
for
key
providers.
We
support
file
type
key
providers
as
well
as
50
spiracy
providers
right
we're
going
to
have
more
support
for
different
key
providers
in
the
future.
B
So
then
we
get
all
that
sign
it,
and
then
we
push
it
to
a
store.
We
support
two
stores
right
now:
recore
and
a
file
based
store
now
recore
is
really
special
because
we
actually
get
a
time
stamp
on
that
envelope
when
we
store
it
in
record,
which
means
that
our
key
provider
can
issue
short-lived
certificates
to
that
envelope,
because
we
can
validate
that
that
that
envelope
was
signed,
while
those
keys
are
actually
valid.
B
B
All
right,
so
what
we're
going
to
actually
do
is
the
first
thing
we're
going
to
do
is
we're
going
to
create
some
cheese?
Actually,
so,
let's
create
some
keys.
B
That
looks
like
it
should
work
all
right
and
then
we're
going
to
actually
look
at
that
dot.
Witness
dot,
yellow
so
in
toto
doesn't
support
a
config
file.
We
thought
this
would
be
make
it
a
little
bit
easier
to
drop
into
a
ci
repo,
so
you
can
see
we're
looking
for
when
we
do
a
witness
run,
we're
looking
for
that
private
key
deskee.pam
and
for
the
verify
we're
looking
for
the
public
key
testpub.com
great.
C
B
All
right,
you
can
see
the
functionaries
right
here.
We
have
this
public
key
id
and
then
right
here
this
is
actually
the
keys
that
are
going
to
assign
the
attestation
right
now
we're
overloading
the
keys
for
this
demonstration
and
using
the
same
keys
to
sign
the
policy
as
the
same
key
to
sign
the
actual
at
the
stations
right,
an
enterprise
environment.
These
are
scopes
that
generally
be
separated.
B
So
this
is
where
you
would
define
the
public
key
for
the
thing.
That's
signing
the
attestations
or
right
with
their
certificates,
constraint,
support
that
we've
added
right.
We
actually
use
a
certificate
authority
and
constrain
the
functionaries
based
upon
that
which
works
really
great.
If
we're
using
something
like
a
spiffy
id,
and
that
way
we
can
issue
these
identities
based
upon
the
actual
workloads.
That's
making
that
build
happen.
B
You
can
see
we
put
those
in
right.
There.
We've
got
those
templated
out,
because
I
got
this
little
said
script.
That'll
make
this
a
lot
easier.
D
B
Yeah,
so
if
you
look
at
these
policies
and
I'll
show
you
what
happens
when
it
changes
a
little
bit
later
on
the
demo
all
right,
so
each
of
these
attestations
has
a
name
space
and
type
and
a
version
to
it
right.
So
this
is
this
is
what
we
found
was
really
the
big
issue
with
with
like
trying
to
analyze
test
data
and
we're
just
shoving
it
out
to
some
elastic
search
right.
It's
not
normalized,
and
we
can't
create
policy
and
me
in
any
meaningful
way.
B
Unless
we
have
that
data
normalized.
That's
why
you're
seeing
all
these
solutions
up
that
are
like
taking
ai
engines
that
try
to
ingest
this
data
and
just
come
up
with
a
solution,
whether
it's
good
or
bad
right,
we're
not
doing
that
here.
We're
actually
normalizing
the
data
creating
policy
on
that
actual
data.
These
these
attestations
type
when
we
go
to
dig
to
the
code
in
a
second
you'll,
see
that
those
line
up
with
the
actual
attestations
that
that
were
feeding
into
the
the
factory
does
that
answer
your
question.
C
B
So
the
next
thing
we're
going
to
do
is
we're
going
to
sign
that
policy
right
so
and
then
this
policy
is
the
gatekeeper
to
wherever
you
are
deploying
this
workload
right.
So
this
is
going
to
be
like
your
sizzle
for
the
enterprise
that
says.
Okay,
let
me
look
at
this,
make
sure
it
meets
what
our
organizational
policy
is
they're
going
to
stick
in
the
hardware
token
and
they're
going
to
sign
it
right.
So
we
got
that
signed
now
we
can
actually
do
a
verification
using
the
built
in
cli
verification
right.
B
B
No,
they
don't,
which
is
great,
and
then
we
can
do
witness
verify
and
pray
to
the
demogods
right
works
great.
So
the
next
thing
we're
going
to
do
is
we're
going
to
actually
change
our
policy
right.
So
we're
going
to
say:
oh
look
at
this,
so
we
want
to
make
sure
that
everything
that
is
verified
that
passes
verification
is
actually
built
on
a
gcp
cluster
right
and
we
can
actually
lock
this
down
since
it's
like
any
of
the
metadata
that's
available
in
issue,
but
we're
actually
not
going
to
dive
into
the
rego
policy.
C
B
B
B
So
what
we
really
like
about
this,
and
what
what
mikael
kind
of
designed-
and
I
wish
you're
here
to
talk
about
a
little
bit,
but
you
couldn't
make
it
today.
B
If
you
go
to
the
package
at
the
station
kind
of
see,
this
is
our
secret
sauce.
All
these
are
really
compostable.
There's
this
factory
that
registers
these
attestations
at
runtime.
So
you
get
to
select
what
attestations
you
want
to
use
and
they're
really
easy
to
actually
put
together
so
we're.
Looking
at
like
this
gcp
iit,
I
shamelessly
stole
some
of
this
code
from
the
spiky
spider
project,
but
you
know
within
you
know
two
250
lines
of
code.
B
D
I'll
get
to
a
quick
question
on,
like
the
let's
say,
using
gcp
build
right.
How
do
you,
how
are
you
right
now
doing
the
key
material
and
passing
it
around.
B
So
what
we're
doing
is
we're
just
validating
that
jwt
we're
expecting
signing
that
attestation
is
that's
where
your
trust
model
comes
from
right,
so
that
might
be
some
enterprise
pti
system,
okay,
I
could
be
you
know-
maybe
you're
using
in
the
future
we'd
have
a
plug-in
for
vault,
where
you
get
your
keys
from
vault
right
or
maybe
you're
using
the
tpm
on
there.
I
think
there's
a
different
bunch
of
different
ways.
B
We
can
do
that
key
provider,
but
those
are
providing
that
trust
for
that
node
right
and
then
what
we're
doing
is
we're
layering.
These
secured
attestations
on
top
of
it,
but
where
the
trust
model
breaks
down
is,
if
we're
just
trusting
that
node
and
then
creating
these
attestations
without
some
sort
of
outside
verification.
B
It's
still
better
than
nothing
right.
It
gets
us
at
that
salsa
level,
one
because
we're
recording
the
metadata,
but
in
order
to
actually
get
to
that
salsa
level,
three
four:
we
need
that
node
verification
right
here.
We're
doing,
I
think,
we're
doing
workload,
verification
just
because
we're
recording
everything
about
that
workload.
B
Just
because
we're
not
verifying
it
necessarily
or
let
me
back
up
a
second,
because
none
of
this
is
actually
hitting
production
environment
right
now.
These
are
not
actually
running
workloads.
I
it's
sufficient
enough
just
to
collect
enough
metadata
to
actually
do
the
verification
at
a
later
point.
We
don't
need
to
actually
do
the
workload
verification
at
this
point
right.
We
can
do
the
workload,
verification
and
execution
time
just
because
we're
not
actually
in
a
production
environment.
C
B
Right
so
we
chose
rego
for
two
reasons:
one
is
in
our
enterprise
version.
We
want
to
support
external
policy
to
integrate
with
you
know
things
like
styro
das
and
open
policy
agent.
It
works
really
well
there
also
rigo.
B
One
thing
we
hear
from
our
customers
is
that
they
really
want
to
get
a
reason
for
a
policy
rule.
Denial
right,
just
say:
hey
this
policy
failed
is,
is
generally
too
opaque
to
actually
get
any
good
debugging
going,
so
rigo
allows
us
to
actually
give
that
policy.
Denial
of
reason,
we've
designed
the
data,
the
schema
in
a
way
that
it's
really
easy
to
add
additional
policy
types
to
it,
and
we
think
that
that
cue
is
definitely
something
that
we
can
use
to
simplify
the
policy
creation
in
the
future.
C
Okay,
good
another
question
this:
this
kind
of
I
mean
witness,
can
also
be
used
as
a
dependency
like
a
library
right
that
you
can.
You
need
to
use
only
the
cli
or
or
at
this
point
is
modular
enough
to
just
call
certain
functions
or
interfaces.
B
Yeah
yeah
there's
public-facing
functions
that
you're
free
to
use
we're
gonna,
I
mean
we're
gonna,
do
we're
at
version
0.1
right
now,
so
I
mean
you're.
I
don't
know
how
much
is
going
to
change,
but
we're
really
going
to
try
to
keep
that
gold
compatibility
compatibility
into
you
with
our
public
facing
api
right
now.
In
fact,
I'm
there's
some
stuff.
I
think
we
got
to
work
through
still
a
little
bit,
but
I
am
actually
building
a
mission
controller
with
that
library
right
now.
B
So
I
think,
once
I
get
a
little
bit
further
on
that,
that
api
might
be
a
little
more
stable.
Well
as
as
we
just
use
it
internally
here,
what
some
of
the
stuff
we're
doing.
B
So
what
we
have
is
we
have
these
in
total
statements
and
we
have
every
a
tester.
Has
these
things
called
subjects
that
they
they
emit
in
anything
that
you
create
a
subject
on?
We
can
is
indexed
by
recall.
We
can
go
ahead
and
look
that
up
so
we
can
see.
We
can
now
look
up
this
artifact
by
the
actual
commit
hash
that
was
made
because
that's
in
the
get
a
tester,
and
we
can
also
look
it
up
by
this
fi
file-
hash
right
here.
B
So
if
we
search
record
for
any
of
these
two
things,
this
will
come
up
so
like
in
the
gcp
iit
a
tester
right.
We
have
like
similar
stuff
like
that,
that
we
can
look
it
up
by
we
record
the
entire
environment
metadata.
We
know
that.
Okay,
we
have
a
get.
This
get
a
tester,
so
we
know
that
this
build
actually
had
some
untracked
us
changes
or
unstaged
changes.
So
we
can
create
policy
against
this
and
say
hey
make
sure
that
your
your
get
tree
is
clean
for
anything.
B
You
build
in
it
that
that
so
that
way
that
doesn't
make
it
into
production,
and
then
we
have
the
material
tester
here
right.
That's
just
grabbing
everything.
That's
in
that
context
and
bringing
it
in
and
then
this
is
our
command
run
a
tester.
Now
this
is
running
in
non-tracing
mode
and
then
our
product
to
tester
right
we
have
the
mime
type
for
the
output
and
the
shot
256
right,
and
then
this
this
is
available
to
any
posted
testers
too.
So
this
is
kind
of
this
is
what
we
use
in
our
oci.
Tester
is
hey.
B
We
have
a
tar
file
that
was
output
from
a
docker
save,
so
let's
open
that
up
and
just
calculate
all
the
metadata
and
then
push
think
index
out
of
great
attestation
about
that
to
record.
B
And
actually,
when
we
put
tracing
on,
we
can
see,
we
got
every
single.
B
We
can
see.
Actually
what
program
use
was
used
to
compile
it.
The
sha
sum
of
that
program,
as
well
as
all
the
information
right.
We
even
see
that
hey
my
machine.
I
have
the
spec
bypass
vulnerability.
I
I
I
don't
have
that
turned
on
right
now,
so
you
know
more
performance,
because
it's
my
own
personal
machine,
so
we
can
create
policy
even
on
stuff,
like
that,
once
we
start
doing
some
more
inspection
of
using
s
trace
all
right,
so
we
know
every
single
file
that
went
into
this
compiler.
B
I
know
ed's
been
doing
some
work
around
the
around
some
of
this
stuff.
Getting
this
information
into
the
actual
help
files
too
but
anyways,
I
think
that's
all
we
have
for
witness.
So
if
anyone's
got
any
questions-
and
I'm
here
here
until
the
end
of
the
time.
A
E
I
know
this
is
probably
for,
for
you
know,
further
down
the
line,
but
I'd
be
curious
to
know
like
what
thoughts
you
might
have
around
either
witness
sort
of
managing
the
sandbox
for
things
that
it's
going
to
be
rapping
or
or
where
you
see
sort
of
that
kind
of
coming
together.
Do
you
see
that,
as
like
hey,
we
would
recommend
that
witness,
let's
say
wraps
a
trusted
build
process
and
that
trusted
build
process?
E
Does
a
lot
of
the
sandboxing
and
witness
is
more
or
less
just
sort
of
acting
as
the
the
tool
to
sort
of
record
all
that
information,
or
do
you
see
witness
as
being
the
thing
that
does
the
same
boxing.
B
B
There's
some
benefits
there
as
far
as
recording
having
more
accurate
recordings
of
what's
going
on,
whether
that's
going
to
help
with
sandboxing
yeah,
probably,
but
that's
really
not
the
point,
and
that's
not
what
we
want
to
do
right
with
the
witness.
What
we
really
want
to
do
is
put
as
many
sensors
into
this
build
process
as
possible.
B
That
way,
you
know
when
we
have
an
unknown
unknown
in
our
build
system,
we
probably
will
have
the
metadata.
We
need
to
mitigate
against
that
situation
right,
and
this
is
what
we
really
looked
at.
You
know
you
look
at
heartbleed
right
if
we
had
a
witness
metadata
for
every
single
build
into
that.
That
happened
with
heartblade
right
we'd
be
able
to
mitigate
that
very
quick
there's
a
demo
in
the
repo
I'm
not
going
to
go
through
it
right
now,
but
it
shows
how
we
can
use
this
information
to
mitigate
it
against
log4j.
B
We
have
a
maven,
a
tester
that
you
know,
creates
attestations
based
upon
and
indexes
based
upon
maven
packages
that
are
in
that
context
right
so
once
we
start
layering
all
this
stuff
together
and
you
create,
you
know
your
customer
testers
for
whatever
environment.
That's
specific
to
your
needs
right.
I
think
it
solves
a
lot
of
those
problems.
C
C
C
D
B
Yeah
and
that's
one
of
the
things
right,
I
think
there's
going
to
be
different
levels
of
detail
for
different
organizations,
there's
obviously
a
cost
right.
I
think
when
we,
when
we
ran
witness
against
the
linux
kernel,
build
at
the
station
end
up
being
like
600
megabytes,
so
maybe
that's
not
the
best,
but
but
right
we
we
create
attestation
of
an
asset
station
to
kind
of
reduce
that
down
a
little
bit.
B
There's
things
we
can
do
around
that,
but
just
having
that
information
available
to
whatever
workflow
you
want,
I
think,
is
important,
because
what
we've
done
is
we've
effectively
moved
the
policy
enforcement
point
outside
of
the
ci
pipeline
to
wherever
you
want
to
put
it
and
that
decouples
all
these.
All
these
little
things
that
were
tightly
coupled
to
ci
pipeline
now
are
not
now.
This
lets
us
create
trusted
pipelines
between
different
infrastructures
that
allows
us
to
create
trusted
pipelines
between
different
organizations
right
because
we
have
different
routes
of
trust
that
we
can
validate
against.
D
Yeah,
I
think
policy
is
one
of
those
things
that
that
we
kind
of
keep
going
back
into
at
these.
You
know,
and
some
of
the
discussions
I'm
having
is
like
yeah.
We
have
all
this
information,
but
don't
really
know
what
to
do
about
it.
Oh
it's
not
in
the
format,
which
is
consistent,
that
we
can
make
clean
policies
or
sensible
policies
out
of
yeah.
B
E
And-
and
in
case
I
missed
something,
I
would
love
to
kind
of
chat
at
some
point
over
like
just
sort
of
thinking
through
some
of
this,
like
if,
if
right
like,
if,
if
the
build
process
that
witness
is
rapping
right,
if
if
it's
still
run
under
the
user,
with
the
same
permissions,
wouldn't
it
be
able
to
potentially
access
the
memory
from
witness
and,
like
you
know,
start
poking
around
like.
B
It
yeah
it
is
you're
right,
but
that's
why
we
have
to
have
external
trust
that
build
node
right
either
through
remote
at
the
station
using
spiff
expire,
which
is
our
current
trust
model.
The
other
way
you
could
do
it
is
have
like
something
like
falco
running
that
note
and
have
a
good
falco
rule
set
for
witness,
because
now
you
identified
where
what
process
space
your
build's
running
in
so
it
makes
a
lot
easier
to
create.
You
know
runtime
policy
against
it.
B
Oh
there's
one
more
side
effect.
I
forgot
to
mention
when
you,
when
you
run
s,
trace
on
a
on
a
process,
nothing
else
can
actually
run
s
trace
on
it.
So
there's
a
demo
and
I
mean
for
people
that
actually
know
how
it
works.
It's
not
that
impressive,
but
it
actually,
when
you
run
trace
on
this
build
process,
you
mitigate
the
exact
attack
vector
that
was
used
in
the
solar
winds
attack.
Now,
maybe
they
could
use
bpf
right,
we're
not
analyzing
a
lot
of
the
files
yet
stuff.
E
Yeah,
that's,
I
think,
a
few
of
the
other
tools
out
there,
like
you're,
your
falcos
and
and
and
whatnot
also
do
that
same
sort
of
thing
is
like
if
you
open,
if
you
just
leave
sort
of
an
you
know,
if
you're
not
even
do
anything
with
the
s
tracey,
just
sort
of
leave
that
connection
open,
then
nobody
else
can.
B
We
can
do
without
any
elevated
permissions
right.
I
didn't
run
sudo
for
any
of
this
stuff
because
we're
wrapping
that
process.
We
have
full
permissions
over
that
process,
so
this
runs
perfectly
well
in
a
container.
This
compiles,
you
know,
runs
on
arm.
This
will
pretty
much
run
anywhere
as
long
as
like.
If
you
have
a
redirect,
because
you're
doing
like
a
docker
build
over
over
a
socket
right,
we
don't
we
don't
trace
that.
B
E
C
E
All
right
well,
thank
you,
cole.
Just
to
reiterate
to
anybody
who
sort
of
I
noticed.
A
couple
of
folks
had
joined
a
little
leader
in
the
meet
so
as
a
reminder
that
the
the
ref
arc
doc
is
is
going
to
be
going
out
for
a
request
for
comment
from
the
community.
E
Hopefully
soon
once
I
figure
out,
I'm
gonna
be
working
with
brandon
after
this
meeting,
just
to
kind
of
get
that
all
sorted
out
and
it
should
be
going
out
as
a
reminder
from
last
time.
You
know
we
brought
down
the
the
paper
from
like
52
or
53
pages
or
so
down
to
like
32
33
pages,
which
is
in
a
much
better
spot.
E
We
didn't
delete
any
you
know
useful
content,
but
we
just,
let's
just
said,
hey
specific
details.
We
really
want
folks
to
look
at
best
practices,
paper
and
other
sorts
of
supplementary
material.
We
want
folks
to
sort
of
mostly
focus
on
the
high
level
architecture
in
this
this
document,
so
that
information
will
also
be
going
out
to
the
the
community
as
part
of
the
request
for
comment
and
then
the
other
thing.
E
Just
as
a
reminder,
you
know
so
celeste
who
was
doing
the
review
has
left
the
cncf
and
somebody
else
be
joining
on
to
nate.
Waddington
will
be
also
reviewing
the
paper,
as
we
kind
of
after
the
request
for
comment
and
all
that
sort
of
stuff
is
over,
and
so
that's
all
the
updates
on
the
the
ref
arc
side,
yeah,
any
other
sorts
of
things.
You
know
any
other.
E
Any
questions
comments,
any
topics
that
they
want
to
discuss
any
topics
that
they
think
would
be
useful
for
next
week.
Any
demos
in
upcoming
weeks
or
anything
like
that.
A
Yes,
so
I
think
we
added
a
little
bit
of
the
agenda
just
to
sort
of
call
out.
We
come
past.
We
had
come
back
past
this
group
before
talking
about
git,
and
so
the
git
bomb
community
is
actually
finally
launched.
There's
sort
of
a
lot
of
milling
about
chatting
with
folks
making
sure
that
you
know
it
made
sense
to
a
bunch
of
people
and
so
I've
stuck
into
the
agenda.
Some
links
to
the
you
know
launch
announcement.
They
get
the
git
bomb
website.
A
It's
always
embarrassing
when
people
tweet
threads
that
are
better
than
your
your
concerted
attempts,
but
I
don't
know
how
many
folks
remember
when
we
came
through
to
discuss
get
bomb
prior,
but
it's
effectively
a
very
simple
scheme
to
allow
you
to
have
your
build
tools,
build
a
compact
artifact
tree
for
what
they've
just
built
and
essentially
embed
a
unique
identifier
into
the
resulting
artifacts
being
built,
and
we've
actually
got
some
interest
from
folks
in
various
language
communities
and
incorporating
this,
because
it's
small
enough
and
simple
enough
that
it
actually
makes
sense
in
the
compiler.
A
For
linker,
sort
of
sort
of
just
by
way
of
comparison
and
all
bad
props
code
here
call
what
we're
doing
is
much
simpler
than
what
you're
doing.
But
I've
got
a
little
bit
of
pop
tooling
I'm
trying
to
drive
out
from
where
I'm
sitting
to
the
open
source.
Right
now
that
we've
run
against
the
linux
kernel
and
where
you
were
getting
600
megabytes
of
total
data
out,
we
were
winding
up
with,
like
824k
now,
admittedly
you're
doing
a
lot
more
but
yeah
to.
A
B
Yeah,
having
that
common
data
format
to
to
to
describe
the
artifactory
will
be
very
useful.
I
think
it's
something
we're
looking
for
so
an.
B
C
Pieces
of
git
bomb
is
enabling
to
chain
between
different
build
processes
like
if
something's
implemented,
witness
in
one
step
and
that
artifact
is
then
consumed
in
the
next
build
step
and
that
one's
a
different
project.
Different
language
doesn't
use
witness.
As
long
as
they'll
use
the
same
git
bomb
identifier
format,
it
can
all
chain
together.
A
And
hopefully,
by
driving
this
out
into
the
various
sort
of
primary
build
tools
like
compilers
and
linkers
and
those
sorts
of
things
it
becomes
something
that's
sort
of
ubiquitously
there,
the
developers
don't
have
to
think
about
because
developers,
you
know
the
mill
developer
is
not
nearly
as
excited
about
instrumenting
their
lives
as
we
are.
C
C
Lists
yeah,
we'd
love
for
folks
to
join,
show
up.
Tell
your
friends
bring
a
dish
to
the
picnic
you
know.
Whatever.
D
E
And
ed
once
you
have
some
of
that,
I
know
you.
You
mentioned
some
of
the
the
you
want
to
show
hoping
to
open
source
a
few
things
once
you
do.
Definitely
love
to
yeah.
Okay,
see
you'll,
see
more
of
that.
There.
A
Okay,
yeah-
and
I
I
I'm
going
through
that
embarrassing
process
where
you
realize
that
people
don't
tell
you
things
inside
your
own
company,
because
I
keep
tripping
across
people,
who've
been
doing
various
pieces
of
pop
work,
but
now
I'm
trying
to
shut
towards
the
open
source
and
what
is
sort
of
a
pseudo
instrumentation
to
sort
of
give
you
something
to
keep
the
tires
with
before
we
get
things
into
compilers.
A
Yeah,
no
it's
it's
sort
of
like
there
was
a
there's,
a
twitter
thread
about
somebody
who
was
running
an
ospo
office.
The
open
source
project
office
discovering
that
there
were
three
orgs
for
their
company.
They
didn't
even
know
about,
and
I've
been
doing
this
for
20
years
and
and
I'm
past
the
point
where
I'm
even
I'm,
not
even
it's
not
even
that.
I'm
not
shocked.
I'm
not
even
concerned
when
you
discover
that
things
like
this
are
happening.
E
Cool,
so
if
there's
nothing
else,
then
we
can
give
everybody
back.
Was
it
12
minutes.