►
From YouTube: Cartographer Community Meeting - Jan. 12th, 2022
Description
00:00 Intro and welcome new faces
01:20 The TL;DR
07:33 Questions around new Examples
11:45 Follow up from previous meeting
12:48 VMware's OSS Supply chain team intro and discussion (in-toto, SLSA levels, etc)
35:06 Documentation feedback request
Community meetings happen each Wednesday at 8:00 AM PT/11:00ET
See the agenda here (https://bit.ly/2Z67z08), add any topic you may want to discuss and join us live!
A
Okay,
hello,
everyone
welcome
to
the
cartographer
community
meeting.
This
is
our
first
session
for
2022,
so
we
are
glad
to
be
back
and
we
really
appreciate
that
you're
joining
us
live
or
watching
the
recording.
So
thank
you
for
being
here.
Let
me
share
my
screen
with
the
agenda.
This
is
not
the
agenda
there.
B
A
So
we
encourage
you
to
please
add
it's
optional,
it's
completely
optional,
to
add
your
name
and
organization
to
the
app
in
the
list,
so
we
can
catch
up
after
the
meeting.
A
A
C
Yeah
pretty
exciting
the
zero
one
zero
released
this
week,
there's
a
lot
of
stuff
that
went
into
this
release.
C
So
I
sent
a
link
to
the
release
notes
here,
but
just
a
couple
highlights
that
are
pretty
interesting
is
the
so
one
of
the
big
features
is
best
matching
on
pipeline
labels,
which
is
the
ability
to
be
able
to
specify
you
know
multiple
characteristics
for
a
supply
chain
and
then
having
a
workload,
be
able
to
match
based
on
like
a
best
match,
so
it
can
can
match
against
multiple
labels,
and
then
it
picks
the
one
that
is
most
accurate.
So
that's
pretty
exciting.
C
We
also
have
another
big
change
in
this
release
is
we're
using
informers
instead
of
short
polling.
This
was
a
sweeping
effort
across
the
whole
product,
so
hopefully,
things
end
up
being
a
little
more
snappy.
C
So
yeah,
you
can
check
out
the
the
pr
there
which
leads
to
the
issue,
which
has
a
bunch
more
information.
We
also
have
a
couple
breaking
changes
in
this
release
the
so
we
spent
a
bunch
of
time
reducing
the
controller
permissions,
and
so
that
is
a
breaking
change,
and
so
basically,
what
that
does
is
now.
You
specify
a
service
account
in
your
namespace
that
that
gets
associated
with
the
workload
and
as
the
as
the
supply
chain
is
operating
on
that
workload.
It
assumes
the
permissions
of
that
service
account.
C
C
The
other
big
breaking
change
in
this
release
is
a
new
param
hierarchy,
so
we've
updated
the
pram
hierarchy.
So
now
the
a
template
in
a
supply
chain
can
specify
param
that
param
can
be
overridden
by
the
supply
chain
itself
or
it
can
be
overridden
by
the
workload
that's
propagating
through
the
supply
chain,
and
we
have
some.
You
know
precedence
rules
associated
with
with
that
hierarchy
and
you
can
check
out
all
that
stuff
in
the
issue.
C
And
then
we've
got
some
cool
stuff
upcoming.
The
one
of
the
big
things
we're
working
on
right
now
is
garbage
collecting
the
resources
that
get
created
by
a
runnable.
C
So
right
now
the
runable
stamps
out
a
whole
bunch
of
immutable
objects
and
those
objects
can
accumulate
over
time
and
those
resources
can
tend
to
be
quite
expensive
to
keep
around,
especially
if
we're
stamping
out
things
like
tecton
task
runs
pipeline
runs
and
that
sort
of
thing
so
we're
introducing
gc
on
the
runnable
that
lets
a
developer,
specify
you
know
how
many
successful
and
how
many
failed
items
they
might
want
to
keep
around
so
that
they
can
keep
around.
C
You
know
the
latest
failed
test
run
and
maybe
a
couple
successful
ones
or
you
know
whatever
they
want.
So
hopefully
that
will
help
reduce
all
the
expensive
load
on
the
cluster.
C
We're
also
doing
some
performance
benchmarking,
just
you
know,
coming
up
with
some
recommendations
on
memory
and
cpu
usage
and
doing
some
bit
of
longevity
testing
do
some
load
testing
that
type
of
stuff.
C
And
then,
finally,
pretty
soon
we're
going
to
start
revisiting
rfc
14,
which
is
the
artifact
tracing,
which
is
a
very
in-demand
feature
right
now.
So
the
idea
is
basically
that
we're
going
to
be
writing
an
artifact
dependency
graph
to
the
status
of
the
workload
and
deliverable,
so
that
you
can.
You
know,
look
at
that
and
you
can
trace
back
all
the
different
artifacts
that
got
produced
along
the
way
with
that
with
that
workload
or
deliverable.
A
That's
great,
thank
you,
yoshim
yeah.
I
see
that
this
release.
I
mean
I
was
having
some
issues
around
the
examples
in
the
previous
release.
Once
I
upgraded
to
that
one
that
serious
release
issues
are
gone,
so
we
encourage
users
out
there
to
upgrade
and
use
our
most
recent
release.
So
that's
great.
I
don't
know
if
there's
any
additional
comment
regarding
all
the
new
stuff.
C
Oh,
there
is
actually
one
other
new
thing
that
I
forgot
to
put
in.
The
notes
here
is
that
we
expanded
our
examples
and
docs
a
whole
bunch
over
the
break,
so
com
like
complete
overhaul
of
both.
So
if
you
haven't
taken
a
look,
please
do
feedbacks,
obviously
very
welcome.
So
I.
D
Have
a
question:
actually,
I
saw
the
examples
and
they're
awesome.
So
thanks
to
the
team
for
all
the
hard
work
that
you're
doing,
I
had
been
working
on
like
a
a
supply
chain:
delivery
handoff
that
used
a
image
package
and
I'm
just
wondering
if
that's
like.
D
C
Yeah
for
sure
it's
not
something
that
we
have
in
our
examples
right
now,
but
it's
something
that
we
have
done
internally
before
and
so
it's
yeah
we
know
it
works.
Are
you
having
success
with
that
setup
or.
D
Yeah
yeah,
I
got
it
to
work
so
yeah
and
I
think
the
real
the
reason
that
I
kind
of
went
down
that
path
initially,
is
that
it
alleviated
me
from
having
to
do
the
get
set
up.
But
then
I
then
I
realized
the
get
set
up
was
actually
not
that
bad
with
the
ssh
stuff
but
like
while
I
was
struggling
with
it,
and
I
guess
I
was
interested
to
see
what
that
package.
Handoff
would
be
so
but
yeah
it's
working.
C
C
If
you're
already
building
images
you're
already
pushing
them
somewhere,
so
a
lot
of
the
times,
it's
easy
to
just
yeah,
bring
bring
those
credentials
and
set
up
your
repository
to
push
your
your
config
at
the
end
too.
Yes,
yeah.
D
C
D
I
will
say
I
don't
know
if
it
makes
any
difference
in
like
the
get
scenario
versus
the
package
scenario,
but
like
the
like,
there's
a
very
simple
setup
where
you
just
like,
basically
get
it
to
work
right.
You
just
you
publish
the
yaml.
D
However,
you
want
and
then
you'll
get
it
over
get
or
image
package
and
then
there's
like
probably
the
fuller
scenario
which
I
have
not
embarked
on,
which
is
to
actually
do
it
in
a
way
so
that
I
guess
you're
considering
the
customizations
that
people
might
want
to
do
on
the
yaml,
whether
it's,
I
guess
you
don't
have
to
add
overlays
right,
but
maybe
the
values
file
like
the
schema
for
the
values
file
like
do
you
want
to
include
that
if
you're
going
to
have
unresolved
values
in
your
yaml
and
things
like
that,
so
I
think
there's
like
a
maybe
a
more
sophisticated
use
case
but
yeah,
but
I
don't
know
if
that
would
be
any
different,
actually
between
git
and
image
package.
C
E
D
Cool
okay,
I
think
I
think,
by
the
end
of
the
week,
I'll
probably
be
at
a
place
where
I
can
actually
share
it.
I
did
have
a
I
had
a
question
on
like
oh
yeah,
so
as
a
I
have
a
question
kind
of
on,
like
on
best
practices,
recommendation
which
is
again
for
simplicity,
just
because
sometimes
it's
easier
to
take
the
short
route
when
you're
working
on
a
hello
world,
but
I
for
the
in
the
in
the
get
ops
scenario
where
you're
committing
your
delivery.
D
Your
deliverable
sort
of
the
ops
configuration
to
a
git
repo.
Do
you
envision
that
it's
better
to
have
one
ops,
repo
per
every
app
repo,
or
that
you
would
have
like
what
I
have
is
like
an
ops
repo
with
a
branch
per
app.
C
This
is
something
that
we're
currently
debating
internally
right
because,
obviously
like
there
are
different
setups
that
require
a
lot
more
configuration
and
some
that
can
be.
You
know
automated
a
bit
more
right,
so
we
don't
really
have
a
set
of
best
practices
right
now,
but
it's
it
is
something
that
we've
we're
currently
talking
about.
A
Okay,
that's
great!
Follow
up
from
previous
meetings.
We
have
a
couple
of
action
items.
One
of
them
is
by
rush
he's
still
out.
It
has
to
do
with
what
is
considered
the
public
api
and
another
one
was
part
of
a
discussion
on
how
to
start
thinking
on
guidelines,
what
to
include
in
docs
and
what
should
not
be
in
the
docs.
A
A
Okay,
there
you
go
now
we
have
the
open
mic
discussion
section
where
you
can
add
your
questions
or
topics
there.
So
first
thing
we
have
here
is
that
today
we
are
joined
by
volishka
and
joshua.
Look,
they
are
from
the
oss
supply
chain
team
that
I
believe,
is
a
kind
of
new
team
from
vmware,
and
we
wanted
to
to
discuss
here.
You
know
the
shutter
of
that
team
and
what
potential
collaboration
areas
could
be
between
cartographer
and
valentine
and
graphical
steam.
A
So
welcome
valentin
and
alicia
and
joshua
sorry.
F
Yeah,
thank
you
thank
you
for
having
us
here.
It's
our
pleasure
to
join
your
meetings.
Joshua
and
I
are
part
of
the
the
open
source
technology
center
of
the
open
source
program
office.
The
open
source
technology
center
is
the
engineering
on
of
the
open
source
program
office
of
vmware.
F
F
We
we
are
engaged
with
two
groups
of
projects
on
one
hand
we
are
contributing
to
security
frameworks,
tools
and
integrations
and
on
the
other
hand,
we
are
supporting
compliance
tooling,
with
focus
on
containers.
F
Joshua
is
our
supply
chain,
security,
expert
and
I'll
I'll.
Ask
him
to
share
more
about
the
projects
that
we
are
actually
engaged
to.
It.
B
Sure,
okay,
so
yeah.
The
folks
on
our
team
are
heavily
invested
in
the
update
framework,
which
is
a
kind
of
a
design
with
reference
implementations
for
how
to
do
secure
content,
delivery
and
update
ensuring
integrity
and
freshness
and
being
able
to
recover
from
compromise,
primarily
designed
for
kind
of
package
managers
and
similar
software-based
systems,
but
equally
applicable
to
all
kinds
of
content.
Delivery.
Secure
content,
delivery
over
a
network.
B
B
And
that's
an
open
source
project,
part
of
the
open,
ssf
open
source
security
foundation.
I
think
I've
completely
forgotten
what
the
acronyms
were,
and
so
salsa
is
a
relatively
new
project
launched
last
year
with
contributors
from
a
bunch
of
different
companies
coming
together
to
define
a
like
a
set
of
requirements
and
collaborate
on
tools
to
achieve
those
requirements.
B
It's
a
really
interesting
project
for
understanding
yeah,
the
kind
of
the
wider
supply
chain
security
problem
space.
We
also
have
folks
working
on
and
maintaining
a
tool
called
turtan,
which
is
a.
B
It
is
a
tool
for
understanding
the
inventory
and
license
compliance
footprint
of
container
images,
and
so
it
can
generate
a
software
build
materials
in
a
multitude
of
formats
for
a
container
image,
yeah
they're
the
big
efforts
I
think
we
have
going
on
we
kind
of
get
called
in
the
project's
kind
of
linking
a
lot
of
supply
chain.
Security
projects
are
all
kind
of
interlinked,
so
tuff
is
heavily
used
in
six
store,
so
we
have
some
influence
and
contributions
to
that.
B
You
get
that
community
as
well,
but
they're
the
big
three
that
we
spend
a
lot
of
our
time
on.
A
A
B
Yeah
yeah,
I'm
aware
of
the
project.
I
tend
to
work
at
a
level
or
two
below
kubernetes,
so
I'm
not
entirely
convinced
that
I
understand
like
enough
of
the
primitives
to
even
be
able
to
pass
the
cartographer
kind
of
introductory
docs.
I
started
looking
when
the
project
was
first
launched
and
started
to
stumble
on
some
of
the
kind
of.
B
Like
kubernetes,
I
guess
terminology
so
yeah,
I'm
familiar
with
the
project.
I've
spoken
briefly
with
wishima
about
it,
but
I'm
definitely
interested
in
learning
more
and
wouldn't
profess
to
understand.
A
Yeah,
it's
great
yeah,
I'm
not
sure.
If
the
program
showed
intro
to
the
project
could
fit
here,
because
at
least
myself
we
I'm
still
trying
to
be
able
to
articulate,
in
a
short
time
the
the
main
goals
of
the
cryptographer.
A
E
So
because
I
jump
in
and
to
I'll
try
to
give
an
elevator
pitch
for
cartographer
at
a
really
simple
level.
You
know
you've
got
your
you've
got
your
path
to
production
and
you
know
going
to
start
as
with
all
things
with
some
imperative
code.
That's
just
like.
Okay,
I've
got
to
do
all
these
things.
E
To
get
the
software
that
I
created
to
be
some
running
app,
that
my
users
can
use
and
as
I
iterate
on
that,
I'm
going
to
put
in
more
compliance
and
more
security,
and
you
know
as
you
as
you
do,
that
you
start
chunking
things
into
groups
of
like
okay.
Here,
I'm
focusing
on
like
building
an
image
and
like
here
I'm
focusing
on
testing
that
image,
and
here
I'm
focusing
on
scanning
that
image,
and
so
you,
as
you
start
to
encapsulate
each
of
those
steps.
E
What
would
be
really
useful
is
what,
if
you
didn't,
have
to
have
your
own
imperative
code
to
do
each
of
those
things.
What
if
there
was
some
program
that
you
could
just
call
out
to
and
say
here
are
a
couple
of
here's
like
a
little
bit
of
information
about
my
code
or
about
the
previous
steps
that
I've
already
taken
and
I'd
like
you
to
do
that,
step
that
I
used
to
have
imperative
code
doing
I'd.
E
So,
for
example,
kpac,
which
is
cloud
native,
build
packs
in
kubernetes
saying
I
don't
want
to
write
my
own
docker
files
and
like
write
all
this
bash
code.
I
just
want
to
say
here's
my
source
code.
Please
give
me
an
image
and
I'll
I'll
outsource
the
the
expertise
of
that
of
that
image.
E
Building
to
kpac,
and
so
cartographer
is
a
tool
that
allows
you
to
chain
together
different
controllers
that
have
their
own
areas
of
expertise
to
allow
users
to
exist
at
a
higher
level
of
abstraction,
on
that
when
they
think
about
that
path
to
production.
So
I'll
pause
there
and
ask
if
there
are
questions.
B
I
yeah
I,
I
have
a
line
of
thought.
I
guess,
are
you
familiar
with
the
in
toto
project.
E
I
think
different
members
of
the
team
to
varying
degrees.
I
I
know
that
it's
out
there.
I
know
that,
for
me,
I
think,
of
in
toto
as
at
a
attestation,
I'm
not
sure
if
that's
the
proper
way
to
think
about
it.
B
Yeah,
it's
certainly
it
certainly
is
that
sort
of
thing
one
of
the
the
similarity-
and
this
might
be
just
my
brain.
Making
connections
that
don't
exist
but
part
of
in
toto
is
intended
to
be
like
a
framework
for
end-to-end
integrity
of
your
software
supply
chain.
B
So
you
define
like
all
of
the
steps
in
your
supply
chain
in
a
layout
file
and
then
the
framework
tries
to
you
know
you
generate
attestations
for
each
of
those
steps
and
then
the
framework
and
evaluate
a
set
of
associations
against
the
layout
and
check
whether
the
the
expected
actions
occurred
and
were
performed
by
the
permitted
actors
and
those
kind
of
things.
So
I'm
hearing
similarities
between
an
in
total
layout
and
cartography
cartographer
kind
of
choreography
and
I'm
just
trying.
B
E
Yeah,
I
would
say
that
that's
one
of
the
the
pieces
that.
E
I
I
I
don't
think
that
we
yet
have
a
great
attestation
story,
and
so
that
is
you
know,
particularly
looking
over
the
the
page
that
we
just
saw
of
what
what
your
team
is
working
on
between
tough
and
in
toto.
I
think
that
is
a
place
that
we
definitely
need
to
get
to
right.
Like
that's
going
to
be
important
for
anybody
using
using
cartographer
anybody,
building
an
app
platform
on
top
of
cartographer
is
figuring
out.
What
does
attestation
look
like
and
in
total?
B
So
I
I
guess,
there's
some
linkage
to
the
rfc
14
that
was
touched
upon
earlier
in
the
meeting
which
I
clearly
haven't
read
because
first
I'm
hearing
about
it.
But
if
that
is
trying
to
track
the
inputs
into
the
the
choreographed
supply
chain
right,
that's
one
of
the
one
of
the
things
that
in
toto
attests
to
and
is
like
yeah
effectively
where
all
of
the
inputs
for
the
defined
unexpected
inputs.
B
Have
that
low-level
view
into
what's
happening
within
a
choreographed
supply
chain
such
that
they
could
do
like
the
in
total
terms,
artifact
low
integrity,
but
effectively
tracking
tracking,
all
of
the
inputs
and
at
which
steps
they
used?
And
things
like
that.
E
I
I
guess,
sort
of
two
things:
the
what
rc14
is
doing
is
reporting
artifacts,
that
came
out
of
each
or
reporting
the
artifacts
that
are
currently
exposed
by
resources
in
a
supply
chain,
so
in
in
that
path,
each
each
controller
at
a
given
time
is
going
to
have
a
status
and
it's
going
to
be
exposing
something.
So,
for
example,
kpac
is
saying:
here's
the
image
that
I
that
I
have
created
an
rfc
14
is
about.
E
That's
one
can
reason
about
from
there,
looking
at
the
shape
of
the
supply
chain
and
the
the
definition
of
the
supply
chain
and
those
values
what
it
what
has
been
fed
into
each
step.
So
I
guess
so
you
know
to
to
the
question
of
does
cartographer.
Have.
E
B
Moment
yeah
sounds
good,
there's,
possibly
some.
B
Some
opportunities
for
cartographer
to
produce
salsa
provenance,
which
is
a
specific
kind
of
attestation
to
discuss
to
effectively
document,
write
the
inputs,
outputs
and
steps
in
a
in
a
build
so
that
you
can
start
to
detect
temporary
in
your
software
supply
chain.
B
Which
would
be
super
cool,
I
think
yeah,
so
maybe
probably
not
here,
but
if,
if
you
know
wanted
to
follow
up
on
on
that
topic
specifically,
we
could
definitely
find
some
time
to
do
that.
E
And
am
I
correct
that
at
this
point
my
impression
is
at
this
point
that
I
we
would
just
sort
of
declare
like
we
are
like.
We
meet
the
criteria
of
salsa
they're
like
different
levels
of
salsa
compliance,
and
we
would
just
say,
like
we're
level
three
and
there
isn't
a
certifying
body
or
anything
that
we
would
go
to
to
do.
That
is
that.
B
It's
true
yeah,
there
isn't
a
certifying
body,
it's
been
discussed,
I
mean
salsa
is
a
new
project
and
it's
new
enough
that
we
have
a
fairly
good
idea
of
what
the
requirements
are,
particularly
because
this
is
heavily
derived
from
guru's
internal
binary
authentication
for
borg
system
that
they've
been
operating
for
quite
a
long
time
now,
but
there's
a
bunch
of
open
questions
around
things
like
how
one
actually
does
some
kind
of
policy
evaluation
of
generated
destinations,
how
you
do
kind
of
storage
and
discovery
of
attestations
and
things.
B
So
the
kind
of
the
the
what
to
do
is
well
understood,
but
how
to
make
that
usable
for
folks
ingesting
your
software
to
make
some
kind
of
decision
as
to
whether
the
produced
artifact
is
what
they're
expecting
before
they
take
it
into
their
own
software
supply
chain
is,
is
still
an
open
area
of
development
within
the
salsa
community,
which
is
a
very
long
way
of
saying.
Yes,
there's
no
accreditation,
it's
something!
B
That's
it's
been
talked
about
speculated
about,
but
doesn't
exist
yet
not
even
sure
how
we
would
go
about
doing
it,
whether
there's
any
kind
of
desire
or
demand
for
it.
Salsa
is
predicated
on,
like
some
trust,
being
anchored
in
the
source
control
platform
and
the
build
platform
that
you're
using
in
your
software
supply
chain.
B
So
if
you
already
trust,
for
example,
github
actions-
and
they
tell
you
that
they
are-
you
know
level
three
build
system-
I
imagine
most
github
users
would
just
kind
of
trust
that
so
the
value
of
some
kind
of
accreditation
is
not
certain.
I
think
at
this
stage.
E
Go
ahead,
I
mean
look
at
these
levels.
I
think
the
big
question
for
us
is
going
to
be.
What
is
israel,
I
think
they're,
where
necessary,
for
meeting
that
and
generate
prominence.
E
So
we
pointed
out,
like
rc14,
is
going
to
be
a
building
block
that
we
expect
to
be
a
step
in
the
in
the
road
to
to
that
providence
to
be
able
to
say,
hey
we,
you
know
we
picked
up
source
code
at
this
at
this
repo,
the
shaw
and
then
we
we've
fed
that
into
kpac,
and
then
k-pac
gave
us
this
image
that
that
lives
in
this
registry.
E
I
can,
I
can
say
that
to
a
person,
I'm
like.
Okay,
that's
the
providence,
but
I
you
know
in
terms
of
what
is
what's
the
expectation
for
tough.
How
would
you
encode
that
in
toto?
How
would
you?
How
would
you
represent
that
it
was
like
okay,
this
meets
also
level
one.
B
B
Yeah
so
similar
kind
of
train
of
thought,
all
questions
no
answers
at
this
point,
but
I
think
it's
an
interesting
question.
E
It
sounds
like
maybe
we
should
talk
some
more
and
do
some
demos
to
each
other.
Maybe.
A
Like
we
can
leverage
some
of
the
expertise
in
the
joshua
team,
so
we
encourage
you
to
keep
joining.
A
We
have,
for
example,
now
a
complete
architecture,
section
concepts
that
that
was
missing
in
previous
versions.
So
there's
been
a
lot
of
time
from
the
team
building
this
out.
It's
been
helpful,
for
example,
for
101
users.
Like
myself,
it's
been
really
useful
to
finally
start
understanding
how
how
all
the
elements
and
concepts
relate
to
each
other
and
what
we
would
like
to
have
from
you
out.
A
There
is
to
get
your
feedback
if
you
have
any
improvement
ideas
on
the
documentation,
you're
welcome
to
add
them
as
response
to
this
issue
that
is
linked
in
the
in
the
meeting
notes.
So
with
your
feedback,
we
will
be
able
to
keep
improving
and
improving
docs
each
time
right
so
yeah.
Well,
I
believe
that's
it
for
today
I
don't
know
if
well,
I
need
to
keep
working
on
this.
I
don't
know
if
there's
any
additional
comment
from
email
there.
A
Oh
okay,
thank
you.
So
much
for
your
time.
Thank
you
again.
Alicia
ken
joshua
I'll
fix
your
name
here
and
hope
to
see
you
next
week.