►
From YouTube: Research: Bypassing merge protections in 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
Hey
there,
my
name
is
austin,
I'm
a
product
designer
at
git
lab.
I
work
in
the
manage
stage
for
the
compliance
group
today.
I
wanted
to
run
you
through
some
solution.
Validation
that
I
did
to
investigate
a
proposal
that
we
came
up
with
last
fall
talk
a
little
bit
about
the
insights
that
we
had
and
what
we're
going
to
do
with
those
what
we're
going
to
do
next,
so
in
the
fall,
we
were
looking
into
this
idea
of.
A
A
The
option
you're
left
with
is
getting
the
right
administrators
into
git,
lab
dismantling
your
settings
so
that
you
can
allow
changes
to
go
through
which
is
risky
and
then
putting
those
back
once
the
change
is
in.
That's
really
your
only
workaround
that
you
could
do
unless
those
individuals
came
back,
and
so
what
we
sought
out
to
do
was
break
down
this
idea
in
a
couple
different
strategies
of
ways
to
implement
it.
A
We
looked
into
dimension
for
ui
elements.
I
won't
go
through
all
the
terrible
iterations
that
we
had,
but
we
went
all
the
way
from
like
creating
its
own
widget
on
a
different
compliance
dashboard
for
approving
these
types
of
requests,
because
essentially
we
wanted
there
to
be
some
level
of
accountability
so
two
eyes
looking
over.
This
was
what
we
kept
saying.
We
don't
want
just
one
person
to
be
able
to
have
this
power.
We
want
there
to
be
someone
to
submit
and
request
this
type
of
approval,
and
so
where
we
eventually
led
to.
A
We
had
two
scenarios
that
we
ran,
and
so
we
ended
up
calling
this
the
the
force
merge
capability,
and
so
we
had
a
scenario
for
the
software
developer
and
we
had
a
scenario
for
a
group
owner:
that's
a
role,
that's
more
specific
to
git,
lab
and
so
for
the
software
developer.
Essentially,
what
we
were
presenting
them
with
was,
let's
say:
you've
created
this
change
to
fix
a
bug
in
production
and
all
of
your
approvers
are
out
like
I
was
saying
earlier.
A
What
would
you
do
next
and
the
thing
that
we
had
presented
in
our
ui
was
essentially
a
little
message
to
them
in
the
merge
widget
container
saying
if
you
have
an
emergency
contact,
your
group
owners,
they
can
take
care
of
it
for
you.
What
we
saw
was
no
one
ever
saw
this
message.
This
might
be
because
our
merge
request,
widget
itself
is
at
least
the
merge
request.
Page
is
overloaded
with
a
lot
of
information,
so
this
one
line
was
buried.
A
The
one
person
that
did
identify
it
understood
what
it
meant,
however,
to
go
to
so
that
was
cool,
but
it
wasn't
obvious
that
this
was
value.
Add
to
the
ui,
so
what
I'm
opting
for
at
least,
is
to
not
implement
anything
from
the
developer's
point
of
view,
but
there
is
a
functionality
we
want
to
further
explore
for
the
people
that
might
be
group
owners.
So
these
are
the
people
that
you
tend
to
give
more
administrative
privilege
to
in
gitlab
they
have
more
authority
to
affect
the
settings.
A
They
tend
to
also
have
the
code
owner
responsibility
as
well,
and
so
we
were
looking
to
what
it
might
be
like
to
give
this
person
the
ability
to
take
existing,
merge
requests
and
force,
merge
them.
So,
in
our
scenario,
this
would
allow
them
to
bypass
everything,
not
just
approvals,
but
also
pipeline
status.
Protected
environments
emerge
across
approval
rules.
A
Anything
you
think
of
basically
you're
just
getting
a
ability
to
force.
This
change
right
into
production,
which
I
understand
is
a
risky
idea,
and
this
is
why
we're
going
through
so
much
solution,
validation,
because
we
don't
want
to
introduce
a
change
that
could
definitely
break
the
experience.
Put
any
applications
at
risk,
we're
just
trying
to
investigate.
How
can
we
make
this
platform
more
usable
and
flexible
for
the
people
that
use
it?
A
A
What
we
learned,
though,
was
everybody,
told
us?
This
is
a
bad
idea.
You
probably
shouldn't
do
this,
don't
make
this
easy,
but
there
were
some
really
nice
ideas
that
a
lot
of
the
candidates
presented
that
created
some
really
neat
action
items
for
going
back
and
redesigning
the
experience.
So
we
went
from
having
a
little
bit
more
of
a
experience
where,
yes,
you
see
this
button,
it's
buried
under
all
this
other
content.
So
it's
non-obvious
and
we're
trying
to
tell
you
hey.
A
You
can
force
this
change
in
if
you'd
like
to
and
we're
adding
a
little
bit
of
friction,
we
weren't
putting
much,
but
we
heard
some
pretty
creative
ideas,
and
so
what
I
ended
up
taking
on
after
that
was
how
we
could
continue
to
evolve
this,
and
so
how
it
would
look
today
in
this
proposal
is:
let's
say
you
come
in
there's
a
merge
request.
A
It's
awaiting
approvals.
You'll,
have
the
ability
to
force
merge
only
if
it's
also
passed
the
things
like
the
pipelines
and
all
your
other
rules,
so
we're
considering
scope
back
the
amount
of
ability
to
bypass
certain
protection.
So
one
thing
we
heard
most
often
was
the
approver's
blockage
is
a
human
one
that
can't
necessarily
be
automated
or
fixed
without
people,
so
that
might
be
the
most
likely
case
where
you
might
want
to
force
a
change
in,
and
so
what
would
happen
is
if
you
click
on
this,
you
then
see
hey.
A
This
might
break
your
build
and
the
new
components
introduced
here
were
100
from
our
candidates,
providing
some
really
neat
ideas.
Everyone's
said,
they
would
only
do
this
change
if
they
were
very
confident,
like
100,
confident
so
we're
thinking
about
putting
a
like
or
a
scale
in
anything,
that's
less
than
100,
confident
we
don't
recommend
doing
this.
A
We
want
our
users
to
be
confident
what
they're
doing
and
if
they're
not.
This
should
not
be
the
route
that
they
go.
Also
we're
considering
adding
a
message
space
to
document.
Why
is
this
necessary?
This
might
just
show
up
as
a
comment
in
the
thread
of
the
emerge
request,
but
an
uneditable
comment
do
one
that
would
just
at
least
be
able
to
document
who
did
this
and
why
and
then
two
can
tie
into
my
group.
A
And
lastly,
what
we
were
changing
in
the
ui
was
instead
of
just
saying,
merge.
We'd,
say
force,
merge
to
show
that
this
was
a
different
path
that
was
taken
now.
Where
are
we
at
we're
kind
of
still
in
solution
validation?
I
would
love
to
take
this
in
front
of
more
customers
or
with
more
individuals
that
might
see
a
need
for
this,
so
hey.
If
you
think
this
would
be
useful
for
your
team.
Let
me
know,
in
the
comments
feel
free
to
comment
on
this
issue.
A
We
still
need
to
go
out
and
validate
that
this
is
truly
solving
a
problem,
and
so,
since
we've
scoped
back
some
of
the
features
in
terms
of
the
ability
to
go
past
everything
we
want
to
make
sure
this
is
still
valuable
before
we
dedicate
development
time
to
it,
that's
it.
I
hope
this
was
insightful
for
you.
If
you
stuck
towards
the
end,
appreciate
hanging
around.