►
From YouTube: Security releases and confidential merge requests
Description
James and Marin discuss security release workflows, and iterations towards confidential merge requests – https://gitlab.com/groups/gitlab-org/-/epics/753
A
So
yeah
in
in
the
current
release,
we've
got
this
product
discovery
issue
around
confidential
bed
requests
and
there's
been
a
bunch
of
discussions
on
it
backs
and
forwards
and
I,
just
like
the
objective
is
really
trying
to
work
out
where
to
start
with
the
making
things
better
and
I.
Think
as
we've
been
discussing
it
on
the
cage
side,
I
seem
to
be
like
a
couple
of
those
components
to
the
problem
and
what
I
think
is
difficult
to
to
know
at
this
stage
of
unclear
to
me
is
which
are
the
most
important
problems.
A
So
it
has
to
unpack
the
different
spheres
that
we're
sort
of
seeing
is
that
there's
kind
of
one
problem
which
is
like?
How
do
we
have
like
the
security
release
branch
and
keep
that
secret
right,
because
we
need
to
keep
critical
vulnerabilities
like
the
fixes
for
them
until
they're
deployed,
which
is
what
we're
currently
doing
the
desert
get
lab
right.
So
that's
one
component
and
then
I
guess
there's
the
other
component,
which
is
kind
of
a
work
flow
related
problem,
which
is
how
do
how
do
engineers
go
from
a
security
issue?
A
That's
confidential
and
then
were
a
flow
that
into
a
fix
and
then
onto
the
security
branch
and
I.
Guess
like
the
problem
now.
Is
that
as
I
understand
it
is
that
there's
an
issue
on
one
instance,
and
then
they
go
to
a
completely
different
instance
to
fix
the
issue,
and
then
that
has
to
somehow
like
flow
back
into
the
gearlive.com
server.
A
And
so
what
we're
talking
about
is
like
well
we're
trying
to
move
away
from
that
to
serve
the
situation
as
it
is
so,
and
that
can
kind
of
be
done
already
right
like
if
we
have
gitlab
seee
and
get
labs
seeing
private,
which
is
like
a
totally
separate
project.
Okay,
the
workflows
simpler
and
then
you
still,
you
only
have
two
instances,
sorry
to
projects,
and
they
can
be
in
the
same
group
and.
B
A
A
What
are
those?
What
are
the
problems
with
that
situation,
like
confidential,
merge
request
should
solve,
because,
if
I
look
at
that
situation,
that
is
a
lot
more
better
than
the
current
situation.
And
it's
not
clear
to
me
what
the
priority
in
sight
and
what
the
specific
advantages
of
having
all
that
happen
in
one
project.
By
guys
from
one
perspective
like
I
love,
the
idea
of
just
be
able
to
say
someone
hey,
you
can
fix
your
security
issue
in
the
same
project.
A
You
just
like
from
a
confidentially
to
click
about
in
the
create
confidential
bed
request,
and
it's
all
secret
than
just
work
right.
But
then,
from
the
perspective
of
how
do
we
iterate
towards
that?
And
what's
the
most
valuable
thing
to
Seoul,
it's
very
unclear
to
me
like
what
the
most
immediate
improvement
versus
the
the
forking
nerd
request
work
for
years.
B
We've
like
we
still
don't
have
the
go-ahead
to
actually
execute
on
it
until
some
security
related
items
are
addressed,
but
like
what
kind
of
problems
we
are
having
with
and
having
to
work
with,
that,
you
workflow
that
you
just
described
having
a
fork
in
a
separate
project
in
a
separate
group.
It's
completely
private,
so
number.
One
problem
that
we
realized
right
away
is
syncing
between
repositories,
a
still
a
problematic
thing.
A
B
Name,
the
private
repository
security
see
right.
That
is
a
fork
of
public
repository,
it's
in
a
private
project
in
a
private
group,
and
only
certain
people
have
access
to
it.
So
when
you
actually
are
developing
on
this
private
project
get
Cee
the
private,
the
public
repository
is
moving
so
making
sure
that
master
branch
or
any
of
the
important
branches
you
have
is
constantly
in
sync.
You
need
to
have
a
task
that
will
automatically
sync
that
item
number.
A
Four
need
a
copy
of
master
like
can't
that
just
be
I
mean
once
you
create
a
security
branch
like
all
the
public
branches
like
they're.
The
source
of
truth
is
in
skill,
I'm
saying
so.
If
you
a
local
right-
and
you
say
all
right-
I'm
going
to
create
a
new
security
release
and
you
what
you
do,
is
you
go
and
check
out
the
touch
like
the
release?
The
public
release
version
of
like
you
label
Evans
on
a
and
then
you
push
that
Brand
X
to
the
secure
repo
like
you.
B
Now
in
this
updated
branch
that
you
couldn't
see
when
you
were
working
on
so
right,
theoretically,
just
before
the
merge
you
as
a
developer
needs
to
rebase
on
top
of
the
latest
branch,
whether
that's
master,
whether
that
security
totally
does
not
matter
for
this
discussion,
but
it
needs
to
be
the
freshest
possible
branch
from
repository
where
all
the
work
is
being
carried
out.
So
this
is
one
of
the
things
that
we
are
dealing
with
like
as
recent
as
yesterday,
when
the
latest
security
release
went
out,
is
we
had
I?
B
B
But
what
would
what
would
your
expectation
be
with
that
private
branch
versus
public
branch?
Would
that
be
automatically
sync
at
some
point
or
who
would
be
doing
the
syncing
I
think
so
assume
that
there
is
no
work
going
on
on
the
private
branch
at
the
moment
who
is
doing?
How
is
the
branch
of
a
synced
public
versus
private.
A
A
I
guess
the
other
approaches
you
could,
rather
than
so
I.
Don't
think
it
succinctly,
you
can't
you
can't
it's
not
the
same
as
a
sinking
problem,
because,
like
a
sinking
problem,
you
kind
of
design
something
emerges
here,
you
merge
it
there
and
something
goes
tea
image
at
there
and
obviously
you
can't
do
that.
It's
kind
of
like
you
have
to
keep
everything
on
this
branch.
So
I
guess,
like
the
other
way
of
looking
at
it,
is
rather
than.
A
I'm
thinking
or
a
mirroring
problem
is
once
you
merge
something
into
the
public
branch.
You
could
have
like
a
cascading
merge
where
it
triggers
a
merge
request
on
to
the
private
branch
and
then
I
kind
of
like
automatic
modes,
for
each
branch,
which
could
be
a
CI
job
right
and
as
soon
as
you
move
something
on
to
the
public
branch
and
then
like
trigger
the
CI
job,
to
merge
onto
the
private
branch
right
yeah.
But
then
I
also
think
that's
not
an
ideal
solution,
because
you've
now
got
public
friend.
A
Public
merge,
request
conflicts
because,
like
the
merge
request,
fails
and
it's
going
to
be
like
raised
like
the
role
you
have
public,
the
public,
the
volume
of
public
mentor,
question
pussified
and
programmatic
west
then
you're
putting
the
result,
responsibility
and
resolving
conflict
on
to
the
public
branch.
Yeah.
B
B
Really,
like
I
understand,
like
I,
know
how
complicated
this
problem
is.
So
maybe,
instead
of
like
looking
for
that
solution,
maybe
we
can
like
lay
out
what
would
work
for
us
in
this
in
the
situation
where
you
would
have
a
separate
project,
and
maybe
with
that,
we
would
be
able
to
more
clearly
understand
what
is
the
literal
end
with
MVC
vanilla.
So
there
are
a
couple
of
things
that
have
learned
a
new
were
important,
but
they
were
like
reiterated
as
as
super
important
right.
B
B
That
merge
request
that
gets
created
on
that
private
repository
needs
to
be
exclusively
needs
to
stay
exclusively
private
right,
like
it
can
leak
one
way
or
another,
so
whether
the
projects
are
Forks
of
one
another
or
not
that
that
matters
only
so
much
as
I.
Don't
want
anything
that
I
do
in
the
in
the
private
project.
I
don't
want
to
accidentally
have
Italy
right
now.
If
two
projects
are
in
the
fork
relationship,
when
you
create
a
merge
request,
it
will
automatically
offer
you
to
target
branch
to
be
to
the
upstream
repository
right.
B
B
Number
two
item
is:
how
do
you
ensure
that
you
don't
duplicate
issues
right?
We
have
this
move
issue
item
which
I
think
kind
of
resolves
the
problem
for
us
where,
even
if
you
create
this
in
the
private
repository,
you
can
easily
just
click
move
and
the
issue
will
be
moved
in
English,
let's
see
and
then
the
final
thing
for
us
or
the
first
one.
B
So
if
you
protect
it,
a
branch
inside
of
github
or
github
seee,
you
want
your
private
project
to
have
the
same
setting,
regardless
of
whether
it's
really
needed
or
not,
because
there
are
multiple
other
settings
approvers
or
whatever
else
you
want
to
ensure
that
that
is
a
one
on
one
relationship
and
that
there
is
no
death
between
it
that
could
cause.
You
know
someone
to
have
access
to
merge
on
this
project
that
doesn't
have
access
to
merge
on
this
public
project.
So
those
are
the
baseline
items
that
we
would
need
to
address.
A
Yeah,
so
the
ones
I
guess
I
definitely
been
thinking
a
lot
about
the
projects
having
the
same
settings.
Because
to
me
that
seems
like
a
really
big
problems
like
like,
if
you
contribute
early
CI
variables
or
your
CI
settings,
things
like
that
yep
having
to
reconfigure
that
all
over
again
I
guess
so.
The
others
as
I
was
thinking
about
that.
However,
I'm
using
your
thoughts,
it
occurred
to
me
that
that
may
in
fact
be
a
weakness
of
doing
it
all
the
same
project.
A
B
So
those
those
are
items
that
I
think
we'll
have
to
resolve
right
now
when
we
move,
if
we
move
security
development
to
github.com
and
we're
going
to
do
it
that
manually,
most
likely
I,
don't
know
we'll,
probably
not
be
able
to
do
this
in
four
settings,
but
syncing
between
branches
to
keep
them
up
to
date
and
I
probably
break
the
fork
relationship
between
the
two
projects
to
ensure
that
there
is
no
accidental.
You
know
what
if
we
made.
A
Sorry
like
what,
if
we
change
the
way
I
if
we
started
introducing
confidential
merger
questionable
structured
way
and
if
we
somehow
designated
the
downstream
project
is
being
confidential
and
therefore
like,
given
its
confidential,
restrict
or
change
the
default
mode
request
behavior.
So,
for
instance,
if
if
the
fork
was
listed
as
confidential,
only
people
with
merged
permissions
could
actually
open.
A
Something
like
would
there
be
any
situation
where
a
private
for
other
public
projects
like
where
you'd
want
just
anyone
to
be
able
to
open
a
merge
request
to
merge
thing
to
publish
I
mean
it
seems,
like
kind
of
like
a
sane
default
like
if
you've
gone
to
the
effort
of
making
a
four
that
only
the
people
who've
made.
A
private
should
be
made
able
to
make
the
stuff
public
again,
and
if
we
did
that
I
think
that
covers
like
them.
A
B
So,
let's
see
there
are
a
couple
of
cases
that
that
we
see
happen
frequently.
First
of
all,
even
if
you
have
a
stable
branch
security
branch
that
is
slower
than
master
right
like
it
only
receives
updates
for
for
security
related
items
and
it
hasn't
been
updated
from
any
of
the
faster-moving
branches.
B
You
can't
merge
the
third
one.
For
example,
if
you
have
three
the
third
one
can
be
merged
because
of
conflict,
then
you
as
a
developer
or
whoever
is
working
on
that
thing.
You
need
to
go
back
and
resolve
any
of
the
conflict
and
then
wait
for
that
green
thing
to
pass
and
then
you're,
fine
things
get
merged
and
you're
almost
done
well,
not
really
because
now,
whoever
else
is
doing.
This
release
needs
to
merge
the
stable
branch,
so
the
a
bit
faster
running
branch.
B
So
now
the
security
one
but
the
stable
one,
because
in
the
meantime,
things
moved
on
right.
So
you
merge
that
branching,
but
there
is
like
a
huge
amount
of
commits
now.
So
what
do
you
do
now?
As
a
release
manager?
You
go
and
start
pinging
each
of
the
individual
people
who
contributed
to
the
security
item
to
resolve
a
similar
or
even
the
same
problem
that
they
already
resolved
in
one
other
place,
maybe
in
the
stable
branch,
maybe
in
security
branch.
It
doesn't
matter
where?
What.
A
It
is
to
clarify
just
to
clarify
so
yeah.
What
happens
is
like
you've
got
the
public,
stable
branch,
that's
faster
moving
than
the
security
branch.
Yes,
the
security
branch,
then
you
create
a
merge,
commit
to
merge
stable
into
secure
yeah,
and
then
it's
on
the
secure
ICS
to
resolve
the
conflicts
in
animation.
B
Yes,
yes
exactly
and
what
you
actually
get
all
often
as
a
question
is:
why
couldn't
have
we
done
this
like
just
before
I
merged
it
right,
like
the
branch
was
updated,
I
resolved
all
the
conflicts
in
the
stable
branch
is
PD,
please.
This
is
now
just
me
doing
another
work,
another
piece
of
work,
so
ideally
every
time
you
merge
something
in
that
security
branch.
B
You
would
have
a
sync
job
coming
from
a
location
right,
for
example,
if
we
define
that
it's
a
stable
branch
than
a
state
right,
merge
that
and
then
whoever
is
doing
the
work
in
another
merge
request
would
no
longer
need
to
do
this
in
two
places,
because
now
they
can
resolve
the
conflicts
right
away
once
their
thing
gets
merged.
The
next
site
will
come
on
top.
You
know
and
that's
how
I
kind
of
see
it
yeah.
A
So
if
I,
just
like
either
an
octopus
merge
where
you
go
like
a
three-way
merge
where
you
go
like
stable,
like
public,
secure
like
stable,
secure
and
the
feature,
branch
and
I
do
merge
all
three
and
like
a
single,
merge
and
then
the
process
of
doing
that
actually
brings
in
two
most
recent
changes.
I
guess
the
the
other
option
would
be.
Is
that?
A
And
so
that
means
that
there's
just
like
one
isyes
job
whose
job
it
is
to
resolve,
whatever
the
difference
is
and
rather
than
resolving
it
in
like
a
monthly
like
this,
is
the
next
security
release
like
result
like
14
days
of
velocity
on
the
public,
stable
branch
yeah,
ideally
we're
resolving
like
a
couple
of
days
to
velocity
at
a
time
as
the
security
fixes
mergers
like
smaller
chunks
to
resolve.
Yes,.
B
A
A
B
To
like
point
that
out,
no
no,
there
is
no
such
thing
as
perfect
solution
in
this
case.
This
is
more
that
you
know
we
don't
have
to
go
into
a
situation
like
we
had
again
now,
where
you
know
one
of
the
release
managers
goes
and
thinks
the
person
three
times
we
have
one
person
working
on
the
most
frequent
changed
code.
Three
times
they
had
to
fix
a
conflict
first
time
when
they
were
trying
to
merge
this
thing
into
stable.
What.
A
About
a
different
approach
and
where,
as
soon
as
you
know,
change
into
stable
cherry
get
into
the
release,
Brettler
stable
public
release
branch
and
that
merges,
then
we
cherry
pick
it
onto
the
security
branch
at
the
same
time,
and
it's
that
the
IC
not
from
the
secure
branch,
the
I
see.
Who
is
cherry,
picking
the
feature
like
because
it's
currently
the
developers
job
when
it
gets
cherry,
picked
into
the
stable
branch
to
resolve
conflicts.
So
they
mentioned
to
master.
A
If
it
can't
be
cherry
pick
to
cleanly
it's
their
job
to
resolve
that
issue,
if
it
can't
be
Cherokees
cleanly
in
to
secure
shouldn't
it
also
be
that
same
person's
job.
So
it's
the
person,
who's
merging,
is
job
to
resolve
the
conflicts
in
stable
and
secure
and
in
theory
those
conflicts
should
be
kind
of
similar
right.
They
have.
B
Four
of
them,
for
example,
so
you
do
backwards
as
well.
Now
the
person
who
is
also
reviewing
this
or
needs
to
go
through
all
two
or
three
others,
and
you
know
it
amplifies
the
more
backports
you
do
do
more
of
these.
You
need
to
do
so,
for
example,
for
our
use
case.
We
have
three
back
ports
plus
master.
That
is
four
plus.
B
A
B
A
B
B
Solving
right,
it's
not
it's
not
as
simple,
but
the
point
is
for
any
of
the
requests
that
you
create.
You
have
four
things
to
think
about
and
then
imagine
you
have
worked
on
two
or
three
of
those
for
this
one
release.
It's
going
to
be
pretty
annoying
to
do
that,
all
the
time
when
you
can
resolve
the
conflict
once
and
ensure
that
which,
wherever
you
resolve
the
conflict
that
just
gets
propagated
into
whatever
you're
doing
already
and
I
know.
B
B
A
Yeah
I
wonder
if
if
we
improve
those
like,
if
we
improve
those
scripts-
and
we
also
just
automatically
so
we
automatically
open
at
the
back
ports
where
it
needed
to
happen
and
we
automatically
opened
the
security
merge
request,
I
mean
in
most
cases
like.
Hopefully,
there
aren't
conflicts
like
if
it
was
just
like
open.
The
merge
request
set
it
to
merge.
One
part
by
succeed.
B
A
A
B
A
That,
if
we
can
like
cut
out
all
that
other
manual
work,
I'm
I
generally
think
the
person
who
writes
the
code
should
fix
the
conflicts
where
the
conflicts
and
yeah
they
should
be
the
they
should
be
the
the
specialist
that
knows
how
to
resolve
the
conflicts
fastest,
rather
than
putting
it
on
the
poor
person.
That's
already
working
on
a
security
fix,
fixing
someone
else's
confidence,
so.
B
Here
is
another
thing
that
might
actually
be
more
beneficial
for
for
the
concept
of
security,
merge
request,
then
even
this
resolving
of
conflicts,
so
you're
working
in
a
public
repository
right,
like
all
of
our
engineers,
are
working
in
github,
see
II,
for
example,
your
day-to-day
workflow.
Is
you
just
automatically
push
or
you
look
in
the
Edition
at
github?
See
e,
and
now
you
need
to
start
working
on
a
branch
for
the
security
fix.
A
So
it
so
I
guess
like
if
you
create
a
if
you've
got
a
confidential
issue,
it
could
really
only
allow
you
to
create
a
merge
request
on
to
a
private
project,
be
that
your
own
personal,
private
fork
or
on
if
you've
got
write
permissions
to
the
try
that
security
projects.
You
should
really
only
offer
you
private
projects
in
order
to
create
the
branch
yeah.
B
Yeah,
exactly
and
even
possibly
like
saying
something
like:
oh
you're,
opening
your
bridge,
you're
quite
well,
I
know,
I,
don't
know,
that's
not
gonna
work
anyway.
You
know
that
one
better
not
going
there,
but
but
basically
try
to
enforce
like
make
it
super
clear
for
a
developer
that
hey
you're
working
off
a
confidential
issue.
So
your
thing
can't
be
in
this
repository.
It
needs
to
be
in
the
private
repository.
A
Yeah
I
mean
I'm
trying
to
think
through
like
what
the
dumb
work.
Why
would
be
like
if
the
dumb
work
flow
was
like
a
user
like,
has
read
and
write
access
to
the
public
Gil
MCA
and
they
also
have
write
access
to
secure,
secure,
City,
a
security
seeing
whatever
and
they
don't
have
a
private
four,
because
most
people
most
get
ladders,
don't
have
a
private
thought
that
a
public
for
forget,
lab
yeah,
okay,
assume
like
healthy
situation.
Well
like
a
typical
situation,
then
when
they
open
that
merge
request
from
secure
CA.
A
The
previous
issue
thing
we
spoke
about
was
like.
If
you're
in
a
secure
project,
don't
allow
non
maintainer
to
open,
merge,
request
on
to
public
projects.
Yep
no
requirement
should
automatically
be
fulfilled.
The
edge
case
would
be.
If
they
had
a
private
get
mad
floor,
then
they
would
end
up
in
like
the
situation
where
I
know
we
they
would
still
be
caught.
You
were
just
like
a
deep
malt
to
their
master.
A
No,
they
would
be
maintainer,
so
we
would
default
back
to
the
public
one
which
would
not
be
good,
but
maybe
we
could
put
a
warning
on
that
or
somehow
but
I
mean
that's
one
edge
case
that
we
have
to
solve
it
like
the
default
in
the
default
situation.
Where
we
tell
all
engineers
like
don't,
have
a
private
key
plaid
fork,
use
the
private
gitlab,
secure
thing
yeah
and
the
default
should
work
like
that's
serviceable
in
like
beguiling
common
use
case
in
a
short
term.
Yeah.
B
B
What,
if
you
can't
what,
if
you
have
like
when
you
had
create
that
relation
between
public
repository
and
security,
confidential,
private
repository?
What
if
you
blank
out
settings
so
it's
read-only?
Basically,
and
maybe
you
had
an
override
for
CI
variables
or
something
like
that
to
ensure
that
you
can
specify
whatever
is
necessary
for
working
with
security.
So
that
way.
A
B
Because
what
is
really
important
here,
it's
really
important,
like
probably
there's
going
to
be
a
workflow
where
you
know
you're
going
to
get
a
company
that
tells
you
well
for
the
security
part.
We
have
different
set
of
approvers
right.
So
I
need
to
be
able
to
override
all
of
this,
but
I
think
as
an
MVC
just
making
it
like
read-only
and
allowing
you
know,
override
/
CI
variable
for
build
purposes
sufficient
to
start
yeah.
A
Yeah
and
I
guess
that's
like
if
you
combine
so
there's
a
feature
in
the
backlog,
to
allow
different
approval
rules
and
different.
They
on
different
branches
because,
like
the
classic
situation,
is
like,
if
I'm
doing
a
feature
of
merging
a
feature
branch
into
a
feature
branch
like
like
a
front-end
engineers
collaborative
back-end
engineer,
and
they
want
to
like
merge
into
each
other's
branches.
They
currently
need
approval
to
do
that.
A
The
the
other,
the
other
workflow,
would
be
like
if
it's
already
made
it
onto
master
like
the
set
of
approvers
needed
to
cherry-pick
or
merge
changes
from
the
master
branch
into
a
release
branch.
It's
totally
different,
like
yep,
you
don't
need
a
maintainer
to
approve
that
you
need
a
release
manager
to
approve
that.
A
So,
if
we
had
that
sitting
down,
then
like
that
set
of
configuration
options,
that's
providing
a
nice
groundwork
for
all
these
security
branches,
which
have
different
visibility,
also
different
approvers,
which
are
security
and
release
management,
yep
cool.
This
has
been
very
helpful
and
it
sounds
like
we've
actually
got
a
lot
of
great
groundwork.
We
can
do
starting
immediately.
That's
not
implementing
this
second
repository,
which
is
like
the
hardest
from
dissolved.
It
sounds
like
that's,
probably
like
the
shiniest
and
most
like
streamlined.
A
B
Actually,
you
know
like,
while
we
were
discussing
all
of
that
stuff
before
before
our
meeting
I
realized
that
I
have
way
more
confidence
in
whatever
we
currently
have
set
up
right:
private
projects,
private
groups-
and
so
then
this
new
thing
that
has
such
a
huge
impact
that
we
don't
even
know
yet
so
I
was
thinking
like.
Why
can't
we
just
reuse
that
to
try
to
tie
those
things
together?
And
yes,
it's
not
a
proper
solution,
but
it's
definitely
something
that
will
allow
us
to
see
the
failures
in
areas
with
as
least
damage
as
possible.
Oh.
A
B
And
you
know
we
can
pair
up
quite
a
lot
on
this
like
as
soon
as
we
get
the
go-ahead
to
to
move
things
to
calm.
We
can.
We
can
stay
like
closely
in
touch
so
that
you
can
actually
see
all
of
these
things
working
out
with
us,
building
the
custom
tooling
and
trying
to
wire
things
together,
and
maybe
you
finding
an
entry
there
to
implement
something
for
us.