►
From YouTube: SSCS Working Group Meeting - June 5, 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
software
supply
chain
security
meeting
Marshall
you've
got
the
first
item
here.
Do
you
want
to
get
us
started.
B
Yeah,
so
I
was
trained
to
understand
exactly
when
we
expected
the
pipeline
wreck
change
to
land,
I
I
think
we're
on
track
for
16.1,
but
with
the
external
dependency,
I
also
wanted
to
talk
through
the
implications
of
it
being
behind
a
feature
flag
and
that
being
whatever
we
decide
on
on
or
off
by
default.
I
think
there's
implications
either
way.
C
B
C
B
B
That's
all
I
think
we
need
to
know
for
one,
but
it
leads
into
the
the
second
question
which
is
like,
regardless
of
whether
it's
behind
a
feature
flag
or
not.
What
should
the
behavior
be
when
the
when
the
claim
cannot
be
set?
B
And
really
this
is
more
on
the
full
Co
side,
I
think
because
I
don't
know
if
you
noticed
Billy
but
like
I,
also
as
part
of
that
same
PR,
it
updates
the
sand
to
be
derived
from
the
pipeline
ref,
which
I
think
is
I,
think
that's
the
correct
Behavior,
but
it
has
very
strong
implications
that
that
claim
is
not
populated,
obviously
right
and
yeah
I'm,
just
not
I'm,
not
sure
what
what
the
correct
Behavior
would
would
be
here,
like
my
intuition,
is
that
it
makes
sense
to
like
Fail
Hard
and
not
generate
a
certificate,
but
I
can
see
I
I
think
the
alternative
is
that
we
populate
the
same.
B
The
way
that
we're
populating
the
sand
today,
which
is
I,
think
we
basically
just
provide
the
project
flood
like
the
server
URL
plus
project,
slug,
I,
I,
just
I,
don't
know,
I,
don't
know
if
it
makes
sense
to
have
artifacts
out
there
that
are
being
signed
both
ways
or
not.
You
have
an
opinion
on
that
really.
D
Yeah,
this
is
a
good
question.
I
think
as
long
as
it's
deterministic
I
would
be
okay
with
the
fallback
like
as
long
as
we
can
clearly
document
like.
If,
if
it's
under
these
conditions,
then
you'll
get
this
San.
Otherwise,
you'll
get
this
this
other
sand.
D
We
can
hard
fail,
but,
like
you
said
that
will
sort
of
negatively
impact
like
certain
workflows,
will
not
be
able
to
do
the
keyless
signing
flow,
so
I
think
sort
of
order.
Order
of
of
how
I
prefer
would
be
if
we
can
have
a
static
sand
that
we
can
apply
to
everything
great.
D
Let's
do
that
if
we
need
to
have
the
fallback
behavior
that
works
alone,
as
we
can
clearly
document
and
say
when
each
would
would
show
up
and
then
finally,
if
we
want
a
heart
fail
that
that
that's
also
fine
too,
but
I'll,
see
seeing
as
this.
D
This
affects
your
users,
the
most
all
sort
of
defer
to
to
you
all
for
like
what
is
the
the
preferred
Behavior
there,
because
this
will
sort
of
be
a
documentation
burden
on
your
end
as
well
for,
like
which
identities
do
you
have
to
to
verify
and
stuff?
Like
that.
C
C
B
D
C
Yeah
I
wanted
to
Circle
back
on
Sam's
question
about
whether
we're
going
to
be
able
to
announce
something
for
a
16-1.
It
seems
like
pipeline
ref,
the
claim
and
your
your
physio
PR
should
be
able
to
land
in
time.
C
So
I
guess
are
we
okay
with
announcing
that
signing
is
available
only
if
the
build
config
lives
in
the
same
Repository
is
that
something
we'd
be
okay
with
or
do
we
still
want
to
delay
it
until
the
next
Milestone,
when
we
have
support
for
different
types
of
configs.
B
C
C
Yeah
once
Marshall's
PR
lens
and
my
Mr
with
the
pipeline
reflands,
which
we
expect
to,
then
we
don't
have
to
worry
about
stuff
on
the
certificate.
Changing
it's
just
that.
If
the
pipeline
config
does
not
live
in
the
repository,
you
won't
be
able
to
do
keyless
signing
at
this
point.
That's.
A
A
A
C
B
B
Documenting,
like
the
like,
once
we
supported
the
behavior
when
the
config
is
not
local.
A
B
A
C
So
we
don't
have
what's
it
called
ambient
credential
detection
at
this
point
right.
A
C
There's
this
ID
tokens
keyword
and
you
would
set
I
think
it's
called
six
store
token
something
there's
a
defined
value
set
there
and
then
cosine
will
automatically
pick
up
that
token.
C
A
B
And
I
I
think
there's
some
specific
stuff
in
there
that
we're
going
to
want
to
mention
as
just
good
security
hygiene
like,
for
example,
you
should
only
like
you
should
you
should
try
to
build
at
least
on
gitlab
CI.
You
should
try
to
build
and
sign
the
artifact
in
the
same
job
rather
than
like
building
the
artifact
in
one
job
and
it
might
passing
it
as
a
as
an
output
artifact
to
another
job
that
that
signs
it
it's
better
to
build,
build
and
sign
in
the
same
job.
A
A
A
D
One
last
thing
on
the
docs:
once
once
you
guys
have
something
available
on
the
gitlab
side
feel
free
to
send
it
over
my
way
we
can
see
where
we
can
add
it
on
the
six
door
side
for
the
six
star
documentation.