►
From YouTube: Sync on Signing with GitLab
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,
so
this
meeting
is
a
chance
for
us
to
sync
up
and
talk
about
our
plans
for
signing
artifacts
within
the
gitlab
runner,
and
we've
had
a
lot
of
discussion
back
and
forth
in
slack,
as
well
as
on
the
Epic
and
the
issue.
A
So,
given
the
nature
of
the
back
and
forth,
I
thought
it'd
be
good
for
us
to
all
get
together
and
just
level
set
around
what
our
current
thinking
is,
what
our
plans
are,
and
at
least
on
my
end,
the
most
important
thing
is
I
just
want
to
make
sure
that
whatever
we
design
is
going
to
work
for
to
allow
us
to
also
be
able
to
sign
containers
and
packages,
because,
even
though,
like
the
current
issue
and
epic
that
we
have
open
focuses
on
build
artifacts,
eventually,
we
want
to
be
able
to
sign
everything.
A
Not
just
that,
and
so
I
want
to
make
sure
that
you
know
that
is
the
right
place
for
us
to
start,
and
you
know
I
just
want
to
make
sure
that
we'll
be
able
to
easily
extend
support
out
to
those
other
types
of
artifacts.
You
know
signing
containers
and
packages
rather
than
just
build
artifacts
themselves,
but
yeah
that
I
guess
it's
mostly
a
question
to
the
engineers
but
I'll
open
it
up
for
discussion.
B
Hey,
so
I've
got
like
a
ton
of
notes,
and
this
is
actually
my
my
first
question,
my
first
wine
in
the
notes,
because
I
read
through
your
comments
in
swac
about
like
how
we
want
to
support
the
for
Multiplex,
all
the
other
things
like
packages
and
Docker
images,
and
with
that
in
mind,
I'm
not
sure
we
can
have
signing
in
the
runner
like.
If
you
want
to
build
Docker
images,
do
we
want
to
force
you
to
use
some
helper
function
to
build
images?
B
What
about
packages
artifacts
are
easy.
We
we
transparently
support
them
right
now,
but
that's
not
the
case
for
packages
or
Docker
images
or
whatever
else.
C
Yeah
I,
like
I
I,
think
the
same
thing
I
I
was
considering
in
my
head
like
how
we
could
possibly
do
it
natively.
If
we
wanted
to
go
that
path
and
I.
Think
like
it's
theoretically
possible
that
we
could
extend
the
cim
will
syntax
to
have
like
a
native
awareness
of
various
artifact
types
right.
So
like
I
was
thinking
like,
for
example,
you
know
doctor
build
allows
you
to
write
to
a
a
tar
ball
right,
npm
build
like
creating
an
npm
package.
C
You
can
write
that
to
a
tarball
right,
so
we
could
instruct
users
to
do
that
in
their
build
process,
output
them
as
artifacts
and
have
CI
syntax.
That
would
allow
allow
the
user
to
specify
hey.
This
is
the
path
to
my
tarball
that
contains
a
Docker
image,
and
this
is
the
registry
and
tag
that
I
want
the
runner
to
to
push
that
image
to
as
well
as
perform
signing
and
and
whatnot
at
the
same
time.
But
I
I
don't
see
a
ton
of
value
in
in
doing
it
that
way,
I
think
it.
C
It
adds
complexity
to
the
build
because,
rather
than
doing
what
you
do
on
an
ACI
platform
in
terms
of
Docker,
build
Docker
push,
you
now
have
to
modify
the
build
steps
to
be
platform
specific
and
and
interact
with
our
runner
specifically,
and
even
if
we
did
do
all
that,
I
I
think
just
the
whole
configuration
would
be
more
verbose
for
the
end
user
than
just
doing
it.
The
way
you
would
natively
with
all
these
tools.
D
Cosine,
you,
you
say:
I
want
to
sign
this
image
at
this.
You
know
registry.
You
know
URL
whatever
right
like
in
theory,
we
could
point,
you
know
we
could
have
a
URL.
That
said,
you
know
natively
just
sign
that
container
image
as
well
right,
but
you
would
have
to
add
a
lot
of
logic
to
download
a
Docker
image
and
sign
that
right
is
that
what
you're
is
you're
thinking
here
that
that
you,
you
add
more
complexity
with
every
package.
You
need
to
support,
because
you
now
need
to
add
that
to
the
runner
yeah
exactly.
C
And
it's
like:
where
do
you?
Where
do
you
stop
right?
If
we're
adding
like
package
manager,
API
specific
implementations
for
signing
like
what's
the
difference
between
that
and
and
and
building
the
package
to
begin
with
right,
like
The
Logical
conclusion
of
this
is,
like
you
know,
should
we
enable
should
we
teach
the
runner
how
to
both
build
and
sign
an
npm
package
and
build
and
sign
a
Docker
image
and
I
think
the
answer
is
like
obviously,
no.
C
B
That's
that's
a
very
good
point:
I
I
guess
I
mean
some
can
answer
to
that,
but
we
mostly
wanted
it
to
be
very
easy
simply
because
nobody
else
is
doing
it
the
easy
way.
So
we
wanted
to
take
all
that
burden
away
from
the
user,
but
yeah
after
all,
building
and
signing
current
that
much
different.
So
why
take
away
the
power
from
one
but
leave
it
for
the
other.
C
C
C
D
So
when
these
other
packet
managers
like
npm
at
the
end
of
the
day,
how
is
npm
doing
it
differently
from
like
you
know,
you
know,
let's
say
we
produce
a
DOT,
you
know
whatever
npm
or
whatever.
It
is
how's
that
how's
the
signing
different
from
you
know.
If
we
had
our
own
native
thing,
just
add
a
signature
to
it.
How's
that
how's,
the
npn
signature,
different
yeah.
C
So
in
npm
hasn't
implemented
it
yet,
but
it's
going
to
be
baked
into
the
to
the
CLI
client,
so
so
they
they
are
actually
building
six
store,
JS
like
a
JS
library
for
Sig
store
first
and
then
they're
leveraging
that
library
in
the
npm
client
to
do
signing
as
part
of
the
publish.
So
it's
all
it's
all
going
to
be
embedded
and
both
client-side
and
server
side
and
things
going
to
have
a
native
awareness
of
of
of
these
signatures.
C
I
think,
like
the
us
us
having
any
signing
on
by
default
for
the
case
of
like
a
npm
package,
it
would
first
require
that
the
user,
like
writes
the
package
to
its
Hardball,
that
gets
uploaded
as
an
artifact
to
our
system
for
no
reason
other
for
it
than
it
for
other
than
for
it
to
be
signed
right.
But
that's
completely
separate
from
the
workflow
of
actually
publishing
the
npm
package.
B
Yeah
now
it's
npm,
then
it's
going
to
be
I,
don't
know
what
else.
Maybe
Dockers
gonna
add
that
at
some
point
as
well
that
that's
gonna
make
total
sense.
E
A
B
Yeah
I
would
say:
do
it
the
same
way?
Github
is
doing
it
they're
just
giving
us
I,
don't
even
know
if
these
sections
are
actually
official,
but
they
GitHub
and
cosine
have
a
mutual
understanding.
So
if
GitHub
exposes
a
couple
environment
variables
and
you
run
the
sign
command
and
these
variables
are
accessible
by
cosine,
it's
automatically
going
to
use
the
Json
web
token
and
sign
the
artifact.
B
So
all
you
have
to
do
is
use
the
action
where
you
say
cosine
sine
something
and
that's
it.
C
Yeah
and
and
I
think
forgive
me
I,
don't
know
how
to
pronounce
your
first
name.
Is
it
Georgie
yeah?
That's.
B
C
C
They'll,
probably
still
be
first
party
but
like
pushing
it
all
into
user
land
where
we
don't
have
to
like
support
everything.
As
it's
announced
right
like
allow
users,
the
ability
to
create
these
shareable
configurations
for
various
package
managers
and
various
types
of
artifacts
that
need
to
be
signed
and
I.
C
Think
that,
like
the
pipeline
CI
pipeline
components,
proposal
is
the
closest
thing
I've
seen
for
us
to
be
able
to
provide
similar
functionality
to
what
GitHub
does
and
other
CI
providers,
because,
like
my
take,
for
example,
is
that,
like
I
mentioned
this
to
Stan
the
other
day,
it's
like
I.
Don't
even
think
that,
like
the
uploading
of
artifacts
needs
to
be
built
into
the
runner
right
like
it,
that
that's
that's,
just
an
API
call
right
and
so
I
don't
like.
It
would
make
more
sense
to
me.
C
If
we
had
like
a
first
party
step,
that
you
could
append
to
the
end
of
a
of
a
CI
job
right
that
took
artifacts
at
this
path
and
uploaded
them
to
our
artifacts
upload,
endpoint
right
I
think
we
have
a
ton
of
behaviors
that
are
embedded
into
the
runner.
E
E
B
Yeah
but
GitHub
doesn't
actually
provide
us
anything
specific
for
packet
measures
and
all
that
all
they
provide
I
and
that's
not
an
official
is
an
action
to
install
cosine
and
then
you
have
to
run
the
commands
manually,
so
they
don't
provide
you
with
anything.
All
they
provide
is
the
way
to
get
the
Json
web
token.
The
the
open
ID
connect.
Token.
That's
that's
how
they
provide
in
that
scaffold
with
cosine,
but
it's
limited
to
that.
C
Yeah
the
have
you
seen
the
sorry
hang
on
I'm
trying
to
grab
a
link
here.
D
D
It
says
they
just
run
cosine,
but
the
magic
happens
because
they
have
two
environment
variables
that
are
set
during
this
process
is
one
of
which
is
like
the
the
URL
to
go
fetch
the
token
and
then
I
think
it's
the
the
GitHub
build
token
that
they're
exchanging
for
the
open
ID
connect
token,
and
so
this
happens
kind
of
transparently
cosine's,
like
oh
okay,
I,
see
these
environment
variables,
I'm
going
to
go,
go
get
this
token
I'm
going
to
go,
sign
it
and
then
I'm
gonna,
you
know,
do
all
the
things
I
need
to
do
to
prove
that
I've
signed
it
and
then
the
last
steps
on
this
yaml
this
recourse
stuff
is
basically
the
verifications
like
hey
I've,
you've
signed
this
thing.
D
D
A
case
being
made
just
to
make
this
easier
and
to
make
gitlab,
you
know
work
with
cosine
in
you
know,
just
out
of
the
box.
I
think
that's
that's
one
of
the
main
requirements
here.
Just
like
make
it
much
easier.
I
think
the
initial
push
was
to
make
it
completely
kind
of
transparent,
but
maybe
the
first
step
is
just
make
it
easier
to
use
cosine
because
right
now
it's
a
real
pain.
You
have
to
either
configure
a
private
key,
which
I
think
we
didn't
like
openid
doesn't
quite
work.
D
I
think
there
was
one
proposal
on
that
issue
about
using
an
open,
ID,
secret
and
client
secret,
and
you
know
that's
another
way
to
go
about
it,
but
you
would
still
have
to
keep
that
client
secret
for
that
Runner.
So
that's
another
problem
and
the
way
GitHub
is
working
right
now
is
it's
it's
saying:
well,
the
job
is
really
what
I
want
to
authenticate.
I,
don't
want
to
care,
I,
don't
care
about
the
runner,
the
runner
itself.
D
You
could
have
100
Runners,
they
may
be
ephemeral,
they
may
go
away,
but
I
really
care
that
this
job
defines
the
process
by
which
I
built
and
signed
the
artifact.
So
when
it
goes
and
it
gets
the
there's
like
a
ref
job
ref.
It's
basically
like
a
link
to
you
know
this
action
at
this
command.
Id,
so
I
can
prove
it.
This
was
built.
So
that's
the
way.
D
They
do
it
right
now
or
you
do
you
know
we,
you
know
our
GitHub
cim
was
a
little
bit
different
in
the
sense
that
you
can
include
other
CIA
animals
and
then
you
might
have
to
like.
If
you
really
wanted
to
say
this
is
the
job
that
actually
did
this
thing.
You
would
have
to
kind
of
bundle
all
that
together,
it's
doable,
but
maybe
the
first
step
here
is
just
mid.
Cosine
do
everything
we
can
to
make
cosine
just
work
really
easily
with
gitlab,
and
then
we
can
think
about.
B
Right,
yeah,
I,
completely
agree
with
you,
Stan
and
another
important
thing
you
touched
upon
is
the
identity
of
whoever
whatever
signed
the
beauty,
artifact,
that's
something
we
talked
about
a
few
times
in
the
issue.
B
The
I
I
think
the
idea
of
signing
an
artifact
or
whatever
is
just
to
prove
that
it
was
signed
somewhere
on
some
specific
place,
for
example,
a
build
job
and
note
that
it
was
signed
by
something
specific
or
that
it
can
be
reproduced.
So
essentially,
if
I
am
a
bad
actor
and
I
gain
access
to
your
CI.
Yes,
of
course,
I
can
generate
assigned
artifacts,
but
I
mean
that's,
that's
okay,
because
at
some
point
this
has
to
has
to
come
from
somewhere
all
these
tokens
they
have
to
be
accessed
from
somewhere.
B
So
having
the
the
build
as
the
issuer
of
these
artifacts
I
think
that's
completely
fine.
A
C
So
I
I
think
it's
more
related
to
to
like
what
what
Stan
was
saying
like
really.
What
you're
trying
to
prove
is
that
the
artifact
was
produced
with
a
known
like
trusted,
Builder
workflow
right,
so
that,
like
the
it
like,
the
the
build
process
itself
is
immutable
even
from
like
a
project.
C
Maintainer's
perspective
right
because,
like
a
malicious
actor
like
the
whole
point,
is
that,
like
a
malicious
actor,
it
doesn't
matter
what
level
of
control
they
have
over
your
repository
per
se
like,
even
even
if
they
are
able
to
trigger
a
CI
job
and
build
some
artifact.
The
artifact
was
still
produced
using
this
external
build
process
which
generates
the
the
provenance
metadata
and
signs
it
and
everything
right
so.
C
I
I
think
that
avoids
the
problem
that
you're
getting
at,
because
certainly
you
can
introduce
like
malicious
code
right
to
to
the
project.
But
but
the
point
is
that,
like
a
build
process,
itself
is
immutable
and
and
you're
cryptographically
you're,
making
it
cryptographically
verifiable.
But
that's
the
case
and
that
this
artifact
specifically
was
produced
using
that
build
process.
A
Right
I
would
just
think
that
they
could
modify.
You
know
if
you're
running
like
in
a
in
a
test
Branch
or
a
development
Branch.
You
could
modify
the
build
process
itself,
so
you
can
modify
the
steps
taken
to
do
the
build
and
then
tamper
with
the
file
itself
to
change
the
steps
that
are
published
in
the
attestation
and
then
sign
it.
A
D
What
I
would
want?
It's
all
auditable
right.
You
should
have
the
branch
that
was
made
with
that,
and
it
should
have
all
the
commit
IDs
so
that
if
they
do
produce
artifact,
you
go
back
and
say:
okay,
where
do
they
build
this
if
they
built
it
all
this
crazy
branch
that
should
not
be
I
should
not
use
this
artifact
right
right.
A
D
D
I
can't
even
say
the
word
this
map
this
this
this
file,
that
it
means
that,
like
you,
that's
that's
the
reason
why
you
don't
want
to
have
this
key
available
to
even
like
the
build
process,
because,
if
you're
able
to
go
and
muck
with
that
file,
then
then
I'll
bet
her
off
right.
That's.
D
So
this
is
why
this
is
Keith
ephemeral.
They
just
sign
it
and
they
toss
away
the
private
key
and
there's
no
way
you
can
go
and
create
this
this
file
again,
unless
you
redo
the
build
process
in
the
right
way
and.
C
This
also
like
touches
on
like
the
differences
between
like
social
level,
one
and
salsa
level,
two
two
and
three
and
and
Beyond
like
I,
don't
think
it's
also
level
one
requires
that
your
build
process
and
Providence
generation
be
externalized
in
the
same
way
that
salsa
level
two
and
three
yeah
right
so
I
think
Sam
in
in
the
use
case,
you're
laying
out
like
you're
talking
about
like
a
maintainer
hijacking,
maintainer
access
to
a
project
and
then
modifying
the
build
process
within
within
that
project
right
in
campaign
that
level
well.
C
Yeah
yeah,
but
but
like
if,
if
you're
built,
if
you're
relying
on
like
trusted
first
party
or
third-party,
build
process
right
it
it.
It
doesn't
matter
anymore
because,
like
as
a
consumer
of
that
package,
all
I
care
about
is
that
I
can
verify
that
this
artifact
was
built
using
this
build
process
that
I
trust
over
here
right.
So
it
doesn't
really
matter
what
the
user
is
doing
in
their
particular
project.
Right
because,
like
I,
I
trust
the
build
process
and.
D
C
D
Yeah,
if
they
could,
if
they
can
generate
their
own
like
manifest
file
and
just
say
hey,
this
was
actually
the
the
main
branch
right.
Then
then,
you
have
a
problem
here
right
like
that's.
That's
the
problem
with
having
these
secret
keys.
That
can
you
know
if
you
happen
to
get
access
to
that
secret.
Key
I
can
generate
like
oh.
This
is
now
the
main
I've
just
faked
my
binary
to
look
like
the
main
binary,
the
main
you
know,
Branch
or
whatever
right
right.
A
So
my
concern
was
my
concern
would
be
to
make
sure
that,
in
that
scenario,
that
someone
was
not
I
mean
I
know
we're
using
an
ephemeral
key.
But
if
the
process
for
creating
the
key
isn't
private
enough,
you
know
if,
if
that
malicious
build
process
or
whatever
is
able
to
go,
generate
a
new
ephemeral
key
signed
their
tampered,
you
know
attestation,
then
you
have
a
problem
as
well,
so
you,
you
have
to
make
sure
just
the
key
being
ephemeral
itself.
Isn't
enough.
D
C
I
think
the
the
keyless
signing
workflow
in
particular
bypass
is
a
lot
of
a
concern
right
because,
like
there's
certain
things
that
have
to
be
true
for
a
job
to
have
a
cig
object
or
a
t
token,
to
begin
with
right,
like
we
know
that
that
was
issued
by
gitlab
for
this
particular
job.
C
We,
we
then
rely
on
like
a
service
like
folkio,
being
able
to
verify
against
the
gitlab
server
that
this
token
is
valid
and
was
produced
by
by
git,
live
itself
right,
I
think,
there's
all
sorts
of
threat
models
that
you
need
to
concern
yourself
with,
if
you're
doing
the
key
management
yourself,
but
that's
sort
of
like
always
true
right
for
any
sort
of
for
any
sort
of
Secret,
In
Your
CI
job.
C
So
the
point
being
I
think
that's
why
we
need
to
focus
on
the
keyless
workflow,
because
that's
easy
easier
for
us
to
ensure
secure
defaults
around
than
any
of
the
like
BYO
key
type
type
stuff
right,
we'll
have
to
like
evaluate
that
much
more
thoroughly
and
provide
good
recommendations
for
folks
on
how
to
do
that.
Key
management.
C
But
that's
that's
hard!
So,
let's,
let's
just
leverage
pokio
and
do
the
keyless
finding
first.
D
Sorry
I'm
just
saying
full
screen
is
a
whole
different.
You
know,
there's
very
GitHub
oriented
right
now
right,
and
so
we
would
have
to
you
know,
they're
talking
about
having
a
job,
a
generic
job
reference
right,
because
right
now,
GitHub
has
a
very
specific
meaning
of
what
it
means
to
have
a
job
reference.
And
you
know
we
have
our
own
ideas,
and
so
they
had
that
issue
open
about
how
to
support
everybody
else.
But
it's
you
know,
it's
I,
don't
think
it's
gone
anywhere
yet.
C
Yeah
and
I've
been
in
touch
with
the
with
those
folks
and
they're,
certainly
like
open
to
collaborating
with
us
like
they
want
to
figure
out
what
works
across
local
CI
providers
as
well,
but
I
do
think
it's
it's
a
really
important
problem
to
solve,
but
that
all
CI
providers
have
the
same
either.
C
The
same
exact
claims
on
tokens
that
they
generate
or
like
things
that
can
be
easily
mapped
to
the
same
Concepts
right,
I
I
think
we're
in
a
better
position
than
most
providers
to
be
able
to
tweak
the
claims
that
we
expose
since
there's
been
a
lot
of
work
going
into
the
CI
job
jvt
stuff
lately,
but
but
I
I
think
I
think
we
could
contribute
the
necessary
changes
to
folkio
or
at
least
coordinate
with
them,
to
make
gitlab
like
a
first
party
and
that's
all
the
stuff.
C
D
A
I
know
we're
out
of
time
here,
I
just
wanna
before
we
wrap
up.
So
if
we
go
down
this
proposal
of
making
it
easier
to
use
cosine
out
of
the
box
rather
than
integrating
it
into
the
gitlab
runner,
is
there
still
a
path
forward
if
we
want
to
use
that
as
MVC
and
then
eventually
get
to
the
on
by
default?
Or
you
know
on
like?
A
Is
this
a
path
towards
where
we're
headed
in
product
or
is
this
like?
Does
this
take
us
in
a
completely
different
direction?
If
we
did
eventually
want
to
do
signing
directly
in
the
gitlab
runner
or
embed
cosign
in
the
gitlab
runner
itself,
so
that
it
just
happened,
and
you
know
if
we
did
add
support
for
you-
know
individual
package
managers
or
Docker
images,
or
something
like
that?
Is
there
a
path
towards
that
in
the
future,
or
are
these
two
totally
Divergent
paths.
D
D
C
I
think
it's
I
think
it's
spot
on
at
any
any
work
that
we
do
related
to
get
live.
Integrating
with
Tokyo
and
cosine
just
means
less
code
in
the
runner.
If
we
go
to
embed
cosine
in
the
runner,
otherwise
we
need
to
configure
and
like
parameterize
cosine
with
all
the
stuff
that
would
just
be
native
to
it.
A
Got
it
okay?
Well,
thanks
everyone
for
that
today
and
before.
D
I
think
there
are
a
few
steps
in
there.
I
don't
know
if
you
covered
it
comprehensively
yet,
but
we
can
add
to
that
epic
or
the
issue.
A
E
I
can
create
the
issues
if
let's
keep
the
boot
in
light
for
Stan,
Georgie
and
Marshall
just
make
sure
the
steps
are
in
this
dock
somewhere
right
and
then
we
can
figure
out
how
to
create
the
issues.
So
don't
worry
about
creating
issues.
Just
lay
out
the
steps
like
what
we
need
to
do
in
this
Dock
and
then
I'll.
Think
of
even
the
issues.