►
From YouTube: Automatic Build Artifact Signing - SSCS/Runner team sync
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
Yeah
I
I
just
wanted
to
talk
through
the
next
steps
here.
Now
that
we've
got
this
keyless
signing
released,
I
want
to
make
sure
we're
reliant
on
the
direction
that
we're
headed.
It
sounds
like
maybe
there's
either
some
misunderstanding
or
misalignment
I'm,
actually
not
100
sure
which,
but
I
want
to
make
sure
that
we're
on
the
same
page,
between
our
two
teams
and
also
you
know,
work
together
to
figure
out
how
we
can
get
the
support.
We
need
to
get
the
new
features
across
the
finish
line.
A
I
wonder
if
it
might
help
just
to
show
real
briefly.
What
we
have
today
in
a
quick
demo.
Would
that
be
useful
to
everyone.
B
I
personally
went
I
went
through
a
doctor,
fine,
either
ways.
A
Okay,
okay
sounds
good,
I'll
I'll
skip
the
demo
then,
but
essentially
right
now,
you
can
sign
build
artifacts,
container
images
and
packages.
Just
by
modifying
a
few
lines
in
your
CI
CD
file.
A
I
know
Darren
when
you
and
I
were
talking
before
I
think
the
vision
was
to
always
have
that
eventually
be
something
that
just
happened
without
even
requiring
developers
to
go
change,
their
CI,
CD,
yaml
file,
and
so
I
still
am
really
hoping
that
we
can
find
a
path
towards
that
to
having
it
be
an
on
by
default.
Experience.
A
I
know
that
there
is
some
concern
because
it
does
generate
another
artifact
file
which
has
the
signature
in
it,
and
so
at
least
when
we
first
released
the
attestation
feature.
We
had
that
behind
a
variable,
so
that
was
default
off
and
then
users
would
have
to
switch
that
variable
to
true
if
they
wanted
to
opt
in.
A
You
know
you
still
would
have
to
change
your
CI
CD
file,
but
it
would
be
fewer
things
that
you
would
have
to
insert
into
the
CI
CD
file
compared
to
now
you
adjust
that
one
variable
to
true,
and
then
it
would
sign
all
of
your
build
artifacts
is
what
we
would
propose
for
the
first
step,
but
I
I
don't
know
it
sounds
like.
Maybe
there
are
some
concerns
about
generating
this
additional
artifact
file
that
I'm
not
fully
understanding.
C
A
D
So
I
think
so
I
think
what
I
think
what
Darren
is
more
interested
in?
Is
you
know
how
would
how
would
users?
How
would
we
expect
users
to
be
using?
You
know
these
signed
artifact
files
and
I?
Think
what
our
plan
is.
Is
that
we're
going
to
start
showing
in
the
lab?
You
are
like
what
artifacts
have
been
signed
and
like
if
they
have
bad
signatures?
D
So
if
you,
you
can
either
verify
those
signatures
manually
by
like
downloading
the
files
and
checking
them
using
command
line
tools,
but
we're
going
to
also
show
that
same
status
in
GitHub
so
that
you
don't
have
to
do
anything.
You
can
just
look
in
gitlab
and
see
like
these
artifacts
are
signed
and
their
integrity
is
good.
C
Okay,
let
me
ask
it
a
different
way:
I
I,
don't
know
anything
about
get
that
artifact
signing
capabilities,
I'm
a
developer,
I
create
a
pipeline,
that's
going
to
create
and
that's
going
to
generate
an
artifact
right,
very
simple
pipeline.
It's
going
to
generate
some
hard
facts
right
and
expect
to
be
able
to
use
that
effect.
Somehow
this,
in
addition
to
Simply
creating
my
gitlab
yaml
file,
which
might
be
a
very
simple
yaml
file
like
hey,
build
something
generate
artifact
do
I
have
to
do
anything
else.
A
So
the
vision
is
no.
It
just
happens
that
that's
where
we
really
want
to
get
to
for
the
first
step
where
we're
at
right
now,
you
have
to
add
I,
don't
know,
maybe
four
or
five
lines
to
your
CIA
yaml.
What
we're
proposing
is
taking
that
and
moving
the
workflow
into
the
runner,
so
it
it
just
cues
off
one
variable,
so
I
forget
what
variable
name
I
proposed.
It
was
like
sign,
enable
signing
or
something
like
that,
and
if
you
set
that
to
true
it
would
just
sign
your
artifacts.
A
So
as
a
developer,
all
you
would
need
to
do
is
set
the
variable
sign
artifacts
to
true,
and
then
it
would
do
all
of
that
signing
for
you
without
any
additional
steps
on
your
part
as
a
developer
and
and
so
that
would
be
phase
two
and
then
phase
three
I
was
as
a
breaking
change.
I
would
like
to
just
default
that
to
on
so,
instead
of
being
an
opt-in
experience,
it
becomes
an
opt-out
experience,
so
you
could
have
a
very
simple
pipeline.
It's
producing
a
build
artifact
and
without
making
any
other
changes
whatsoever.
C
D
Okay,
let
me
let
me
write
this
stuff
in
the
agenda.
Real
quick
I
do
have
something
I
want
to
say,
but
I
want
to
make
sure
that
I
could
sit
in
them.
B
So
the
thing
about
this
being
on
by
default
and
getting
it
magical
and
all
that
it
needs
to
be
truly
magical.
So
if
it's
just
a
file,
they'll
tell
it
to
a
default
that
my
own,
like
I,
don't
have
the
power
and
you
want
to
autopilot
to
it.
B
That's
that's
the
gonna
be
problematic
in
some
cases.
So
if
you
want
to
have
that
your
provenance
file,
that's
gonna,
sign
up
and
that's
gonna
show
up
in
the
UI.
It
needs
to
be
separate
from
my
own
artifacts,
so
it
needs
to
be
opposed
to
a
step
at
a
standpoint.
It
needs
to
be
completely
separate
from
my
own
files.
B
A
Because
doing
the
signing
itself
doesn't
hurt
anything
I
think
what
I'm
hearing
everyone
say
is.
The
problem
is
that
publishing
the
signature
as
a
build
artifact
could
potentially
cause
problems
or
confusion
or
get
in
the
way
of
other
things.
B
A
B
I
I
mean
that's,
that's
not
my
decision
to
make,
but
as
a
user
of
that
and
what
I've
seen
from
our
huge
users,
who
I
mean,
have
huge
CI
Farms,
where
every
single
Cent
is
accounted
for
and
they
won't
optimize
as
much
as
they
want
to.
This
is
gonna,
be
very,
very
bad
for
them
and
they
need
to
be
a
hundred
percent.
Aware
of
whether
you
know
this
is
gonna
happen
for
them.
So
everybody
needs
to
know
that
they
need
to
opt
out
of
that
before
we
make
it
automatically
on.
C
And
that's
kind
of
what
I
was
going
back
to
my
point
above
about
the
research
I
think
we
need
to
survey
a
lot
of
these
large
Enterprise
customers
that
have
all
these
very
complex
workflows,
because
the
Georgie's
point,
the
conversations
we
get
pulled
into
about
making
pipelines
go
efficient,
reducing
costs
developers
to
run
away,
not
breaking
workflows.
You
introduce
something
that's
on
by
default
in
someone's
regular
I,
don't
know
test
pipeline.
Are
you
signing
a
bunch
of
artifacts
every
hour
every
day
it
could
become
very
problematic?
C
A
So
I'm
hearing
all
the
concerns
here
as
well
around
on
by
default.
Are
there
any
concerns
with
developing
this
in
an
off
by
default,
opt-in
experience
for
now-
and
you
know
we
can
always
figure
out
when
or
if
we
deprecate
it
or
change
it
to
an
on
by
default
later,
but
are
you
okay
with
us
proceeding
with
making
this
off
by
default
and
opt-in,
essentially
that
phase
two?
Where,
if
you
set
a
variable
to
true,
then
all
of
this
happens
and
if
you
don't,
then
you
know
nothing
changes
from
what
happens
today.
C
To
answer
that
question:
what,
besides,
the
attestation
feature
that
we
added
some
months
back
to
wrap
up
this
next
piece
of
the
feature?
What
actually
required?
What
are
we
thinking
is
actually
required
to
be
added
to
the
runner
if
anything,
Brandy
now.
D
Sorry
I
was
writing
the
agenda.
What
was
the
question.
C
In
order
to
finish
this
next
piece
of
the
picture
sort
of
the
Native
signing,
is
there
any
additional
features
or
capabilities
required
in
the
Runner
code
base?
To
finalize
this
feature,.
D
Yes,
so
the
main
thing
that
I'm
not
sure
about
is,
we
would
have
to
actually
run
cosine
to
you
know,
sign
these
artifacts
and
I'm,
not
sure
if
there's
a
good
way
for
the
runner
to
like
invoke
an
external
program
like
that.
C
So,
in
order
to
sign
the
artifact
at
some
point
in
the
artifact
generation
process,
you're
going
to
be
looking
to
instruct
the
runner
to
reach
out
to
this
cosine
process
in
order
to
design.
So
where
would
cosine
be
well,
this
cosine
going
to
be
bundle?
Somehow?
Is
the
customer
expecting
tactical
sign
already
pre-installed.
D
Yeah,
that's
that's
something
that
I
haven't
figured
out
yet
and
it's.
D
That
might
not
be
a
kind
of
usage
that
the
cosine
team
expects
us
to
be
doing.
So
they
may
not
be
able
to
support
that
and
they
might
ship
breaking
changes
to
it
all
the
time.
We're
not
sure
so,
I
think
I
think
we
should
probably
reach
out
to
fix
door
and
see
what
they
think
of
that.
D
C
Within
the
runner
somehow
or
the
application
on
the
process,
is
you
know
somewhere
in
the
environment?
You
any
concerns
from
your
own
about
this
last
piece.
B
I
actually
have
a
bunch
of
concerns
related
to
a
proposal,
so
the
distribution
itself,
I'm
gonna,
leave
that
for
a
while,
because
I
want
to
talk
about
a
couple
other
things.
B
So
there's
this
sentence
in
The
Proposal.
All
signing
must
be
done
in
code
outside
the
reach
of
the
job.
So
I
saw
something
proposed
with
the
words
on
internal
Runner
job,
which
is
not
a
concept
that
exists
currently.
B
So
any
signing
that
happens
in
the
job
happens
in
the
job.
There's
no
outside
the
job,
Runner
runs
jobs.
So
if
I
have
access
to
the
infrastructure,
I
have
access
to
the
jobs
that
generate
this
artifacts.
B
So
if
I'm,
like
a
regular
developer
of
this
company
and
I
just
run
CI
workloads
and
I,
somehow
artifacts
are
generated
and
somehow
they're
signed,
there's
a
very,
very
high
chance
that
I
can
insert
myself
in
that
process
and
we
as
guitar
and
guitar
pronuncially,
there's
nothing.
We
can
do
if
we
wanna
have
the
generation
to
happen
by
the
top
Runner
it
can
happen.
B
Somehow,
maybe
let's
say
let's
say
you
need
to
have
a
separate
infrastructure
that
runs
separate
card
workloads
where
only
you
know
signing
happens
and
we
transfer
artifacts
to
there
and
then
transfer
the
you
know
the
signatures
back
and
then
we
transfer
that
to
GitHub
I
mean
it
could
happen,
but
I,
don't
think
that's
what
anybody
wants
and
the
next
one
is
very
much
similar.
B
It
is
the
token
used
to
generate
the
signing.
Key
must
only
be
possible
to
generate
with
the
correct
links
when
generated
by
guitar.
B
So
once
again
we
talked
about
this
was
time
and
can
generate
something
chances
are
I
can
do
it
manually
as
well.
If
the
top
Runner
takes
on
the
identity
of
you
know,
for
example,
takes
on
data
OS
identity
of
the
CI
machine,
it's
you
there.
B
I
can
do
that
manually,
though
it's
not
doing
it
in
any
sort
of
way.
I
can
interpret
it.
So
I,
don't
think
that's
possible,
and
here
I
I
want
to
ask
you.
Why
do
we
want
the
runner
to
do
this?
Is
it
because
it
yeah
thing
and
we
just
default
to
GitHub
Runner?
C
Oh
yeah,
it
goes
back
to
that
debate.
I
was
having
in
a
call.
I
was
with
with
I
forget.
It
was
the
six
door,
folks
or
whomever,
and
this
whole
idea
that
they
have
that
I
can
get
the
tune
they're
using
but
being
able
to
trace
the
entire
build
process
and
I
I
was
disagreeing
with
them
that
they're
putting
all
of
this
on
the
build
agent
Georgie.
If
you
were
to
do
this,
where
would
you
create
a
whole
new
service
that
that
is
taking
care
of
the
signing.
B
Yeah
I
I
think
it
100
needs
to
be
a
separate.
It's
going
to
be
a
micro
service,
he's
gonna
be
inside
the
back
end.
I,
don't
know
it
doesn't
really
matter,
but
this
is
not
something
that
you
do
on
the
user's
machine
which
we
are
doing
so
if
I
want
to
generate
another
example,
if
I
want
to
take
this
token
from
the
back
end-
and
we
really
want
this
token
to
be
unique
and
not
be
used
by
anybody.
B
But
if
I
just
run
this,
if
I
run
this
web
request
to
get
this
token
for
GitHub
runner
from
the
back
end
in
a
network
where
I
can
skip
the
network
in
some
way
or
another,
I
can
get
this
token
again
there.
There
are
a
bunch
of
ways
that
this
can
be
compromised
and
again
even
opposing
the
artifact
to
the
back
end.
B
We
need
to
make
sure
that
the
correct
art
Factor
uploaded
again
I
can
compromise
that
as
well,
but
that
leaves
many
many
less
vectors
where
I
can
approach
this
and
compromise
the
whole
process.
I,
don't
need
to
think
about.
Is
the
coastline
binary
correct
because
to
me
again
as
a
TI
user
I
can
replace
the
binary
I
don't
need
to
think
about
where
the
network
is
particularly
secure.
I
don't
need
to
think
about
the
token
I.
B
D
A
D
Discussion,
that
is,
it
requires
a
lot
of
thought
and
it's
not
really
something
that
we
can
address
on
this
call,
but
I
think
it
would
be
great
if
you
could
write
your
concerns
down
like
in
an
issue,
and
then
we
can
see
think
about
some
ways
that
we
can
address
them
and
do
some
threat
modeling,
maybe
pull
in
the
app
stick
team
if
they
can
help
and
I
think
I
think
we
can
think
through
that
and
figure
out
a
way
to
address
those
problems.
B
Yeah,
this
definitely
needs
to
be
a
bigger
discussion.
I
just
I
went
through
a
proposal
before
the
meeting
and
I
I
bet
I
had
the
same
concern
before
we
started
doing
any
of
this
and
I.
Don't
think
that
making
the
automatic
call
sign
exposure
of
the
you
know
the
environment,
but
I
was
making
that
so
automatic
I.
Don't
think
that
helped
with
any
of
this
concerns,
it's
just
easier.
You
know
before
before.
We
couldn't
really
do
it
now.
Now
we
can,
but
that
doesn't
make
it
any
more
secure
or
anything
like
that.
D
Yeah,
but
one
one
thing
that
comes
to
mind
is
you
know,
we're
probably
gonna
have
the
runner
identity
like
embedded
in
signature,
and
it's
like
each
user
is
gonna
like
determine
your
manifest
that
they
designate
to
a
specific
parameter
so
like
get
their
posted
runners
are
probably
are
something
you
could
probably
be
considered
trusted.
You
know
you
you
can
most
people
are
going
to
consider
our
Network
secure
and
like
we
have
controls
to
keep
people
from
accessing
those
production
Runners
right
so
generally,
if
a
runner
is
hosted
back
gate
lab.
B
We
we
don't
really
have
the
concept
of
GitHub
Runner
identity
right
now.
What's
that
gonna
be
where
that
don't
come
from,
but
presumably
that's
all
to
not
something
that
installed.
B
If,
if
we
figure
out
that
concept,
we
talked
about
a
user
identity
be
injected
into
learning.
We
talked
about
the
machine
identity
injected
from
the
runner.
B
In
the
end
of
the
day,
I,
don't
particularly
believe
that
the
runner
is
always
going
to
be
100
source
of
Truth.
So
if
you
sign
an
artifact,
I'm,
not
really
sure
again,
I'm
not
really
into
this
space,
so
much
or
I've
read
or
some
readmissions,
some
blog
posts,
so
I'm
I'm,
not
particularly
sure
but
I
I,
wouldn't
put
my
trust
in
in
the
runner
always
being
100
Dave.
It
was
being
reported
in
the
generated
station,
regardless
of
how
we
choose
to
you
know,
generate
these
applications
to
get.
D
All
right
do
you
want
to
say
thank
you
for
asking
the
type
question
and
sending
a
high
bar,
because
I
do
want
to
make
sure
that
whatever
we
build
is
able
to
stand
up
to
scrutiny.
So
thanks
for
keeping
us
accountable
for
that.
D
A
Know
we're
we're
pretty
well
past
time
here.
I
just
want
to
make
sure
I
got
all
the
summary
takeaways
and
action
items
and
that
we're
in
agreement
on
them.
So
I've
got
three
down
here
so
Darren,
it
sounds
like
you
and
I
are
aligned
on
a
product
perspective
that
we
need
more
research
before
we
talk
about
moving
to
phase
three
of
an
on
by
default
experience,
but
it
sounds
like
you're,
okay,
with
moving
forward
with
phase
two
which
is
off
by
default
and
opt-in.
Yes,.
C
No
because
I
think
the
architecture
needs
to
be
hunted
out.
I
think
we're
not
on
the
same
page
in
terms
of
How
It's,
actually
going
to
be
implemented.
A
Okay,
so
I
we're
not
aligned
on.
We
don't
have
a
architecture
solution,
but
I
think
are
we
aligned
on
the
product
problems
to
be
solved
of
like?
Are
we
okay
with
moving
forward
with
that?
From
like
a
problem
solution
perspective,
we
just
need
to
figure
out
the
solution.
C
So
the
missing
piece
is
right:
now
we
don't
have
the
signing
right
we
kept
signing
today,
someone
could
sign
using
cosine
in
the
pipeline,
but
we
want
to
do
better.
Signing
correct,
correct
and
I
think
how
we,
how
we
do
that
needs
to
be
defined.
Yes,
that's
the
area.
That's
right.
Now
there
is
a
I
can
I'm,
not
we
haven't
even
had
we
haven't
even
brought
in
the
runner
staff
engineers
and
some
of
the
other
Engineers
into
the
conversation
and
I
can
I
I
can
imagine
they
will
also
have
similar
concerns
to
Georgie
and
they'll.
C
A
D
A
We
need
to
work
out
what
the
solution
is,
and
then
we
also
need
to
work
with
cosine
to
figure
out
again
what
that
architecture
is,
and
then
we
need
to
review
the
security
concerns
and
do
some
exploration
there.
C
D
We
haven't
really
been
working
on
it.
I
thought
it
was
gonna,
be
kind
of
straightforward
and
we
wouldn't
need
one.
But
after
the
discussion
today
it
sounds
like
we
probably
will
so.
D
I'll
start
I'll
start
exploring.
You
know
how
we
can
possibly
solve
the
issue
and
I'll
write
something
up
depending
on
how
complex
it
seems.
You
know,
and
we
might
be
able
to
summarize
it
in
issue
description
and
then
maybe
we
don't
need
a
whole
blueprint
but
I'll
see
and
we
can
discuss
it.