►
From YouTube: SSCS Working Group Meeting - March 20, 2023
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
This
is
going
to
be
our
kickoff
to
our
software
supply
chain
security
working
group
here
at
gitlab.
So
thank
you.
Everyone
who
is
able
to
join
I
have
just
a
few
items
in
the
agenda
that
I
wanted
to
go
over
today.
So
first
of
all,
I
assume
you've
probably
already
read
what
was
presented
in
the
merge
request,
if
you're
here,
but
just
to
give
a
high
level
overview
really.
A
Our
goal
for
this
working
group
is
to
enable
signing,
ideally
by
default
within
gitlab,
and
that
includes
everything
from
build
artifacts
to
container
images
to
packages.
It
definitely
is
a
pretty
lofty
goal,
so
we're
going
to
do
our
best
to
see
how
we
can
get
there
over
time.
But
ideally
we
want
to
not
only
do
the
signing,
but
we
want
to
also
be
able
to
display
in
the
gitlab
UI
and
show
whether
or
not
those
items
are
verified
or
unverified.
A
So,
whether
or
not
they're
signed
or
not
so
that
we
have
that
full
transparency
to
users
I
wanted
to
walk
through
a
couple
of
the
items
that
we're
going
to
be
starting
on
as
part
of
this,
the
first
one
is
this
user
experience
for
signed,
container
registry
images,
and
let
me
share
my
screen
and
I
can
walk
through
the
basics
of
this.
A
So
just
to
give
some
context.
This
is
actually
a
demo
that
Brian
put
together
over
a
year
ago.
I
think
at
this
point,
but
right
now,
when
users
sign
images
and
they
push
them
up
to
our
gitlab
container
registry.
We
don't
do
a
great
job
of
showing
that
in
the
UI,
so
we
have
like
here,
for
example,
our
latest
tagged
image
and
then
here's
the
signature
for
that
and
you'll
notice
in
this
UI.
A
There
are
a
few
problems
one
we
showed
this
was
published
22
years
ago,
which
isn't
great,
but
then
also
there's
no
way
to
associate
this
with
the
latest
image.
In
fact,
if
I
click
into
this
and
I
view
the
details
here,
it's
not
particularly
useful.
It
does
not
give
me
any
real
details
about
what
the
actual
signature
is,
and
so,
if
I
want
to
actually
verify
this
signature,
I
would
have
to
pull
the
signature
down
on
my
machine
and
inspect
the
file
manually,
correlate
it
with
the
latest
Academy
image.
A
So
what
we'd
like
to
do
is
instead
of
showing
two
separate
line,
items
we'd
like
to
just
show
one
and
depending
on
whether
or
not
it's
verified
or
not.
If
it
is
signed
and
fully
verified,
we'll
show
this
badge
associated
with
it
and
we'll
also
add
a
line
item
here
for
the
signature,
so
they
can
click
in
and
view
the
details
of
the
signature
itself
same
thing
here.
A
If
it's
signed
by
unverified
or
signed
and
invalid,
and
if
there's
no
signature
at
all,
then
we
just
won't
show
a
badge
and
then,
if
they
do
click
into
view
details.
This
is
a
ux
mock.
Ignore
the
content
in
here.
This
is
not
really
accurate,
but
you
know
just
like
when
you
go
to
view
the
details
of
the
signature
anywhere
else
like
if
I
come
in
here
in
Chrome
I
can
see
the
certificate
is
valid
and
then
I
can
share
details
about
the
certificate.
You
know
any
information
that
we
can
show
here.
A
We
would
show
in
that
details
pane,
but
this
text
is
really
just
kind
of
a
placeholder
at
the
moment
and
not
currently
in
scope
for
this
epic,
but
also
and
nice,
to
have
in
the
future
would
be
able
to
would
be
the
ability
to
filter
or
sort
by
images
that
are
signed
or
not.
I.
Don't
think
we
have
to
add
that
right
away,
but
that
would
be
a
nice
follow-on.
A
So
although
this
one
looks
really
simple,
my
understanding
is
the
back
end.
Architecture
of
the
way
our
container
registry
works
is
not
really
suited
to
this.
At
the
moment,
we'll
have
to
make
some
pretty
significant
changes.
Some
database
changes
because
right
now
there's
nothing
associating
these
two
objects
together
in
any
way
in
our
database.
So
we
would
have
to
add
that
in
I,
I'm,
probably
misrepresenting
the
details
that
have
to
be
happened
here,
but
my
understanding
is,
there's
actually
a
significant
amount
of
work
that
we
need
to
do
just
architecture-wise.
B
I
would
have
to
do
some
research
and
understand
a
bit
more
about
the
container
registry
architecture
to
be
able
to
estimate
the
level
of
effort.
But
my
first
star
is
that
it
shouldn't
be
too
difficult.
But
there's
a
like
famous
last
word,
I'm
guessing
I'm,
guessing
that
maybe
the
images
are
not
stored
in
the
DB
they're,
probably
more
like
an
S3
bucket
style,
so
they're,
probably
just
blobs,
and
if
that's
the
case,
then
it
could
be
challenging.
A
Yeah,
so
we
do
have
somebody
who
signed
up
for
the
working
group
as
an
advisor,
who
is
on
that
container
registry
team
and
so
they're.
We
are
able
to
work
with
them
too,
get
the
details
on
exactly
like
what
would
need
to
be
changed
there
as
well
too,
but
yeah
I'm
hopeful,
it's
not
too
hard,
but
the
back
end
team
for
the
container
registry
group
seems
to
think
that
there's
some
significant
changes
needed,
but
they
have
the
details
on
what
that
would
be
for
sure.
B
I,
don't
I,
don't
remember
how
cosine
does
its
signature
format,
but
we
should
be
able
to
verify
that
those
images
were
signed
from
a
pipeline.
That's
like
in
a
specific
group
or
a
specific.
C
A
Yeah,
that
would
be
great
if
we
could
do
that
level
of
verification
for
this
I
guess
my
base
assumption
for
the
verification
was
that
I
think
in
gitlab,
somewhere
I
need
to
look
up
our
documentation,
but
I
think
we
already
have
a
method
where
we
can
provide
a
list
of
root
Cas
that
we
trust
so
I
think
we
could
just
check
and
see
if
the
signature
was
signed
by
one
of
those
root
Cas
or
buy
a
certificate
generated
by
one
of
those
routers.
A
If
there's
a
way
to
be
even
more
granular
and
say
this
signature
came
from
this
exact
project,
I
think
that
would
be
that
might
influence
our
our
user
experience.
That
would
be
an
additional
data
point
that
we
could
surface
up.
That
might
be
really
interesting.
Yeah.
B
I,
don't
I
know
once
you
rely
on
trusted
Cas,
because
the
GitHub
trust
store
is
like
at
the
instance
level,
and
so,
if
you
add
a
trusted
CA,
it's
added
to
the
entire
instance,
and
so
there's
no
way
right
now
to
make
that
work
for
github.com,
because.
D
E
B
B
If
it
uses
first
year,
then
that
certificate
that
it
creates,
is
completely
temporary
and
be
with.
We
would
have
to
look
and
record
to
see
what
certificate
was
used
to
sign
that
signature
and
if
it
was
valid
at
the
time
the
signature
was
created.
So.
A
B
Presumably,
if
you
want
to
add
like
trusted,
if
you
want
users
to
be
able
to
specify
what
they
trust
like
a
private
key
or
a
root,
VA
I
think
they
should
be
able
to
add
that
into
the
project
settings
rather
than
using,
like
a
global
trust
store
because
I
think
I
think
that's
really
bad,
because
it's
also
used
for
for
other
stuff
in
gitlab,
like
for
external
TLS
connection
and
stuff,
like
that,
so
it's
already
used
for
different
things
and
I.
B
Think
if
we
reuse
that
same
trust
store
for
other
stuff,
it's
going
to
introduce
vulnerabilities
that
cross
protocol
attacks,
so
I
don't
think
we
should
use
that
I
think
we
should
have
something
completely
separate.
A
Okay,
yeah,
that
makes
sense
to
me:
okay,
yeah
I'm,
in
agreement
with
that
I
mean
the
the
real
thing
that
we
want
to
be
able
to
verify
is
when
users
are
signing
images
as
part
of
building
the
image
in
our
runner
and
most
especially,
you
know,
we
want
to
support
this
out
of
the
box
configuration
so
if
they
do
useful,
full
Co
to
sign
something
in
our
runner,
we
would
want
that
to
show
up
as
verified.
A
A
Yeah,
that
makes
sense
to
me,
but
do
we
still
need
some
way
you're
saying
we
still
need
some
way,
then
at
the
group
level,
for
users
to
identify
trusted
root
Cas,
because
we
would
be
checking
director
and
full
Co
to
get
the
cert
and
to
identify
the
time
that
it
was
signed.
But
would
we
still
need
to
validate
that
against
a
trusted
group
CA.
B
I
think
so,
I
think.
If
we,
if
we
start
with
focio,
then
we
shouldn't
need
to
do
anything
else.
We
should
be
able
to
verified
infocios
or
RDC
claims,
which
is
it
could
be.
It
could
be
any
anything.
That's
in
the.
B
B
Yeah,
so
this
is
this
is
a
draft
MRI
that
they
have
on
the
fossil
project
to
support
the
gitlab
JWT,
and
so
we
could.
We
could
verify
based
off
of
basically
anything
that's
in
here.
B
A
A
A
F
I
did
have
a
question
on
what
I
could
start
on
so
I.
Think
initially
after
that,
I
need
to
familiarize
myself
with
the
container
registry
how
to
use
it
and
whatnot,
but
I
was
wondering
once
I've
taken
care
of
that.
Is
there
like
anything,
I
could
get
started
on
right
away,
or
do
we
wait
for
back
end.
A
I
would
think
that
you
could
start
developing
some
of
this
just
behind
a
feature
flag,
maybe
even
with
mocked
data,
but
I
mean
my
understanding
was
you
are
going
to
need
an
extra
few
weeks
anyway,
before
you
started,
and
that
might
work
out
better
to
give
the
back
end
a
little
bit
of
a
chance
to
get
started
ahead
of
you.
But
if
you
wanted
to
get
started
right
away,
I
think
you
could
look
at
those
mocks
there
and
start
developing
the
front
end
out
ahead
of
the
back
end.
Just
behind
our
feature,
flag.
F
Okay,
cool
yeah
I'll
have
to
talk
with
Neil
about
the
scheduling,
but
just
wanted
to
get
an
idea
of
what
I
could
start
on
and
also
the
do.
We
have
a
timeline
for
when
we
would
like
this
feature
to
be
out
by.
A
So
we
don't
have
a
good
timeline
yet
because
we
still
need
to
do
refinement
and
break
down
the
Epic
and
figure
out
our
implementation
plan.
So
I
don't
know
right
now.
My
guess
is
as
good
as
yours
as
to
how
long
it's
going
to
take,
but
I
think
we'll
have
a
better
idea
soon.
Our
first
task
here
is
going
to
be
just
to
refine
it
and
to
break
everything
down
into
implementation
issues.
F
B
A
B
I'm
not
sure
so
we're
in
in
my
groups.
Typically,
we
would
have
you'd,
have
the
dri
do
the
requirement
and
create
the
implementation
issues
you
know
one
thing
I
could
do
is
I
could
create
the
implementation
issues
and
then
I
could
ask
you
to
review
them
and
see
if
the
implementation
plan
makes
sense
like
that,
would
you
like
to
do
that.
E
Yeah
I
think
that
sounds
good,
so
I
guess
to
start
off.
I'll
just
get
some
more
context
into
the
Container
registry
and
try
to
see
how
things
are
implemented
and
then
I
guess
we
can
go
from
there
and
collaborate
on
the
implementation
plants.
B
A
Yeah
and
please
feel,
do
feel
free
to
reach
out
to
the
existing
container
registry
team,
especially
where
they've
made
someone
available
as
an
advisor
for
us
I'm,
hoping
that
will
help
reduce
the
learning
curve.
They
seem
to
think
that
there
was
a
lot
to
learn
and
that
it
was
a
pretty
strong
learning
curve.
So
we
want
to
avoid
spending
like
three
months
just
coming
up
to
speed
on
their
back
end
by
you
know,
using
the
advisor
that
they've
made
available
to
us.
D
E
Maybe,
to
start
off
with,
we
could
organize
a
call
with
one
of
the
team
members
in
the
container
registry
and
they
could
give
us
like
a
high
level
walk
through
and
whoever
is
on.
The
call
can
see
that
we
could
record
that
for
people
who
can't
make
the
call
I
feel,
like
that's
a
good
jumping
off
point.
B
A
So
yeah
that
sounds
good
Brian.
Do
you?
Are
you
planning
on
talking
with
individuals?
Are
you
planning
on
having
everyone
work
on
this
first?
How
do
we
want
to
split
this
out
with
the
next
item,
which
is
the
spike
for
doing
the
signing
of
the
artifacts?
You
have
any
thoughts
on
how
to
organize
the
work
here.
B
So
I
will
I
will
talk
with
the
container
I'll
drop
by
the
container
registry
groups
Channel
and
see
if
I
can
find
any
resources
from
them
and
I'll
share.
Those
back
with
the
group
also
I'll
start
doing
the
refundment
on
the
Epic
and
creating
the
implementation
issues,
and
so
once
I
have
those
I
can
ask
Ellie
to
have
a
look
at
them.
B
B
We
also
have
Chris
from
Google
on
the
call
who
he's
kind
of
been
looking
the
whole
time.
I
wanted
to
ask
and
the
what
he
thinks
about
this,
because
I
think
having
an
external
perspective
is
really
valuable.
So
Chris,
you
might
not
have
the
context,
but
based
on
what
you've
seen
on
the
call
does
it
does.
What
we're
doing
seem
to
make
sense.
C
A
A
All
right:
well,
we
are
practically
at
times
so
yeah,
let's,
let's
go
ahead
and
move
on
to
this
next
part.
I
have
a
lot
less
to
say
about
this
one
other
than
you
know
right
now,
I
think
when
we
first
started
down
those
path,
it
seemed
like
it
was
going
to
be
a
fairly
simple
problem
and,
as
we
explored
it
more,
we
quickly
realized
that,
not
surprisingly,
you
know
signing
things
is
much
more
difficult
than
we
initially
thought
so
at
a
very
high
level.
A
So
if
somebody
else
wants
to
sign
it
with
their
own
private
key,
they
can
come
along
and
sign
it
as
well,
but
just
having
that
initial
signing
happen
by
default
out
of
the
box
for
anything,
that's
built
on
gitlab,
that's
sort
of
the
end
state
vision
getting
into
the
details
of
how
do
we
then
move
forward
with
giving
the
runner
an
oidc
identity?
A
And
you
know
how
do
we
authent,
you
know
securely
transfer
any
tokens
or
credentials
that
are
required
for
that
back
and
forth
between
the
gitlab
server,
which
is
an
identity
provider
and
the
runner,
those
start
to
become
a
little
bit
more
complicated
and
nuanced,
and
so
that's
why,
for
this
one
we're
not
even
trying
to
move
into
implementation,
we're
just
starting
this
out
with
a
generic
research,
Spike,
there's
a
lot
of
context
and
Link
threads
and
other
discussions
that
have
happened
in
the
past,
but
at
a
high
level
here
we're
just
trying
to
figure
out.
A
How
can
we
get
to
that
end
state?
Do
we
want
to
do
some
things
in
the
middle
like
to
have
good
iteration
and
to
move
towards
it?
Incrementally
you
know
what
is
it
that
needs
to
be
done,
so
that's
what
this
research
spike
is.
It's
just
to
go,
explore
those
unknowns
and
help
us
start
to
put
together
a
plan
on
how
we
can
move
forward.
B
Yes,
so
I'm
I'm
a
bit
skeptical
about
the
native
signing,
because
there
is
no
standardization
for
it
and
that's
really
important
so
I
see
Chris
has
his
hand
raise
I'm
gonna.
Let
him
talk
like
as
soon
as
I
finish
this,
but
the
things
we
can
do.
We
can
use
cosine
and
we
can
do
kind
of
the
same
verification
that
I
talked
about
earlier,
where
you
can
verify
like
a
group
or
a
project,
a
branch
Etc.
B
The
thing
is
that
since
there's
no
standardization,
people
would
have
to
write
their
own
verifiers
and
basically
write
their
own
code
to
verify
those
signatures
in
those
claims
and
I.
Don't
think
I,
don't
think
that's
going
to
work
very
well.
So
there's
like
nothing
in
the
ecosystem
right
now
to
support
verification
of
those
signatures
and
I.
Think
Chris.
C
Actually,
I
think
I'm
gonna
do
my
sales
pitch
for
salsa
now,
which
was
like
you
gave
a
good,
a
good
introduction.
So
there
is
a
standard
for
a
build
generating
build
provenance
which
is
not
exactly
code
signing
but
very
closely
related
and
the
standard
is
pretty
well
developed.
It
is
reaching
its
1.0
release
sometime
in
the
next
couple
of
weeks
and
so
I
think
that
that
could
be
a
great
format
for
you
to
use
to
to
meet
the
the
most
of
the
same
goals
as
straight
up
code
signing.
C
There
is
also
a
salsa
verifier
tool
that
is,
the
community
contributes
to
it,
and
you
could
put
your
all
of
the
metadata
needed
into
that
tool
to
verify
your
signatures.
So
there
there
is
actually
a
framework
and
some
infrastructure
that
you
can
build
this
feature
on
top
of
Carmen
I'm
here
pretty
because
I
want
to
see
this
also
be
successful,
and
it
would
be
great
if,
if
we
could
convince
you
to
adopt
it.
A
Yeah
I
think
we
definitely
want
to
be
producing
like
salsa
compliant,
attestations,
I
guess
maybe
I'm,
not
a
hundred
percent
clear
on
the
full
level
of
overlap
there,
but
I
think
what
you're
saying
is
we
produce
the
it's
also
compliant
attestation,
and
then
we
would
sign
that
attestation
as
part
of
generating
it,
and
that
would
be
the
thing
that
we
would
be
verifying.
Is
that
a
fair
summary.
C
That's
correct
and
the
attestation
contains
a
digest
of
of
the
of
the
built
artifact,
so
you.
B
B
It
I'm
not
totally
familiar
with
sofa,
and
in
total
from
that,
like
I've,
been
researching
it
and
the
more
I
read
the
more
I
think
that
this
is
kind
of
solving
some
of
the
exact
same
problems,
and
it's
also
really
flexible,
so
I
think
there's
some
room
for
people
to
kind
of
build
their
own
solution.
B
A
Yeah
so
I
mean
I
think
we
I
think
that
makes
sense
to
go
down
that
route.
I
I,
don't
understand
enough
of
the
nuances
myself,
but
at
least
right
now.
Our
plan
is
just
to
do
a
big
research
Spike
into
this
area
to
see
if
we
can
find
a
path
forward,
so
I
don't
know.
Does
that
give
us
at
least
enough
to
go
on
for
somebody
to
pick
up
that
research
Spike
and
start
investigating,
or
do
we
have
other
big
questions
that
still
need
to
be
answered.
A
Yeah,
so
my
hope
for
this
would
be
that
we'd
come
out
of
it
having
a
path
forward.
You
know
a
very
high
level
architecture
of
how
we
might
be
able
to
achieve
this
automatic
signing.
Maybe
the
answer
is
just
that
we
produce
a
salsa
attestation
and
sign
that.
Maybe
it's
that
we
signed
the
build
artifact
itself,
but
it'd
be
like
a
really
high
level
architecture
on
how
we
can
move
forward.
That
would
be
the
outcome.
B
B
Yeah
we
can
do
that
I
think
I
think
we
might
and
I'm
going
back
and
forth
a
little
bit,
but
I
do
want
to
refine
that
a
bit
more.
B
One
thing
I
just
think
is
really
important
is
that
we
I
think
we
shouldn't
be
inventing
our
own
thing
in
terms
of
the
cryptography
I
feel
like
we're
doing
the
payoff.
If
you
do
that,
so
I
really
want
to
rely
on
an
existing
standard
or
any
of
these
cryptographic
signatures
and
verification.
B
A
B
Yeah
I've
been
thinking
about
this
a
little
bit
already
I.
Think
I
think
the
runner
has
like
hidden
CR
job.
So
when
the
runner
uploads
artifacts
at
the
end,
it
actually
creates
a
separate
CI
job
that
runs
a
separate
container.
It
does
the
upload
so
I
think
it's
already
able
to
do
stuff
like
that,
where
we
don't
need
to
actually
embed
software
in
a
runner.
It
can
just
basically
run
and
see
a
job,
that's
internal,
and
it
can
have
anything
inside
that
image
that
it
needs.
A
Okay,
yeah
so
I
mean
I.
Think
all
of
those
questions
would
work
out
in
the
research
Spike.
You
know
whether
we
do
embed
the
software,
whether
it's
a
separate
CI
job.
How
does
it
create
an
oidc
identity?
How
does
it
you
know,
use
that
identity
to
create
a
JWT
token?
How
does
it
then
use
that
token
to
create
a
secret
key
with
full
Co?
That's
used
to
then
sign
the
image
I
mean
I.
Think
all
of
those
things
would
need
to
work
out
as
part
of
the
research
Spike
foreign.
A
Okay,
so
I
know
we
ended
up
having
them
we're
way
over
time.
At
this
point,
but
a
couple
other
things
we
have
a
larger
than
anticipated
team.
Maybe
we
want
to
go
work
on
the
package
registry
in
parallel,
maybe
not
I
know.
The
package
registry
is
a
little
bit
more
complicated
because
there
are
more
ecosystems
there,
but
that's
sort
of
just
an
open
question
for
the
group.
If
we
have
more
people
than
are
needed
for
these
two
items,
maybe
we
spin
up
another
effort
in
parallel.
A
It's
probably
not
a
question.
We
need
to
answer
now,
but
it's
more
of
just
a
note
right
now
and
we
can
add
that
as
needed
later
on
foreign,
okay
and
I
can
take
this
last
one
async
I
think
maybe
we
can
discuss
the
meeting
schedule
and
Cadence
in
Slack
instead,
so
that
would
bring
us
to
the
end
of
our
agenda
agenda
today.