►
From YouTube: SSCS Working Group Meeting - August 21, 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
All
right,
Welcome
to
our
weekly
software
supply
chain
security
group
meeting
Daniel
you've
got
the
first
item
for
us.
B
Yeah
so
I'm
coming
into
containers,
signing
fresh
and
so
I
just
have
some
questions
about
how
it's
supposed
to
kind
of
all
work.
I
have
an
idea,
but
I
just
want
to
check
my
understanding
to
make
sure
I'm
not
missing.
Anything
I
did
ask
a
few
questions
in
one
of
the
threads
that
I'll
link
in
the
the
the
dock,
but
yeah.
B
Basically,
I
was
just
wondering
from
a
front-end
perspective,
how
we
can
associate
these
signatures
with
the
images
and
then
some
questions
around
some
edge
cases
that
I've
identified.
C
Yeah
we
are
I,
can
answer
those
questions
asynchronously,
but
we're
basically
going
to
be
adding
signature
data
to
the
exact
same
API
response.
That's
already
being
used
to
populate
the
the
tag
index,
but.
C
End
work
has
some
pretty
substantial
blockers
related
to
like
number
two
that
Sam
wants
to
discuss,
which
is
we
have
to
be
able.
We
have
to
implement
signature
verification
in
gitlab
first
and
that's
proven
to
be
really
challenging
like
it's
like
a
I,
don't
want
to
say
proprietary,
but
it's
very
specific,
like
implementation
and
there's
no
Ruby
implementation
for
it.
Yet.
B
Would
you
have
a
sample
like
a
response
from
the
back
end,
assuming
that
everything
is
in
place,
so
that
I
can
at
least
go
and
create
the
front
end
issues?
Assuming
that
all
the
work
is
done.
B
Yeah,
it
doesn't
have
to
be
final.
I
just
need
an
idea
of
how
like
what
it
looks
like,
so
that
I
could
create
the
issues.
A
A
Also,
as
we
were
talking
about
this
I'm
wondering,
could
we
maybe
move
a
little
bit
more
iteratively
on
this
by
first
just
associating
the
signature
with
the
package
or
with
the
container
image
and
then
doing
the
verification
later
on?
So
maybe
we
could
just
because
right
now,
it's
really
disjointed.
You
see
the
container
image
in
the
UI
and
then
the
signature
is
somewhere
else
completely
not
associated
at
all.
C
C
The
Blob
could
potentially
be
very
big,
so
maybe
you
can
show
it
if
it's
below
a
certain
five.
B
We
can
start
with
just
the
the
signature
or
just
assigned
or
not
signed
badge
for
now
and
I.
Would,
in
that
case
that
reduces
the
scope.
A
lot
and
I
would
just
need
to
know
what
I
should
do
or
how
I
should
associate
the
signature
with
the
image,
because
I've
I've
looked
at
the
data
coming
back
currently
and
I
can
pull
the
the
digest
out
of
the
signature
name,
but
I
didn't
find
anything
else
that
I
could
use
to
match
it
up
with
an
image.
So.
C
Yeah
yeah,
so
we're
we're
implementing
so
we're
actually
implementing
a
new
a
new
feature
in
the
registry
called
Rippers,
where
essentially,
an
image
can
have
many
refers,
and
it's
just
a
list
of
the
Digest
of
learn
each
each
other
manifest
that
refers
to
this
one.
So
it's
like
it's
like
a
it's
like
a
foreign
key.
Basically,
and
so
one
image,
one
one
manifest
can
be
related
to
many
other
manifests,
and
so
we
would
just
return
a
list
of
the
Digest.
C
So
you
could
you
could
individually
fetch
those
addresses
and
like
check
the
check.
The
Manifest
video
for
those.
B
Is
that
something
that
will
be
completed
soon
or
are
we
still
or
is
that
a
while
out,
basically
I'm
asking
if
we
want
to
prioritize
getting
the
the
signed
state
in
ASAP
or
if
we
could
wait
for
that
to
be
in
place?
First.
C
I
think
I
think
I
think
for
that
to
be
in
place,
but
I
think
I'll
be
done
in
a
milestone
or
two
like
like
Aaron's
working
on
that.
Currently
the
thing
is
is
I,
think
the
the
rails.
B
C
That
is
being
used
to
populate
the
data
for
the
tag
index.
I
think
that's
a
different
API,
that's
on
top
of
the
registry.
So
so
there's
the
registry,
API
and
then
rails
has
like
an
intermediate
API
between
that
which
is
being
used
to
return
database
front
end.
So
we
would
have
to
update
both
of
those
first.
B
In
in
that
case,
for
the
front-end
issue,
creation
I
feel
like
I.
Don't
have
enough
information
yet
to
really
estimate
the
work?
It's
not
going
to
be
a
lot
I,
don't
think,
but
I
also
can't
really
come
up
with
a
decent
implementation
plan,
without
even
seeing
what
the
data
I'd
be
integrating
against.
B
C
Yep
so
I
will,
like
I,
did
see
your
comment
this
morning.
I've
been
doing
maintaining
reviews
all
day,
so
I
haven't
gotten
the
chance
to
respond
yet,
but
I
did
see
your
comment
and
I'm
going
to
plan
to
answer
your
questions
and
I
can
also
provide
sample
data
structures
for
you.
I
should
be
able
to
do
that.
You
know
by
by
Wednesday
or
Friday
somewhere
around
then.
A
B
Yeah
so
I
can
create
the
issues
based
off
of
like
a
amok.
Api
I
can
even
start
some
of
the
implementation
chances
are,
though
it
will
change
enough
that
I
will
have
to
basically
rework
the
Mr
once
the
actual
feature
is
available
and
once
I
am
because
there's
always
like
you
know,
things
that
come
up
and
that
you
didn't
anticipate
so
I
could
do
that.
The
other
option
is
to
just
do
it
in
one
goal.
Once
the
the
actual
data
is
available,
both
are
choices.
B
A
B
The
other
option
is
that
I
do
have
the
signature
hash
that
I
can
get
out
of
the
name,
and
then
I
can
associate
that
with
an
image.
And,
although
that's
not
quite
the
you
know
the
the
method
with
the
the
digest
that
Brian
was
talking
about,
it
will
at
least
fix
the
problem
now
without
any
additional
backend
work.
If
that's
desirable,.
A
C
A
C
Think
the
I'm
having
trouble
remembering
but
I,
think
the
spec
for
the
new
referrals
format
says
that
you
have
to
be
able
to
fall
back
to
that
file.
Name
format
so
like
we're.
C
They,
the
backend
API
that
we're
implementing
is
going
to
return
all
the
images
that
are
in
that
file
name
format.
But
it
will
also
return
images
in
that
have
rappers.
So
the
the
referred
images
might
not
necessarily
always
be
in
that
name
format,
but
if
you
have
to
be
able
to
fall
back
and
show
the
ones
that
are
in
that
naming
format,
but
not
using
the
new
API.
A
Okay,
then,
for
the
front
end,
I
I
think
we
should
try
to
just
move
forward
with
developing
against
the
mock
API
spec.
That
Brian
provides
and
do
that
behind
a
feature
flag
and
then
you're
right,
like
if
things
do
change,
we'll,
have
to
modify
it.
But
that
way
that
way,
we're
not
creating
a
solution
on
the
front
end
that
we
would
end
up
just
throwing
away
entirely.
C
Yeah,
the
other
thing
is,
is
which
you
have
to
kind
of
be
careful
about
the
performance
aspect,
I
think.
If
you
want
to
get
all
the
signatures,
you
know
you
would
have
to
make
individual
requests
for
every
single.
C
A
C
A
Okay,
one
thing
Daniel
that
you'll
probably
want
to
consider
is
because
there
can
be
one
like
it's
a
one-to-many
relationship
and
unfortunately
we
did
it
100
finish
the
ux
designs
before
we
lost
our
ux
designer
who
was
on
this
project.
A
So
one
thing
to
think
about
is
how
we
might
be
able
to
handle
that
if
there
are
two
signatures
or
five
signatures
or
20
signatures,
I
mean
those
are
like
really
far
edge
cases,
but
we
might
need
to
adjust
the
designs
a
little
bit
and
if
you
need
us
to
get
a
ux
designer
to
help
with
that,
let
me
know,
but
if
you
feel
like
you
have
a
reasonable
idea
that
seems
like
it
would
work.
We
could
probably
also
just
move
forward
with
that
is.
B
It
that
the
is
it
important
for
the
user
to
see
all
the
signatures
and
to
identify
which
ones
were
verified
and
which
ones
weren't,
or
is
it
only
important
for
like
say
one
of
them
to
be
valid.
A
If
one
of
them
is
valid,
that
would
be
the
most
important
thing,
but
I
would
still
expect
that
there
would
be
a
way
for
them
to
like
drill
in
like
expand
out
and
get
a
full
list
of
all
the
signatures
and
their
verification
status
and
click
into
the
details
for
them
individually.
If
they
wanted
to.
C
Thing
is
is:
is
that
the
verification
framework
is
kind
of
flexible
so,
depending
on
the
things
valid
might
mean
different
things,
different
people,
depending
on
like
your
security
policies,
you
could
say
you
like
you,
you
would
be
checking
like
certain
attributes
and
things,
and
so
it's
it's
basically
up
to
the
user
to
determine
which
ones
are
important.
A
Yeah
so
for
this
iteration,
let's
do
that
same
thing,
but
just
don't
make
any
statement
about
whether
or
not
it's
valid
just
say
this
image
has
a
signature
or
it
doesn't.
And
then,
if
somebody
wants
to
drill
into
that
and
say,
oh,
it
actually
has
20
signatures
here.
Let
me
get
a
list
of
them
and
I
can
get
the
details
for
each
one
and
we'll
add
in
the
validity
later.
B
If
we
still
have
questions
after
that,
we
can,
we
can
either
what's
called
it
refined
or
involve
a
ux
designer.
Okay,.
A
A
You
know:
we've
been
exploring
the
option
of
maybe
trying
to
convince
openssf
to
help
fund
a
contractor
who
would
build
and
test
a
ruby,
Library
I
think
that
is
a
viable
path.
I
think
there's
a
good
chance
that
could
happen,
but
it
also
is
likely
to
take
quite
a
bit
of
time
because
they
still
would
have
to
develop
that
whole
Ruby
library
and
then
they
would
have
to
go
put
it
through
a
full
security
vetting
process,
and
all
of
that
would
even
only
start
after
the
budget
was
approved
and
allocated.
A
C
C
One
thing
is
so
about
the
proposal:
they're,
actually
not
wanting
to
build
a
ruby,
Library
they're
wanting
to
build
bindings
written
in
Rust
that
can
be
called
from
every
programming
language,
so
essentially
something
akin
to
c-bounding
by
written
and
Rustin
said,
and
then
you
could
use
those
bindings
like
similar,
it's
kind
of
similar
to
open
SSL
like
a
ton.
C
C
So
I
haven't
I,
haven't
read
the
issue
yet,
but
it
looks
like
it
was
a
proposal
and
they
haven't
actually
implemented
it.
Yet
is
that
right?
Does
that
sound
right.
C
And
let
me
let
me
take
a
look
real
quick.
We
can,
we
can
do
it
together,
but
yeah
a
girl,
Ruby
ffi.
This
is
this
is
like
the
same
thing.
I
was
talking
about
about
the
rest,
the
rest
funding.
It's
like
the
same
thing,
but
to
go.
D
Like
I
think
near
the
bottom,
there
is
a
comment
saying
closes
this
as
completed
with
the
merge
of,
and
then
they
list
three
or
four
Mrs
yeah
that
one.
So
that
makes
me
think
that
they
did
something
towards
this.
A
Yeah,
so
my
thought
was,
we
don't
know
how
long
it's
gonna
take
to
go
the
route
of
getting
this
Ruby
Library
through
openssf
and
maybe
that's
the
best
long-term
solution.
But
if
there's
something
faster
or
easier
here
that
we
could
do,
you
know
it
could
be
like
a
year
before
the
open,
ssf
thing
is
done,
and
so
there's
something
here.
We
could
do
in
a
month,
for
example,
I'm
just
throwing
out
time
periods
but
like
we
could
do
something
in
a
month
here
and
use
that
for
a
year
and
then
switch
over
later.
C
C
So
I'm
kind
of
like
I,
don't
know
about
that.
The
other
thing
is
the.
C
The
six
I,
don't
think
I,
don't
know
if
cosigning
is
meant
to
be
used
as
a
library.
So,
even
if
we
do
this,
it
might.
A
Okay,
well,
I
will
try
to
get
something
started
then,
on
option
number
one
Brian,
I'm,
probably
gonna,
need
your
help
to
add
in
a
lot
of
the
technical
details
for
the
proposal,
so
I
can
get
started
with
some
of
the
business
case,
and
you
know,
I
I
can
open
up
the
initial
issue,
but
I'll
tag
you
in
it.
If
you
can
add
in
all
of
those
technical
details,
that
would
be
really
helpful
and
it
looks
like
we
have
some
good
support
for
this
too,
like
from
a
few
different
companies.
C
Okay,
that
sounds
good,
exciting.