►
From YouTube: SSCS Working Group Meeting - July 10, 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
Welcome
to
our
weekly
group
meeting
for
the
software
supply
chain,
security
working
group,
I
have
just
a
couple
of
questions.
Here,
looks
like
we
don't
have
everyone
on
and
I
apologize,
because
I
put
my
questions
in
really
late,
so
I
didn't
have
the
full
24
hours
in
advance,
but
we'll
see
how
many
we
can
get
through
so
I'm
wondering
do
we
have
anyone
on
the
team
who
can
help
with
the
front
end
work
for
the
user
experience
for
signed
container
registry
images
I
know
technically.
Everyone
here
is
our
backend
Engineers.
B
B
C
B
A
So
we
had
Daniel,
but
he
ended
up
getting
pulled
off
for
AI
and
anyway,
so
I
can
work
to
get
a
front-end,
an
actual
front-end
developer
back
in
the
working
group,
whether
it's
Daniel
or
somebody
else.
A
But
it
does
feel
like
most
of
our
front
end.
Work
is
really
light
and
more
of
like
a
temporary
thing
than
the
back
end
work
that
has
a
pretty
long
roadmap
associated
with
it.
So
I
was
just
trying
to
feel
out
whether
there's
somebody
already
on
the
team
who
might
be
able
to
take
that
on
and
it's
sort
of
a
very
temporary
full
stack
capacity
type
thing
or
if
we
need
to
go,
find
an
actual
front-end
developer
to
come
in
and
help.
B
A
Yeah
I
think
that
would
be
less
disruptive
I'm
just
a
little
bit
hesitant
to
pull
somebody
off
of
their
current
work
just
to
help
out
here
for
a
tiny
bit,
and
then
you
know
it's
just
the
more
context.
Switching
you
give
people
the
harder
it
is
so
if
they
can
kind
of
at
least
keep
doing
their
current
workload
and
maybe
just
assist
a
little
bit
I'm
sure
that
would
be
yeah.
B
B
Maybe
that's
just
someone
on
the
team,
whose
area
we're
working
in
like
whoever
owns
the
front-end
components
that
we're
going
to
modify.
A
That
is
true.
We
may
be
able
to
get
some
help
from
like
the
registry
team
or
one
of
their
front-end
Engineers
is
a
that's
a
great
idea.
A
Okay,
so
item
number
two
I
just
wanted
to
confirm
so
once
16
2
is
done
and
we
finish:
shipping
the
CI
CD
signing
integration
with
cosine
at
least
my
understanding
was.
The
plan
was
to
go
back
to
Priority
One
on
the
list,
which
is
actually
the
research
spike
in
designing
build
artifacts
by
default.
A
Perhaps
I
can't
remember
exactly
what
he
said.
I
think
it
was
next
Milestone
because
he
was
already
full
this
Milestone,
but
I
think
that's
the
next
step
after
this
I
just
wanted
a
confirmed
that
we're
all
on
board.
With
that
and
then
b,
ask
if
there's
any
way
I
can
help
facilitate
that
if
I
need
to
reach
out
to
some
of
the
engineers
on
the
runner
team
or
start
setting
up
some
calls
just
to
talk
through
any
of
that
I
I,
don't
know
what
would
be
helpful
here.
B
I
think,
personally,
from
my
side,
there's
some
follow-up
work
related
to
the
signing
work.
We're
shipping
in
16-2,
so
I
will
probably
be
busy
with
some
of
that,
but
I
think
I
do
remember
that
Brian
said
something
about
taking
it
on
and
yeah
I
think
there's
a
bunch
of
older
discussion
threads
where
we
even
have
people
talking
through
what
the
architecture
might
look
like.
So
I
think
there's
a
lot
of
good
discussion
to
go
through
there.
I
feel
like
we
have
enough
information.
Oh
Brian
is
here.
C
Hey
how's,
it
going
do
you
have?
What
were
you
talking
about.
A
So
we're
on
number
two
in
the
agenda,
but
we're
talking
about
once
we
finish
this
integration
with
cosine
I
know
the
plan
was
to
do
that
research
Spike
into
how
we
can
automatically
find
build
artifact
by
default
in
the
gitlab
runner,
I.
Think
Brian.
You
were
going
to
do
that.
Research,
Spike
I,
can't
remember
the
timing
around
that
I
think
you
said
you
were
going
to
start
that
in
16-2,
but
I.
Don't
remember.
C
C
A
Just
to
confirm
okay,
yeah
I'll
have
to
go
look
up
that
name,
but
I'll
I'll.
Send
it
to
you
later.
A
A
C
Okay,
yeah
I
I
should
be
able
to
start
doing
that.
You
know
now.
I
do
have
a
little
bit
of
work
that
I'm
wrapping
up,
but
I
can
start
working
on
that
also.
A
Okay,
great
I
will
do
all
right
so
number
three
I'm
just
wondering:
does
anyone
have
contacts
in
their
Network
who
work
at
Docker?
I
know
we
talked
about
previously
that
if
we
want
to
automatically
sign
Docker
images,
we
might
need
to
actually
contribute
to
the
docker
CLI,
and
if
that
is
the
case,
I
would
like
to
start
that
partnership
and
those
discussions
earlier
rather
than
later,
because
anytime,
you
have
two
companies
coordinating
things
can
move
really
slowly.
C
A
C
B
Yeah
I
was
just
asking
if
we
should
prioritize
supporting
keyless
signing
when
the
CI
config
is
located
outside
of
the
project
for
our
16-2
release.
We
only
support
signing
if
the
CI
config
is
in
the
project,
which
should
cover
the
majority
of
projects.
But,
for
example,
we
don't
support
Auto,
devops
or
if
the
CI
config
is
located
in
another
repo
or
pointing
at
an
arbitrary
URL.
A
Yeah
thanks
for
reminding
me
about
that,
I
forgot
about
all
that
follow-on
work,
so
I
think
we
should
prioritize
that
at
priority
three,
the
same
place
as
the
work
that
we
had
before,
so
that
would
still
put
it
lower
than
the
user
experience
for
signed
container
registry
images
and
that
would
put
it
lower
than
getting
started
on
the
default.
You
know
signing
build
artifact
by
default.
A
A
Right
Ellie
was
saying:
maybe
he
could
help
some,
especially
if
we
found
another
funny
front
end
to
act
as
a
mentor.
So
we'll
we'll
probably
try
that
if
I
need
to
get
a
front-end
engineer
to
come
over
into
the
working
group,
we
can
do
that.
It's
just
probably
going
to
be
disruptive
to
them
to
pull
them
off
of
their
work
just
to
help
with
this
for
a
short
time
and
then
put
them
back.
So
I
was
hoping
to
avoid
that,
if
possible,
but
yeah.
C
A
And
I,
actually
the
front
end
is
probably
my
strongest
Point.
Personally
I'm
I
can
do
some
front
end
coding
as
well,
but
I'm
also
not
a
front-end
developer.
So,
especially
if
I
can
get
help
with
some
of
the
tests
and
things
usually
I
can
make
it
work.
But
we'll
see
okay,
I'll
see
who
we
can
get
to
help
us
with
that,
so
that
we
can
actually
ship
that
one.