►
From YouTube: SSCS Working Group Meeting - April 24, 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
everyone
to
our
weekly
software
supply
chain
security
working
group
meeting
Brian
looks
like
you've
got
the
first
item
for
us
here
today.
B
B
Wondering
let
me
double
check
whatever
yeah
so
about
that
automated
signing
I've
been
looking
at
the
architectural
blueprint
and
I'm
having
trouble
figuring
out
Harriet,
get
that
to
work.
I.
Think
I
think
we
can
do
it
for
see
our
job
artifacts
but
I'm,
not
sure
if
it's
feasible
to
do
for
other
types
like
for
container
images
or
for
packages,
because
that's
that's
kind
of
decoupled
from
the.
B
Mcsd
configuration
you
know,
you
use
the
script
to
upload
your
container
image
to
the
registry
or
upload
your
package
to
wherever
the
package
is
being
saved.
So
it's
not
really
from
the
perspective
of
the
runner.
The
runner
is
not
going
to
be
able
to
tell
what
bios
need
to
be
signed
and
where
the
signature
should
go.
C
Yeah
yeah
in
terms
of
like
the
the
yaml
keywords,
I
I,
think
this
whole
thing
is
like
probably
incompatible
with
the
artifacts
keyword,
mostly
because,
like
that
is
uploaded
as
like
a
single
zip
file
right
and
and
there's
not
going
to
be
a
way
to
like
easily
sign
individual
artifacts
Within
that
blob
Brian,
it
might
be
worthwhile
to
to
sync
up
separately
with
Billy,
because
he's
done
some
work
on.
That's
basically
exactly
the
same
in
tecton.
So
you
could
look
at
like
how
they
are
are
signing
artifact,
outputs,
yeah.
A
B
Yeah
I
think
I
think
it's
actually
feasible
to
do
it
for
artifacts.
It's
just
it's
the
other
kind
that
I'm
not
sure
about.
Like.
B
A
A
Another
idea
that
I
have
is
just
if
we
could
watch
the
script.
I
don't
know
if
there's
a
way
to
monitor
what
Linux
commands
are
being
run
in
a
job,
but
if
we
can
monitor
for
a
Docker
build
command
and
then
we
could
trigger
off
of
that
and
sign
the
resulting
output
anytime,
we
see
a
Docker
build
command
that
might
be
another
option
and
then
this
last
one
maybe
is
a
little
bit
more
of
a
stretch.
But
regarding
the
question
of
how
do
we
push
it
in?
A
You
know:
I
I,
don't
know
if
there's
an
easy
way
to
do
this,
but
I'm
not
familiar
enough
with
the
structure
of
the
docker
image
file
format,
but
maybe
there's
some
way.
We
can
embed
our
signature
in
so
that
at
least,
if
they're
pushing
into
the
gitlab
Container
registry,
the
signature
would
just
go
along
with
the
file
I,
don't
know,
but
a
couple
of
questions.
C
And
I
think
another
thing
to
I:
I,
don't
have
a
solution
here,
but
another
thing
to
to
be
considering
is
that
I
I
think
in
terms
of
like
the
pre-bake
solutions
that
we
provide.
C
It's
gonna
be
ideal
if
folks
have
an
option
to
like
do
container
image,
build
and
s-bomb
generation
and
signing
both
of
those
things
in
the
same
workflow
specifically
because
like
if
you
try
to
do
s-bomb
generation
after
the
fact
on
a
container
image,
that's
already
been
built,
you
potentially
can't
get
as
Rich
of
metadata
as
you
can
get
with,
like
various
package
manager,
plugins
and
whatnot
that
can
feed
into
s-pomb
generation
at
build
time.
A
C
I
I
was
just
trying
to
like
point
out
that,
like
there's,
there's
going
to
be
these
other
use
cases
that
I
don't
see
an
easy
way
to
solve
without
the
without
components
or
something
like
that,
as
you
were,
as
you
were,
getting
at
I
just
meant.
There's
there's
going
to
be
a
couple.
Other
steps
in
there
that
need
to
take
place,
and
those
are
I
was
just
pointing
out
that
that
stuff
is
hard
to
do
as
like
a
bolt-on
after
the
image
has
already
been
built
thing.
B
Yeah,
okay,
so
the
the
next
thing
I
had
related
to
that
was
I
think
we
should
probably
prioritize
assuming
that
I
think
we
should
probably
prioritize
based
off
of
what
you
can
already
do
with
good
app
today.
So
it's
already
possible
to
you
know,
run
cosine
and
csvd
and
use
that
to
sign
images
and
so
I'm
thinking.
We
should
probably
sign
prioritize,
like
distinction,
verification
step
in
showing
the
signature
better,
that,
like
the
ux
improvements,
transplant
signature
before.
B
Over
like
the
automatic
signing,
because
the
the
certain
images
is
something
you
can
already
do
today
and
I
think
that
would
be
the
quickest
value
as
opposed
to
creating
a
new
solution
like
the
automatic
signing
tool.
A
C
Okay
and
I
I
agree
with
that
too,
because
the
further
along
the
verified
folks
get
with
the
CI
catalog
and
potentially
steps
and
stuff
like
that,
then
the
easier
everything
else
becomes
too.
So
if,
if
we
have
other
things
that
we
can
do
well,
they
work
that
in
parallel
that
can
wind
up
better
in
the
future.
B
C
I
I
wanted
to
hijack
you
real,
quick
just
because
I
have
a
hard
out.
I
actually
have
a
conflict
that
I'm
supposed
to
be
in
right
now,
but
I
just
wanted
to
understand
what
we
think
will
not
land
by
16.0,
because
I
was
under
the
impression
that
that
was
sort
of
the
target
for
the
for
the
polkio
integration.
A
C
No,
the
the
claims
that
need
to
be
added
to
the
gdts
and
then
incorporated
into
the
polkio
specs,
which
is
I,
think
what
Ali
was
working
on.
C
I'm
also
still
running
down
with
Dov
and
Jackie,
like
what
our
options
are
for
doing.
The
issuer
like
like
having
a
separate
issue
of
her
per
CI
tokens.
C
A
C
Because
the
the
big
problem
I
realized
like,
in
addition
to
folkio
we're,
also
pursuing
an
external
partner
Innovation
with
npm
and
in
order
to
get
like
the
verified
badge
on
npm
packages
that
are
signed
with
volcio
they're
going
to
have
to
like
within
the
closed
Source
software
that
exists
on
their
registry.
They're,
going
to
have
to
establish
trust
with
that
issuer
domain
and
so
like.
If
we're
going
to
break
that
at
any
point,
whether
it's
now
or
16.x
or
17.0,
we
have
to
before
I
can
engage
with
them.
On
that.
C
D
Quick
question
for
the
the
16
Auto
release.
What
would
be
the
timeline
for
that?
If
we
get
the
full
seal
claims
in
like
when,
would
that
go
live
on
on
goodlab.com.
A
Oh
yeah
great
question,
so
our
release
dates
are
when
we
do
the
cut
for
our
self-managed
users,
so
technically
16.0
ships
to
users
on
May
22nd,
but
you
would
actually
see
that
go
live
on
gitlab.com
much
earlier
than
that,
so
our
fast
offering
runs
basically
the
Alpha
version.
I
think
it's
technically
Alpha
of
16.0
already,
and
so
we
make
code
changes
anytime
between
now
and
usually
the
release.
Cutoff
is
around
I.
Think
the
17th
at
the
absolute
latest
so
anytime
between
now
and
May
17th.
C
A
Yeah
or
well,
it
will
technically
be
before
then
that
will
reach
kitlab.com.
But
yes,.
C
D
B
D
B
Guess
I
have
the
next
one.
I
was
looking
at
the
architecture
blueprint
that
was
started
on
by
the
runner
team
and
it's
it's
very
Bare
Bones.
It
seems
to
be
about
automatic
on
my
signing
of
job
artifacts.
B
A
Yeah
so
I
just
for
some
context
here,
I
think
Darren
opened
this
trying
to
get
everyone
aligned
on
the
technical
approach.
This
was
before
we
had
the
working
group
stood
up
and
you
know
we
had
Marshall
raising
questions
about
whether
we
needed
a
separate
oidc
provider
or
not,
and
so
I
think
Darren
was
just
trying
to
get
everybody
aligned
in
an
agreement.
I
think
we've
actually
done
most
of
that
now,
so
we
may
not
need
it
anymore,
so
yeah
just
feel
free
to
comment
on
it.
A
A
Okay,
yeah,
that's
fine,
I,
just
think
at
the
time
that
Darren
opened
that
we
had,
you
know
just
a
lot
of
a
lot
more
disagreement.
You
know
around
that
whole
question
around
the
oidc
provider
and
whether
or
not
we
need
it
to
deprecate.
Some
of
these
other
items
that
Marshall
has
been
suggesting
and
the
whole
workflow
was
just
a
little
bit
less
clear
and
I.
If
you
feel
more
confident
in
that,
then
I
I,
don't
think
I
agree
with
you,
I,
don't
think
it's
needed
anymore.
A
A
Okay,
all
right
I
can
read
a
couple
of
these
for
Nathan
who's,
not
on
the
call.
So
what
do
you
all
think
about
creating
a
retrospective
issue
for
each
Milestone
he'd
opened
an
MR
to
get
this
started?
We
can
add
anyone
else
who
wants
to
join
in
you
know,
especially
if
we
are
going
to
be
contributing.
80
percent
of
our
time
here
would
retro
be
useful
or
not.
B
B
Would
issue
would
be
fine,
I
find
that
I
don't
participate
in
them.
Very
often,
though
so
I
mean
we
can
do
it,
but
we
might
not
get
participation
at
least
not
for
me,.
A
Yeah
that
works
for
me,
okay
and
then
the
next
item
from
Nathan
is
everyone
using
the
working
group,
fsds
label
on
issues
and
Mrs
I'm,
looking
at
dashboards
using
this
label.
If
this
is
the
right
label,
which,
yes,
it
is
the
correct
label,
can
everyone
please
retroactively
add
to
any
current
and
completed
Mrs
and
issues
would
just
be
the
request
for
anything
you're
working
on.
A
D
Yeah,
so
just
a
quick
update,
there
hasn't
been
any
major
feature
changes
since
we
checked
in
last
week,
there's
been
a
lot
of
just
discussion
on
like
what's
the
right
thing
to
do
for
for
falsio
and
npm
stuff,
like
that.
D
D
I
think
we
got
mostly
agreements
on
the
spec,
so
I
think
just
some
final
knits,
and
then
we
can
go
ahead
and
submit
that
and
then
we'll
we'll
revive
the
the
older
PR
for
actually
adding
the
support
for
folsio,
though
some
of
this
is
going
to
be
blocked
on
the
IDC
claims
that
we
mentioned
before,
which
is
why
I
was
curious
when
those
would
sort
of
go
live
once
once
they're
merged
beyond
that
there
is
the
pr
out
for
the
npm
CLI
we're
starting
we're
going
to
merge
it
into
a
separate
Branch,
so
it
won't
be
in
in
the
the
latest
Branch
to
start.
D
This
actually
gives
us
a
bit
more
flexibility,
because
we
can
go
ahead
and
make
breaking
changes
not
worry
about
it.
We're
also
going
to
start
on
v0
Alpha
1
version,
just
to
make
it
a
little
clear
to
users
that,
like
this
might
change
until
we're
we're
sort
of
happy
with
how
that
Providence
spec
looks
like
I
do
want
to
highlight.
D
A
A
How
can
we
best
coordinate
those
changes
with
you?
Is
that
going
to
be
a
breaking
change?
Do
we
need
to
make
those
changes
now.
D
Depend
it
really
depends
on
your
timeline.
One
of
the
things
to
note
is
that,
even
though
we're
we're
basing
it
off
of
the
existing
Providence,
it
is
technically
its
own
type,
URL,
like
type
URI,
so
there's
no
requirement
that
the
the
need
to
stay
in
sync.
So
it's
totally
fine.
If,
like
you
know,
you
update
one,
then
update
the
other
and
they
those
sort
of
happen.
Asynchronously.
A
Okay,
yeah,
that's
good
to
know,
I,
don't
know
what
the
scope
is
of
your
involvement
here,
but
if
you
do
have
changes
that
you
feel
like
would
be
useful
to
make
in
our
attestation.
It
would
be
great
to
have
those
changes
made
like
that's
on
our
list
of
things
to
do
anyway.
It's
just
timing
wise
and
priority
Wise
It's
Kind
of
a
lower
priority,
because
we
want
to
have
the
signing
in
place,
but
I'm.
B
So
you
were
wondering
about
when
the
RDC
changes
changes
would
be
on.com.
You
can
actually
look
at
merge,
requests
and
see
if
there
aren't
good
at.com
or
not
so
that
cures
one
there's
there's
different
things
you
can
check.
You
can
pick
the
environment
drop
down
here
and
it
tells
you
where
it
was
deployed.
So
if
it
was
deployed
to
G
prawn,
then
that
means
the
merge
request
is
on
github.com.
A
Great
thanks
for
that
I
think
we
have
just
two
more
minutes
unless
there's
something
else
urgent,
I
I,
don't
know.
If
we
fully
discussed
a
couple
of
the
items
earlier,
I
we
kind
of
skipped
over
them,
because
Marshall
had
to
go
so
back
on
one
b,
three
I
was
just
wondering
about
those
first
two
items.
We
talked
about
the
third
idea
quite
a
bit,
but
is
there
any
viability
in
these
two
items
that
I
have
highlighted
here
in
the
agenda
for
convenience.
B
B
B
The
closest
thing
I
can
think
of
doing
is
like
making
a
contribution
to
the
build
tools
to
have
the
build
tools.
Add
signatures,
that's
that's
the
most
elegant
thing,
I
can
think
of
or
outside
of,
like
using
a
template
like
providing
the
template
that
does
like
building
and
signing.
At
the
same
time,.
A
B
Well,
well,
my
when,
when
I
mentioned
the
build
tools,
I
was
thinking
like
we
actually
make
a
contribution.
A
docker
said
it.
When
somebody
does
darker
build,
then
Ducker
does
a
sign
and
step
after
the
build
set
or
I'm,
not
I'm,
not
sure
what
other
build
tools,
people
use
or
like
how
popular
they
are
or
I
know.
Docker
is
like
one
of
the
most
popular
ones,
but
I
know
there's
no
ones
like
chemical
and
stuff
that
supposedly
do
signing
I'm,
not
totally
sure
so.
A
A
Okay,
well,
that
might
be
something
to
think
about
thanks
for
brainstorming.
Those
with
me
I
know
we're
at
time.
So
thanks
everyone
for
the
discussion
today,
I
appreciate
it.