►
From YouTube: CNCF SIG Security 2021-01-20
Description
CNCF SIG Security 2021-01-20
A
A
Yeah,
like
weird
formatting
problems
that
take
forever
to
try
to
track
down
so
today
dealing
with
the
margins
and
the
table
stuff.
That
was
insane.
I
had
to
like
undo
a
bunch
of
things,
but
it
kind
of
makes
me
wonder
if
we
should
look
at
something
else.
I
mean
I'm
okay
with
google
docs,
but
I'd
also
like
to
encourage
people
to
contribute
content,
and
we
rate
things
in
markdown
for
our
repo,
so
hack
md
made
sense.
B
B
B
B
Okay,
it
looks
like
we
have
all
the
speakers
on.
That's
that's
a
good
start.
B
A
B
B
I'm
surprised,
I'm
surprised,
you
got
that
working
on
the
new
system,
I
feel
like.
Usually
when
you
saw
zoom
for
the
first
time
you
run
into
five
different
problems,
all
right,
I'm
gonna,
put
in
the
meeting
notes
in
the
chat,
if
you
could
just
sign
in
by
putting
in
your
names
and
if
you
have
any
updates
or
if
you're
new,
put
down
your
organization,
or
you
know
what
you
do
so
that
people
that
are
interested
in
the
topic
can
reach
out
if
they
want
to
have
a
chat.
F
B
Okay,
yeah
yeah:
let's,
let's
talk
a
little,
I
guess
yeah,
let's
see
what
we
can
do
for
that.
Maybe
andrews.
Could
you
open
an
issue.
B
We
also
need
asparagus.
If
you
don't
mind,
helping
out
don't
be
great.
B
B
Okay,
so
I
think
let's
get
started
with
kind
of
around
going
through.
Let's
see.
G
Sure,
just
a
very
very
brief
one,
so
we've
had
a
couple
of
additional
conversations
on
the
back
of
the
presentation
on
supply
chain
security
and
software
factory
last
week,
and
we've
agreed
with
the
chairs
to
start
off
that
working
group
and
the
first
meeting
of
that
is
tomorrow
at
4,
30
est
I'll,
be
putting
the
invite
thanks
for
emily,
for
sending
through
the
details,
for
that
so
I'll
be
putting
the
invite
into
the
github
and
the
chat
channel
as
well.
So
come
on
to
be
part
of
that.
B
John
all
right,
so
I
think
that's
all
the
updates
we
have
today,
so
I
think
we
should
just
go
ahead.
We
have
a
good
degree
presentation
today,
our
recall,
and
I
think
we
have
luke
ball
and
don.
I
believe
that
will
be
bringing
us
through
that
today.
So
I
think
let's
go
ahead
with
that.
E
Cool
okay,
we'll
do
a
quick
introduction,
that's
okay!
So
I'm
I'm
luke
hines!
I
work
at
red
hat
in
the
cto
office
and
I've
been
working
around
the
security
space
for
quite
a
while.
Last
time.
I
was
here
I
presented
keyline,
which
is
since
then
on
boarded
as
a
sandbox
project
and
I'll
go
over
to
bob.
E
I
E
D
You
could
get
away
from
yeah
okay,
so
here
we
go.
E
Zoom.Us
will
not
be
able
to
record
the
contents
through
your
screen
until
it
is
quit.
Okay,
dan,
are
you?
Okay
to
present,
I
had
to
quit
zoom
to
refresh
the
permissions.
I
Sorry,
I
think
it's
gonna
work.
Okay,
just
my
internet's
being
a
little
slow.
I
B
B
E
Right,
good,
okay!
So
yes,
so
this
is
project
recall.
As
said
earlier,
it's
myself,
dan
and
bob
that
have
been
working
on
this
we've
been
kind
of
under
the
radar
for
a
bit
and
sort
of
pathfinding
as
we
go
along
with
the
technology
and
and
we're
at
the
stage
now,
where
we're
entertaining
a
soft
launch
as
such
and
starting
to
share
this
with
subject
matter,
experts
to
get
feedback
on
what
their
impressions
are
possible,
collaborations
and
alignment
and
so
forth.
So
do
you
want
to
skip
to
the
next
slide?
E
Okay,
I
you
folks,
you're
all
you'll
have
expertise
here.
I
don't
need
to
explain
this,
but
you
we
all
know
that
software
supply
chains
have
their
their
weaknesses.
So
there's
various
attacks,
forwarded
attacks,
freeze,
replay
attacks,
so
forth
keys,
get
compromised,
sso
accounts
get
compromised
which
allow
people
to
then
piggyback
onto
systems
such
as
github
jiras,
so
forth,
malicious
hashes.
E
So
we
all
remember
the
linux
mint
attack,
where
somebody
swapped
out
an
iso
and
put
their
own
digest,
digest
their
own
md5
digest
onto
the
site
and
then
some
like
10
000
people
downloaded
it.
I
don't
need
to
give
you
folks,
a
scarce
story,
you're
all
experts
in
this
domain,
but
it's
it's
a
problem
that
we're
all
aware
of
and
recall,
is
developed
to
be
conducive
towards
trying
to
help
to
solve
this
problem.
E
Okay.
So
if
we
go
to
slide
three,
so
we
sort
of
agreed
amongst
ourselves
that
we
could
do
with
some
form
of
transparency:
okay,
not
an
arbiter,
on
whether
something
can
be
trusted
or
non-trusted,
but
a
a
form,
a
level
of
non-repudiation
around.
What
is
the
truth?
Okay,
and
particularly
for
cases
where
somebody's
private
key
signs,
artifacts.
Okay,
somebody,
perhaps
signs
a
release
of
some
sort
keys-
are
compromised.
E
Okay.
So
what
is
the
blast
radius?
Somebody
has
claims
to
have
signed
a
release
or
a
binary
and,
and
then
the
old
sort
of
targeted
attack.
Is
everybody
seen
the
same
as
me?
So
when
I
go
to
retrieve
what
I
believe
to
be
the
latest
version
of
a
piece
of
software,
am
I
seeing
the
latest
version
that
everybody
else
is
or
I'm
gonna
see
in
an
older
version,
somebody's
rendering
the
optics
so
that
I
see
an
older
version
that
you
know
has
some
nasty
cvs
in
the
within
that
particular
release.
E
I
Sure
yeah,
so
this
is
kind
of
a
zoom
in
on
the
one
point
luke
made
above
one
of
the
biggest
benefits
of
having
a
signature
transparency
here
in
a
transparency
log
is
the
ability
to
detect
key
compromise.
So,
if
you're,
using
something
like
pgp
to
sign,
release,
artifacts
one
of
the
biggest
problems
is
knowing
whether
or
not
your
private
key
has
ever
been
compromised
or
whether
it's
still
secure.
If
it's
been
compromised,
somebody
might
have
it
and
they
might
be
signing
things
on
your
behalf
and
distributing
them.
I
I
It
kind
of
relies
on
everyone,
trusting
and
verifying
each
other.
It's
similar
to
the
certificate
transparency
story.
If
you're
familiar
with
how
that
works.
But
every
time
you
sign
an
artifact
that
you're
going
to
distribute,
you
would
publish
that
signature
to
the
record
transparency
log
and
you
would
instruct
your
users
to
check
that
log
before
trusting
a
signature
from
you.
At
the
same
time,
you're
monitoring
the
entire
transparency
log
for
any
signatures,
added
to
it
with
your
public
key,
and
then
you
compare
that
with
an
internal
list
of
things
that
you
think
you've
signed.
I
If
anything
ever
shows
up
in
that
log
that
you
don't
remember,
signing
or
you
don't
think
you've
signed,
then
you
know
that
your
key
has
probably
been
compromised
and
it's
time
to
rotate
and
get
a
new
one
and
instructor
users
that
any
that
those
particular
signatures
aren't
to
be
trusted.
So
it
also
helps
you
control
the
blast
radius.
There
a
bit.
E
It's
back
to
you,
luke
is
this:
whose
slide
was
this
okay?
So
this
is
just
an
example
of
where
people
have
found
pgp
to
be
problematic.
One
of
the
projects
we
were
talking
to
recently.
You
can
see
they
had
an
issue
at
the
bottom,
where
they
had
an
issue
with
their
computer
needed
to
create
a
new
key,
and
this
particular
project
requires
that
you
import
about
20
public
keys
into
your
gpg
to
validate
the
sign-in
of
a
release,
and
these
are
all
people
that
have
all
left
the
project
you
know.
E
So
it's
it's
sort
of
it
just
goes
to
show
how
there
is
a
it's
less
than
an
ideal
situation
so
slide.
Six,
I
can
see
is
empty,
but
I
can
I
can
do
this
one
by
mouth
so
to
say
so.
I
was
meant
to
put
something
in
here.
So
anybody
that's
not
familiar
I'll,
go
for
it,
quick
because
I'm
pretty
sure
you
all
are
what
a
transparency
log
is.
Essentially
a
structure
called
a
merkle
tree.
E
Git
has
a
type
of
merkle
tree,
okay
and
also
bittorrent
so
build
torrent.
They
split
the
file
into
multiple
parts.
They
hash
those
parts,
those
go
out
and
then,
as
people
receive
those
file
parts,
they
can
validate
that
they're
tamper-free
by
computing,
the
the
merkle
tree.
So
that's
essentially
a
transparency
login,
and
this
is
what
recalls
built
on
top
of
is
a
transparency
login
and
we're
using
the
same
back
end
as
that
which
is
used
for
certificate
transparency,
which
is
run
by
cloudflare
google,
facebook,
various
people
so
slide.
E
Seven,
so
yeah
project
recall
we've
kind
of
touched
on
some
of
this,
but
just
to
reiterate
it's.
This
is
centered
on
software
supply
chain,
transparency,
services.
We
have
a
public
instance,
that's
available,
and
people
are
testing
against
and
we're
looking
to
have
this
as
kind
of
like
a
public
good
corporation.
That's
one
of
the
models
that
we're
receptive
to
so
think.
Let's
encrypt,
essentially,
we
have
server
code
and
client
code.
E
This
is
all
developed
in
golang,
along
with
our
back
end,
which
we
use
for
the
merkle
tree,
which
is
a
project
called
trillium,
and
you
can
have
a
public
instance,
but
you
could
also
stand
up
an
internal
instance,
so
somebody
wanted
their
own
internal
transparency
log.
Then
that's,
you
know,
that's
very
viable
you!
You
can
do
that
now,
once
instances
are
built,
they
can
be
completely
audited
by
what
we
call
a
monitor.
E
So
a
monitor
is
a
system
that
will
pop
entries
as
they
come
off
the
log
they
will
validate
the
integrity
of
the
merkle
tree
and
verify
that
it's
of
a
sort
of
a
tamper-free
state.
So
this
is
again
along
the
lines
of
this
is
nothing
new
that
we've
invented.
This
is
how
the
certificate
transparency
project
operates
as
well.
E
So
if
we
go
to
slide
eight
so
with
recall,
we're
not
trying
to
be
an
actor
as
such,
okay
in
in
the
way
of
say,
for
example,
tough
with
how
to
take
actions
against
the
key
compromise,
or
you
know,
or
notary
or
any
of
the
projects
around
this
sort
of
domain.
All
we
are
is
we're
looking
to
provide
a
the
the
immutable
back
end
for
storing
of
these
data
sets
okay,
and
to
be
able
to
do
that.
We
have
what
we
call
a
plugable
pki
interface.
E
So,
with
these
manifests
assigned
you
as
your,
we
can
have
custom
sign-in
interfaces,
so
one
that
we
use
typically
as
an
example
is
gpg,
but
we
also
have
x509
and
mini
sign,
which
I
believe
is
from
freebsd.
Is
that
right,
dan
bob.
I
Sort
of
yeah
bsd.
E
I
E
Understood
yeah,
but
essentially
it's
like
a
driver.
It's
a
plugable
interface,
okay
and
then
the
same
comes
for
the
actual
manifests
okay.
So
we
take
we're
talking
typically
json
here,
okay,
you
can
effectively
customize
and
have
your
own
value
sets
in
there.
So
we're
not
tied
into
any
particular
standard.
As
such
we've
got,
we've
got
the
agility
there
is
to
to
to
make
a
pull
request
with
your
own
framework
and
and
and
include
that
into
recall.
E
So
that
way
you
know,
like
I
say,
we're
not
fixed
to
any
particular
type.
The
the
flexibility
there
is
to
to
customize
it
accordingly.
So
if
we
go
to
slide
nine,
so
this
is
an
example
manifest.
We
call
this
the
the
recall
type.
Actually,
we
call
them
types.
I
should.
I
should
make
that
clear.
So,
as
you
can
see,
there's
an
api
version,
there's
a
spec,
so
we
have
a
format
where
we've
got
the
sort
of
a
sign-in
system
that
we
use
the
url.
E
In
this
instance,
it's
a
signature,
the
public
key
okay
and
then
we
have
sort
of
values
such
as
data.
So
here
you
can
see,
there's
a
release
and
there's
a
signing
of
that
release.
E
Now
there
there
is
a
client-side
cli
that
will
generate
this
manifest
for
you,
so
developers
could
quite
easily
just
pass
in
some
arguments
of
their
public
key,
the
signature
that
they've
just
generated
for
release
and
then
an
artifact
I.e
a
table
so
that
could
be
locally
on
their
machine
or
it
could
be
on
a
a
sort
of
an
external
facing
system.
Okay
and
then
what
keyline
will
do
is
it
will
receive
this
manifest?
It
will
validate
it
and
then
it
will
ensure
the
signing
is
correct
before
we
let
it
come
into
the
sort
of
log.
E
Okay,
we
we
don't
change
the
data
that
goes
into
to
the
log
as
such.
All
we
do
is
we
make
sure
that
it's
not
nonsense
that
somebody's
signing
us
it's
actually
signed
by
the
key,
the
key
that
is
it's
claimed
to
be
signed
by.
E
So,
as
I
say
here,
we've
got
this
sort
of
generic
example
that
we
have
that
we
use-
and
this
will
work
with
in
toto,
for
example,
and
but
we
also
can
utilize
xml
and
yaml.
So
we're
not
sort
of
locked
into
any
particular
manifesting
type
and
then,
if
we
go
to
slide
10,
so
you
see
this
kind
of
goes
back
to
the
merkle
tree,
which
I
described
earlier.
E
E
E
You
then,
have
your
auditors,
which
are
people
that
would
monitor
the
log
okay,
so
these
could
typically
be
package
managers,
security,
researchers,
somebody
like
a
showdown
dot,
io,
effectively,
antivirus
ventures
so
forth,
and
then
clients
would
be
software
users
or
consumers
of
software
modules
and
libraries.
So
they
could
then
use
recall
as
a
means
to
ensure
there's
another
sort
of
forwarded
attack
on
the
way.
E
Okay.
If
we
go
to
slide
13,
so
quite
often
we
got
asked
why
not
blockchain
okay,
we're
fans
of
blockchain,
but
what
we
found
is
that
most
public
use
or
uses
that
we
know
of
blockchain.
They
end
up
sticking
a
gateway
in
front
quite
a
lot
of
the
time
for
canal,
qualization,
validation,
speed,
authentication
and
so
forth,
and
transparency
logs
out
of
the
box.
They
work
for
what
we
want
them
to
do
and,
as
said
trillion,
is
kind
of
tried
and
tested,
it's
deployed
and
used
at
large
scale.
E
So
it's
used
for
certificate
transparency
for
go
some
and
you
know
it's
the
likes
of.
As
I
said
earlier,
google
run
a
transparency,
transparency
server
as
do
cloudflare
and
various
others
as
well.
E
So
if
we
go
to
slide
14,
so
we
are
effectively
cloud
native
recall
can
run
on
kubernetes,
we
have
an
operator
and
that
we've
actually
got
code,
that's
available
for
instantiating
on
on
kubernetes
as
well
the
various
yaml
files
that
are
needed
and
then,
if
we
go
to
project
status,
so
I
said
we're
currently
in
soft
launch.
So
we
have
a
public
instance
that's
available.
We
now
have
no
guarantees
around
it.
E
It's
it's
a
case
of
it's
a
sandbox
at
the
moment
that
people
can
play
with
and
then
we're
kind
of
we're
sort
of
kind
of
in
an
alpha
stage.
Still
so
you
know
there
might
be
bugs
that
require
us
to
drop
data
and
make
fixes
and
so
forth,
although
we're
confident
we
won't
need
to
do
that,
but
we
just
need
this
sort
of
bedding
in
period
effectively
and
we're
seeking
to
onboard
projects
to
start
adding
entries
to
recall
there
we're
doing
some
integration
with
fedora's
packaging
signing
infrastructure.
E
I
have
a
solution
called
cql
and
we're
at
the
moment
we're
seeking,
obviously
more
people
to
contribute
if
they
have
an
interest
in
this
space
feedback.
As
I
say,
we've
been
pathfinding
here
as
we
go
along
okay
and
there
is
in
fact
a
open
api
that
is
within
recall,
so
we
have
like
a
swagger
ui
where
you
can
go
in
and
see
how
the
the
apis
work-
and
you
know
somebody
wanted
to
develop
a
client.
It
would
be
very
easy
to
do
that.
E
So,
every
time
we
make
a
change
to
the
api,
it
automatically
renders
swagger
ui
and
an
open
api
spec.
So
we,
like
I
said
earlier,
we
have
a
cli
which
can
do
everything
that
you
need
to
do
with
the
transparency
log.
But
if
somebody
wanted
to
integrate
into,
for
example,
their
build
system,
a
call
to
recall
it
would
be
relatively
trivial
to
do
because
there's
a
rest
api,
that's
available
if
we
go
to
16
so
currently
we
have
obviously
red
hat
and
google
are
contributing,
and
some
of
you
all
know,
santiago
from
in
toto.
E
So
at
the
moment
we're
just
talking
to
who
we
see
as
experts
to
to
gain
feedback
and
and
impressions
and
possible
contributions.
You
might
have
a
very
valid
question
of
why
we're
talking
to
the
cncf.
So
we're
not
specifically
looking
we're
not
here
to
see
conclusion
into
the
cf.
It's
not
to
say,
we
haven't
out,
ruled
it
we're
just
sort
of
making
our
minds
up
as
we
discover
and
talk
to
people
what'll
be
the
best
approach,
because
this
is,
of
course
very
it
is
cloud
native.
E
You
know
it
can
run
within
that
infrastructure,
but
it
could
also
run
on
a
non-cloud
machine
and
and
be
dealing
with
manifests
that
are
generated
outside
of
a
cloud
context,
so
that
is
essentially
an
overview
just
some
other
things.
So
this
is
not
just
slidewear.
As
I
said,
we've
got
a
full
working
solution.
E
The
code
is
all
on
github,
it's
apache
2
licensed.
We
have
a
slack
channel
where
people
can
ask
questions
and
get
support.
We
have
kind
of
a
website
where
we're
starting
to
get
decent
documentation
up
there
and
the
swagger
ui.
You
can
see
that
it's
an
example.
This
you've
got
the
api
spec
somebody's
interested
where
you
can
try
it
out
and
we'll
have
be
having
documentation
in
there
and
kind
of
what
is
recall
and
we'll
also
be
providing
a
sort
of
a
directory
of
service
that
people
can
use.
E
So
you
know
there
could
be
multiple
recalls
in
much
the
same
way
as
there
are
multiple
gpg
key
servers,
so
I'll
conclude
that
but
I'll
defer
to
bob
and
dan.
Just
in
case
I
missed
anything
substantial
that
I
should
have
mentioned.
H
Yeah
sounds
good,
I
mean,
I
think
the
only
other
thing
I
would
mention
is
the
you
know
we
do
have
thoughts
around
creating
and
kind
of
going
back
to
the
key
compromise
use
case,
maybe
even
something
like
a
have.
I
been
pwned
website
that
you
could
ultimately
upload
your
public
key
to
and
get
an
email
or
a
web
hook
fired.
If,
if
there
is,
you
know
an
entry
added
to
the
log
that
would
that
used
your
public
and
private
key.
H
So
in
terms
of
trying
to
think
of
this
as
again
the
parallel
of
let's
encrypt,
you
know
this
is
a
common
service
for
good
and
figuring
out
how
how
does
this
ultimately
evolve
and
adapt
to
the
various
artifacts
that
we
could
generate
within
the
supply
chain
like
as
luke,
said,
or
we're
trying
to
feel
that
out
right
now
and
you
know
just
solicit
feedback
and
ideas
and
contributions.
E
Yeah,
that's
a
very
good
point
and
along
the
lines
of
that
have
I
been
pwned
use
case.
I
think
you
could
almost
sort
of
have
a
project
like
the
tough
that
could
benefit
from
this
as
well.
So
if
a
key
compromise
was
picked
up
within
the
transparency
log,
then
tough
could
enact
its
key
compromise,
resilience
and
revoke
and
so
forth.
E
I'm
sure
there's
lots
of
synergies
with
notary
and
we
also
know
keyline
could
benefit
from
the
having
a
source
of
signed,
digest
and
so
forth,
so
so
yeah.
I
think
what
we
could
do
is
open
up
two
questions.
If
anybody
has
any
so
yeah.
L
Okay,
so
this
is
vessel.
Thank
you
for
the
presentation
today,
just
a
couple
of
small
questions.
So
my
first
question
is:
is
your
project
kind
of
I
mean?
Is
it
a
direct
replica
of
ct
transparency
log?
You
are
trying
to
do
same
thing
for
code
signing
or
supply
chain
artifact
signing,
or
is
it
something
additional
as
well
in,
in
addition
to
transparency
log?
Does
it
also
provide
architecture
to
sign
and
verify,
or
is
it
just
transparency
thing
that
you
handle?
L
L
E
E
So
somebody
if
somebody
wanted
to
use
this
within
their
own
private
organization,
they
could-
and
you
know,
if
somebody
has
information
that
they're
willing
to
share,
there's
nothing
to
say
they
can't
put
it
into
a
public
instance
as
well.
If
it's,
if
it
sort
of
meets
that
security
context,
and
you
know
and
and
there's
no
issues
around
trust
boundaries
and
then
the
information
being
public,
we
could
certainly
be
receptive
to
that
and
the
first
question
yeah.
I
I
would
just
just
clarify
that
point:
a
little
bit
like
the
log
itself
is
public
and
all
data,
and
it
is
public.
There's
no
reason
you
can't
store
signatures
for
closed
source
artifacts
and
as
long
as
the
artifact
and
the
signature
are
publicly
distributed.
That's
fine
yeah.
It
wouldn't
make
sense,
like
you
think,
for
you
know
an
artifact
you
build
and
run
internally
that
never
gets
distributed
publicly.
It
wouldn't
make
sense
to
stick
that
metadata
in
here,
but
you
know
even
closed
source
executables.
You
download
still
need
signatures,
and
so
that's
fine.
E
Yeah
good
example
yeah,
for
example,
blobs
and
so
forth,
and
the
the
first
question,
so
this
was
to
do
with
the
differences
between
significant
transparency.
So
I
said
we
share
the
same
back
end,
but
we're
totally
separate.
We
wouldn't
be
running
on
certificate
transparency
logs
we
so
with
trillium.
It
has
a
concept
of
a
personality
which
is
the
kind
of
the
application
that
sits
in
front
of
trillium,
okay
and
recalls
completely
separate
code
base
from
project
to
certificate
transparency.
E
E
So,
let's
see
what
other
questions
so
address,
yeah,
that's
the
right,
url
api.recall.dev.
E
E
B
So
I
guess
I
have
a
question
kind
of
for
the
team.
I
I
know
that
because
interfacing
with
a
lot
of
cloud
native
technologies,
like
you
know,
in
total,
tough
notary,
is
that
not.
E
B
So
so
I
guess
yeah
my
my
question
is
around
that
I
think
justin
isn't
on
today,
but
is
there
any
communities
that
you
would
like
to
if
you're
already
not
in
touch
with
to
get
in
touch
with
them,
and
we
can
help
with
that.
E
Nobody
specifically
comes
to
mind
unless
bob
done,
I
think
tough
and
notary
are
very
interested
and
spyro.
Of
course,
as
mentioned
earlier,
I
think
there's
a
lot
of
some
really
good
synergies
there
as
well.
I
Yeah,
I
can't
think
of
anyone
we're
paying
attention
to
the
notary
v2
work.
I
guess.
I
A
lot
of
cloud
native
projects
aren't
really
signing
release
artifacts
today,
because
it's
not
super
easy
or
possible
to
do
that
with
container
images
and
oci
artifacts.
So
as
that
work
progresses,
I
assume
more
cncf
projects
will
start
signing
release
artifacts
as
that
gets
easier.
So
at
that
point,
we'll
want
to
interact
more
directly
with
people.
H
Yeah-
and
there
is
kind
of
the
chicken
and
the
egg
problem
here
as
well
as
if
we
don't
get
communities
to
to
make
entries
into
the
log,
then
we
don't
ever
get
the
momentum
of
gravity
and
changing
the
broader
practices
in
communities
around
the
software
supply
chain.
So
I
think,
there's
kind
of
a
set
of
integrations
that
we
could
do
with
other
projects
versus
just
users
of
the
log.
So
I
think
we'd
be
seeking
both
type
of
interactions
here,
as
we
go
forward
very
much,
which.
E
Is
kind
of
why
we're
conducive
to
the
let's
encrypt
model,
because
their
their
optics
are
it's
very
much
a
public
good
service?
If
you
see
what
I
mean,
it's
not
sort
of
a
case
of
give
your
data
to
red
hat
and
google,
it's
it's
seen
as
being
something
that's
wholesome
and
for
the
benefit
of
everybody,
and
that's
that's
the
kind
of
that's
how
we
see
recall,
perhaps
standing
a
better
chance
of
adoption
within
the
public
space.
Obviously
internally,
there
are
no
considerations
there
as
such
around
adoption.
B
Yeah,
I
see
santiago
posting
something
about
the
software
supply
chain
security
working
group
so.
B
Yeah
yeah.
M
I
can
you
guys
hear
me
yeah.
E
M
Yeah,
I
just
wanted
to
add
that
I
think
that's
also
a
perfect
place
to
tie
in
the
work
that's
starting
to
come
on
the
software
supply
chain,
security,
working
group
and
projects
like
recore
that
need
to
need
a
framing
around
the
threat
modeling
and
the
usage
scenarios.
M
The
challenges
of
adoption
that
luke
was
talking
about
really
remind
me
of
the
challenges
that
toto
has,
which
is
pretty
much
the
supply
chain.
Is
this
way
because
it's
as
its
weakest
link-
and
I
know
it's
a
very
cliche
phrase
but
like
the
broader
you
cover
an
area,
the
more
secure
things
are
and
that
I
think
it's
a
like
the
important
push
that
I
foresee
in
day
2021
that
it's
getting
the
most
of
open
source
projects
participating.
M
So
we
can
start
answering
questions
about
the
cross-organizational
ownership,
about
publication
of
the
trusted
artifacts
for
political
bills,
so
on
and
so
forth.
K
Can
I
make
a
suggestion
I
mean
I
don't
know
if
again,
it's
helped
us
to
a
certain
degree
is
do
some
presentations
in
in
some
of
these
projects.
Community
meetings
like
aspire
tufts,
you
know
notary
to
kind
of
understand
like
what
you
all
do.
It's
it's
amazing
after
seeing
this,
but
I
kind
of
have
to
do
like
an
internal
kind
of
sell.
K
E
E
A
really
good
point,
yeah,
definitely
yeah,
and
we
would
also
sort
of
like
to
help
projects
actually
sign
releases
because
there's
so
many
that
aren't
at
the
moment
I
mean
if
we
take
kubernetes.
For
example,
none
of
the
releases
are
signed,
github
sort
of
signs
the
commits,
but
then
github's
keys
are
not
accessible.
E
So
all
you
can
really
do
is
rely
on
upon
a
sort
of
a
javascript
component
with
a
green
tick
to
show
that
something's
trusted,
but
you
can't
actually
validate
the
trust
yourself.
So
we'd
also
like
to
you
know,
look
at
ways
that
we
could
explore,
making
it
easier
for
software
maintainers
to
sign
their
releases,
because
so
many
don't
at
the
moment.
So.
K
Cube
has
an
infrared
team
as
well
as,
like
you
know,
the
the
team.
That's
working
through
like
the
releases
right,
I
mean
that's
a
perfect
scenario
where,
on
a
community
call
of
some
sort,
it's
jumping
on
and
saying
hey.
This
is
kind
of
what
we
do.
You
know
it
take
you
know.
Sometimes
you
got
to
give
to
get
right
so.
G
E
K
You
go
to
the
you
know,
I
think
the
kubernetes
contributors
or
or
it
kind
of
shows
all
the
various
zigs
that
are
there.
G
It's
great
to
see
these
sort
of
integrations
as
well
right,
because
what
I'm
hoping
we
can
also
cover
in
that
the
the
supply
chain
working
group
is
that
sort
of
broader
architecture
of
how
this
is
all
going
to
fit
together?
How
would
the
architecture
look
like
if
we
have
in
total
in
there
appropriately
set
up
within
toto
and
aspire,
perhaps
and
and
recall?
G
I
think
that
would
be
really
beneficial
to
see
that
the
breadth
of
what
needs
to
happen
to
to
provide
security
when
the
supply
chain
and
provide
those
best
practices
to
people
into
santiago's
point.
I've
started
to
show
that
to
some
of
the
open
source
projects
to
say
look.
This
is
a
best
practice
approach
to
building
and
securing
that
software.
Here's
a
sample
architecture!
You
can
use
and
press
a
button
and
add
it
to
your
project
right
and
then
you
start
to
see
that
community
with
something
that
you
use
in
leverage
yeah.
That's.
G
We
only
recently
started
discussing
it
last
last
week,
but
we're
holding
the
first
meeting
of
that
on
the
22nd,
which
is
friday
not
tomorrow,
great.
E
So
I
would
just
just
a
quick
point:
if
you
like
right
away,
you
think
you
could
get
us
onto
a
meeting
where
yeah,
where
you're
able
to
lodge
an
entry
on
an
agenda,
go
for
it.
Just
let
us
know
and
we'll
turn
up
and
present
it'll
be
a
privilege.
G
B
Awesome,
do
you
have
any
any
more
questions?
Any
other
comments.
F
E
We
haven't
really
made
a
decision
as
yet
we
we
just
sort
of
socialize
in
the
technology
and
we're
aware
that
we
will
likely
fall
into
some
sort
of
foundational
consortium,
but
we're
sort
of
open-minded
there.
We
intend
to
talk
to
people
and-
and
what
reveals
itself
to
be
the
best
fit,
would
be
the
best
fit
effectively.
E
Yeah
sure
yeah
yeah,
that's
a
good
point
for
us.
The
main
thing
is
like
to
to
echo
back
to
what
we
were
discussing
earlier,
which
is
the
optics
really
that's
what
we
have
to
get
right
because,
as
bob
said,
it
is
for
us
we're
only
as
useful
as
the
data
sets
that
we
have
so
we
need
open
source
projects
to
to
submit
manifest
to
us.
I
Yeah
to
build
on
that
one,
like
the
the
code
is
one
thing:
it's
an
open
source
project,
but
the
real
benefit
here
is
kind
of
the
operational
service
and
then
cncf
operates
a
couple
things
like
that
kind
of
like
the
the
cncf
hub
and
a
few
others,
but
making
sure
that
we
get
that
service
set
up
in
a
sustainable
way
that
can
be
operated.
Reliably
is
the
most
important
part.
E
Very
much
yeah,
so
that's
why
we've
looked
to
build
an
operator
so
that
it's
sort
of
you
know
it.
Could
we
can
sort
of
open
source
the
operation
of
any
core
as
well
effectively
that's
the
sort
of
model
that
we
would
like
to
have
so
that
somebody
can
somebody
needs
to
deploy
recall
you
know
they
can
do
so
in
a
manner.
That's
cloud
native.
F
E
Yes,
very
much
yeah,
that's
that's!
Where
we'll
have
that's,
where
we'll
hold
a
lot
of
value
for
the
overall
open
source
ecosystem.
With
all
of
these,
you
know,
as
we
know,
there's
so
many
projects
that
that
just
have
a
very
small
amount
of
maintainers
on
there.
E
You
know
they're,
perhaps
not
financed
by
a
company-
and
you
know,
they've
got
they've
got
their
own
private
keys,
they're,
signing
things
they're,
making
releases
and
and
these
small
projects
can
be
pulled
into
huge
projects
in
their
dependency
matrix,
and
so
it's
just
sort
of
looking
at
how
we
can
have
some
transparency
there
around.
L
So
one
thing
this
is
jj
that
he
led
to
andrea's
comment.
L
One
thing:
that's
historically
helped
projects
like
this
to
become
a
little
bit
more
successful
is
establish
a
project
plan
for
your,
how
we
are
thinking
about
working
with
cncf
in
a
open,
transparent
way
and
then
track
towards
it.
So
it
helps
people
to
identify
collaborate
and
interface
and
contribute,
and
you
may
stick
to
plan
you
may
not
stick
to
plan
but
being
able
to
actually
establish
that
and
put
it
out
and
open
will
help
you
get
a
little
more.
F
Loca
and
what
you
said
last
really
to
underline
there
that'd
be
great
benefit
to
the
ecosystem.
You'd
be
boosting
a
lot
of
products,
there's
even
mid-sized
projects
of
corporately
employed
people
that
don't
do
signed
releases
because
they
it's
an
operational
burden
right
and
they
have
many
maintainers
of
different
companies.
E
Yes
very
much
yeah
and
I
think
there
is
a
an
angle
to
this,
where
people
are
nervous
to
sign
things
and
to
provide
digest,
because
it
almost
steps
them
up
as
being
accountable
if
something
goes
wrong,
whereas
if
they
don't
involve
themselves
that
they're
not
putting
their
reputation
at
stakes,
which
is
kind
of
doesn't
make
sense
when
you
put
it
apart,
but
I
think
that's
the
sort
of
psychology.
That's
that's
playing
out
the.
K
There,
if
I
think
the
like,
you,
said
the
mental
aspect
of
it,
there
is,
is
kind
of
making
sure
that
people
understand
that
your
tool
is
not
going
to
add
a
ton
of
extra
overhead.
It's
going
to
do
a
certain
thing
that
they
can't
do
that.
You
know
you
don't
want
a
team
to
have
to
build
their
own
kind
of
signing
capability
right.
So
it
seems
like
you're
building
a
framework
right.
E
E
I
mean
we
don't
really
want
to
sort
of
recreate
gpg,
so
we
need
to
sort
of
weigh
up
what
will
be
the
best
approach
there,
but
we
definitely
want
to
make
it
easier
for
people
to
do
this,
and
one
thing
that
will
really
help
them
is
knowing
that
anything
that
they
do
produce
will
be
widely
available
and
others
can.
Others
can
watch
that
particular
space
and
audit
that
space.
B
Would
this
make
make
sense
to
kind
of,
for
example,
if
you
could
have
it
as
part
of
like
the
ci
badging,
because
they
already
have
signing
kind
of
like
silver?
I
think
the
silver
ci
badge
is
like
signing
requirements,
so
maybe
you
know
a
gold
requirement
could
be.
You
would
upload
your
assigned
manifest
to
a
transparency
server
as
well.
E
E
E
A
very
good
point
and
the
the
project's
in
the
open
ssf
now
so
I
think
we
could
talk
to
the
working
group,
though,
because
we
plan
to
talk
to
them
at
some
point
as.
E
E
Awesome
so
I
guess
to
to
round
it
up
recall.dev,
that's
all
you
have
to
remember
on
there.
You
can
find
the
github
organization.
There
is
a
slack
channel.
I
don't
know
if
I've
got
a
slack
invite
on
there.
If
not
somebody
you'll
find
me
in
the
cncf
channel,
I'm
usually
hanging
around
the
keylime
channel
and
yeah.
It's
you
know.
If
you
want
to
stand
something
up,
it's
worth
touching
base
with
us,
because
things
are
moving
fast
at
the
moment,
so
docks
are
catching
up.
C
Certainly
interested
in
that
slack
channel,
if
get
a
link
to
that,
maybe.
B
Could
you
put
the
put
the
slides
as
well
as
the
section.
G
B
Issue,
at
least
we
have
a
preserved
subway
that
is
accessible.
E
We'll
do
I
I'll
I'll
just
quickly
grab
the
invite,
but
I'll
put
it
into
the
I'll
drop
it
into
the
chat.
Great.
Thank
you.
Bob.
E
Yeah,
it's
I
don't
know
much
about
bikes.
I
should
get
on
it
more.
I
tend
to
run
more,
it's
lapierre.
That
means
anything,
but
it
is
it's.
Carbon.
E
M
Yes,
I
am,
did
I
not
confirm.
F
I
don't
know
I
haven't
seen
the
invite
I'm
just.
I
was
wondering
if
you're
gonna
be
there.
M
I'm
sorry
it's
it's
super
hectic.
I
had
a
family
member
in
the
hospital
and
then
I'm
starting
teaching
this
some
this
week.
So
it's
been
like
super
crazy,
but
yeah
I'll,
see
you
on
friday,
cool
your
place
looks
different
from
the
last
time
we
spoke.
This
is
my
office
in
the
university.