►
Description
Meeting notes: https://docs.google.com/document/d/1ttqkcYPmYZyqvtkaHs92bx2UeVUiXDhuzP-0WbP11Fw/edit#heading=h.7o2ubzl5z39r
A
B
B
A
Pretty
sure
I
can
still
draw
the
country
that
that's
what
you're
taught
in
in
geography
class,
so
that's
yeah
I
actually
got
to
see
Notre
Dame
one
last
time
before
it
burnt
recently,
and
that
was
so
sad
I
didn't
make
it
up
onto
the
roof
this
time
because
I
don't
know
if
you've
been
to
I
I.
Imagine
you've
probably
been
there
before
more
recently
than
me,
but
the
the
lines
in
Paris
these
days
to
see
all
the
sights
are
just
insane.
It's
don't.
B
A
A
B
C
B
Right,
so
let
me
try
to
recap
where
we
were
last
time
and
what
we
have
discussed
last
week,
Tuesday
and
last
week,
Thursday
so
first
thing
there
is
this
doodle
ongoing
to
change
the
time
slot
to
make
it
more
friendly
for
the
U.S
West
Coast,
but
there
are
a
few
peoples
only
that
participated
so
far,
I'm
going
to
share
again
the
link
in
the
chat.
So
please,
if
you
haven't,
voted
yet
vote
on
a
time
that
is
maybe
more
convenient
for
you.
Let
me
search
for
us
where's
the
chat
here
all.
B
C
B
Second
thing
is,
as
I
mentioned
during
last
week's
meeting
on
Thursday
and
Tuesday
kind
of
we
came
up
with
this
table
to
better
structure.
The
different
threads
and
I
started,
basically
putting
all
the
existing
content
in
these
tables,
and
let
me
share
the
link
to
the
document,
because
otherwise
you
you
don't
have
any
clue
what
I'm
talking
about
so.
B
There
are
a
few
few
bullet
items
missing
right
and
then
I,
basically
other
than
that
I.
Why
kind
of
consolidating
and
writing
and
the
stuff
I
came
up
with
a
couple
of
questions,
but
maybe
being
or
and
SAS
I,
just
or
all
of
you?
In
fact
you
haven't,
you
haven't
participated
in
the
past
if
I'm
not
mistaken,
so
what
we
basically
do
is
we
try
to
go
through
the
different
systems
of
what
we
assume
a
typical
development
environment,
of
a
large-scale
development
organization,
then
system
by
System.
B
We
try
to
come
up
with
a
list
of
threats
to
the
Integrity
and
the
confidentiality
of
the
software
that
is
developed
by
this
development
organization
and
those
threads
can
be
exercised
by,
for
example,
malicious,
open
source
packages
being
downloaded
to
the
different
systems
as
part
of
the
development
life
cycle,
or
could
also
be
due
to
malicious
actors
and
malware.
Otherwise
entering
the
network
and
the
premises
of
that
development
organization.
C
I
glanced
through
these
document,
so
one
thing
I
think
we
can
add-
is
the
scope
of
this
document
that
what
is
the
like
depth
and
breadth?
We
are
trying
to
cover
here,
for
example,
IC,
CI
and
CD,
and
then
we
are
publishing
the
package
inter
internal
package
repository,
but
we
are
I
mean
after
this
is.
These
are
all
left
to
Launch.
C
B
I'm
sure,
that's
let's,
let's
hope
I,
maybe
I
can
answer
a
few,
and
if
not
we
discuss
and
come
or
anyhow
we
come
to
a
common
agreement.
So
so
the
question
is
whether
kind
of
off-prem
and
on-prem
production
systems
are
in
scope
right.
So
we
we
we
so
software
that
is
running
on
premise
at
the
customer
is
out
of
scope.
So
here
we
basically
stop
at
the
upload
of
any
proprietary
artifact
on
a
distribution
platform
of
the
development
organization
and
in
question
could
be
one
that
they
own
themselves.
B
Maybe
a
download
server
operated
by
you
know
by
Acme
cop
or
it
could
be.
You
know
another
Marketplace
operated
by
somebody
onto
which
they
upload
their
artifacts.
So
and
then
this
is
where
the
customers
get
it
and
operate
it
on
premise
in
their
own
environment,
but
that
again
is
out
of
code.
What
we
thought
would
be
in
scope
is-
and
this
is
at
the
bottom
of
this
architecture-
diagram
is
basically
a
cloud
service
Services
where
the
artifact
is
deployed
in
in
the
cloud
environment
and
operated
by
the
same
organization.
C
B
Exactly
let
me
share
the
screen,
and
so
I
can
point
you
to
the
respective
sections
and
and
of
course,
whenever
you
feel
like
there's
something
requires
further
clarification.
Feel
free
to
you
know,
go
in
suggestion
mode
and
propose
something
to
the
text
right
away.
I
have
always
a
hard
time
kind
of
you
know
running
through
the
session
and
taking
the
notes
and
everything
at.
C
B
Right,
okay,
so
this
is
why-
and
we
just
did
this
last
week
or
so
we
included
that
assets
being,
let's
say,
requiring
protection,
if
you
will
is
also
system
infrastructure
configuration
that
is
used
by
that
Organization
for
any
internal
system,
including
the
customer
facing
cloud
services
if
they
have
any.
So
this
is
this
part
here
on
the
screen.
B
B
A
A
The
first
thing
that
that
came
to
mind
when
I
looked
at
this
is
I.
I
was
expecting
this
to
be
a
a
threat
model
that
that
had
to
do
with
with
open
source
and
as
opposed
to
forgive
me,
but
this
this
seems
to
primarily
talk
about
proprietary
software
as
opposed
to
and
essentially
how
to
mitigate
open
source
as
a
threat
is,
is
how
I
read
this
document,
and
so
and
I
don't
mean
that
meanly
at
all,
I
I'm
I'm,
just
looking
through
this
and
I,
see
open
source.
B
A
Red
box
to
the
right
of
that,
the
diagram
that
you're
you're
you've
drawn
I
see
a
whole
bunch
of
inputs
and
it
talks
about
the
proprietary
side
of
things
as
essentially
being
effectively
safe
and
the
open
source.
You
know
inputs
as
being
potential
threats,
and
that
has
not
been
my
experience.
It's
in
fact
been
the
proprietary
sides
of
things
where
I've
seen
the
most
threats
come
into
my
build
chain.
A
That's
that's
the
first
piece
and
I
I
apologize
that
that
seems
to
be
undermining
the
entire
point
of
this
conversation,
but
but
I
think
a
a
better
title
would
be
a
great
way
to
mitigate
that
that
lack
of
I
was
expecting
one
thing
and
found
another
I'm
I'm
by
the
way,
I'm
not
going
to
say
that
the
drawing
and
the
things
you're
talking
about
are
invalid.
They're.
Not
this.
This
fundamentally
follows
how
cloud
services
are
developed
and
put
together.
A
Certainly
in
my
experience
and
so
on
my
background.
The
second
piece
is
that
I
am
also
in
the
most
of
my
world
has
been
in
the
embedded
or
Appliance
side
of
things,
so
starting
prior
to
Cloud,
even
being
a
thing-
and
indeed
you
know,
I
was
a
part
of
a
number
of
different
groups
that
ultimately
built
a
lot
of
the
things
upon
which
of
many
of
these
things
are
now
are
now,
are
now
being
used
on
a
regular
basis.
D
A
It
goes
onto
your
Cloud
servers
and
you're
done
in
the
embedded
worlds
you
have
manufacturing,
you
have
testing
you,
have
you
have
a
whole
bunch
of
other
things
and
if
there's
all
the
beta
phases,
the
multiple
different
Hardware
versions
that
you
go
through
in
other
pieces
like
that,
so
I
guess
what
I'm
trying
to
say
is
is
that
is
that
the
the
two
pieces
are
I.
Think
this
really
has
to
be
called.
Essentially,
you
know
take
this
as
a
as
a
terrible
start
for
for
a
title,
but
basically
this
is.
A
This
should
be
called
not
so
much
threat
the
the
threat.
What
do
you
call
it
here?
The
threat?
Oh
open,
the
source,
software
Foundation
threat
models,
but
this
is
this
is
a
a
a
proprietary
development
system
that
that
has
inputs,
some
of
which
are
open
source
again
terrible
name,
but
I
think
that
that
needs
to
be
labeled
better
and
I.
I
don't
mean
this
meanly
like
I,
said
I,
think
I
think
it
if
people
are
coming
here
to
see
how
to
secure
their
open
source
software.
A
This
this
is
not
it,
but
but
but
the
second
piece
is:
is
that
I'm
not
sure
that
you're,
the
model
that
you've
described
here
essentially
is
sufficient
for
for
all
situations?
It
covers
one
I'll
be
at
a
big,
a
very
big
particular
model.
That
the
point
is,
is
that
there
are
you
know
if
you're
building
cars
or
phones,
or
televisions
or
or
you
know,
aircrafts
it's
way
more
than
this
yeah.
A
A
B
A
B
B
All
right,
okay,
so
then
let
you
do
this,
then.
Secondly,
by
no
means
I
wanted
to
to
kind
of
suggests
that
open
source
is
in
any
way
more
insecure
or
anything
that
proprietary
software,
and
maybe
this
is
in
Parts
due
to
the
Unlucky
color
code.
That
has
been
chosen
at
some
point
in
time.
It
is
reinforcing.
A
B
And
so
I
completely
agree
with
you
that
this
is
nonsense
so
many
times
just
because
of
things
being
done
in
the
open
people
actually
show
more
excellence
and
produce
more
soft,
secure
software
than
people
doing
this.
You
know
Behind
the
Walls
of
some
company
that
you
know
so
I'm
I'm,
all
with
you
here.
B
It
is
true
that
the
especially
in
the
first
few
kind
of
editions
of
this
meeting,
we
were
focusing
a
lot
more
on
how
on
particularly
these
malicious,
open
source
components
that
were
published
so
and
so
often
and
the
reason
two
three
four
years,
all
right.
It's
true,
and
so
this
is
one
kind
of
a
tech
Vector
in
order
to
you,
know
inject
malicious
stuff
onto
the
different
systems
that
you
see
on
the
diagram,
and
this
has,
and
now
this
has
been
opened
a
little
bit
also
through
to
other.
B
That
is
also
due
to
my
background,
so
I'm
I've
been
working
for
for
sap
for
many
many
many
years
and
I've
witnessed
the
shift
from
these
Enterprise
monoliths
running
on
on
premise
to
the
cloud,
and
so
this
is
kind
of
my
background,
so
I'm
lacking
experience
in
in
this
part.
So
no
it's
fine
here.
Contributions
are
welcome
to
understand
how
this
can
be
modeled.
I
think
the
challenge
always
is
how
to
put
it
all
into
one
diagram.
It's.
B
A
B
Yeah,
do
you
think
it
is,
is
it
is
possible
to
you
know,
add
a
couple
of
building
blocks
to
to
cover
this
better
or
would
you
would
you
say
that
also
the
threats
and
the
challenges
are
so
different
that
it
you
know
it
will
just
dilute
and
make
it
even
more
complex.
Then
it
is
already
now
and
so
better
not
covered.
A
A
Mexico
is
is
a
very
common
place,
at
least
for
North
American
companies
to
go.
There
are
problems
there
that
you
have
to
worry
about
surrounding
people
gaining
access
to
things.
The
security
surrounding
contract
manufacturing
there
seems
insane
precisely
because
they're
worried
about
these
kinds
of
things
and
then,
of
course,
the
when
you
start
getting
to
real
scale.
A
This
is
when
you
go
to
places
like
China
or
Taiwan
or
Vietnam,
and
things
are
very
different
again
and
so
the
the
idea
of
people
gaining
access
to
modifying
you
know,
there's
all
sorts
of
threats
at
that
that
level
you're
behind
it
essentially
firewalls
that
you,
you
really
don't
control
that
are
that
are
under
under
state
level.
You
know,
threats
and,
and
that
sort
of
thing
and
so
and
then
of
course,
once
the
machine
once
products
come
off
the
line.
A
Of
course
they
can
be
modified
before
they
make
it
back
to
you
and
so
on
and
so
forth.
So
there's
all
sorts
of
other
threats
that
that
come
up
just
through
manufacturing
alone
or
upgrades
that
that
happen
outside
of
your
control
as
well.
So
I
guess
what
I'm
trying
to
say-
and
you
know
lots
of
fun
if
you
have
to
deal
with
that
sort
of
thing
like
like
I've
seen
and
helped
with
in
the
past.
A
A
C
A
B
A
Could
maybe
just
if
it's
described
and
again
with
the
appropriate
title
and
the
appropriate
framing
such
that
that
that
that
one
talks
about
this
as
being
a
a
purely
virtual
dealing
with
with
a
virtual
end
result
or
something
that
doesn't
sound
quite
right
clouds
back
up
anyway,
you
know
what
I
mean.
The
point
is:
is
that
mitigation
in
the
words
can
certainly
help
again?
Framing
it
appropriately
is
what's
important.
A
Let
me
what's
being
described
here,
is
valuable
and,
and
certainly
I
would
I
would
argue
is,
is
as
they
as
they
say.
You
know
motherhood,
motherhood
and
apple
pie,
stuff.
None
of
this
is
rocket
science.
If
you've
been
doing
this
for
a
long
time.
The
problem
is:
is
that
a
lot
of
people
don't
do
this.
B
B
Expectations,
yeah,
no
I'm,
I'm
thankful
for
all
all
contributions
and
input
all
right,
so
I'm
not
sure
whether
you
have
I
mean
you're.
The
attending
for
the
first
time
thus
is
attending
for
the
first
time,
I'm,
not
sure
how
many
other
people
are
there,
but
these
are
the
the
ones
that
I
see
on
the
participant
list
right
now
yeah,
but
he
he
has
been
already
a
valuable
discussion
partner
in
the
past.
I.
Don't
need
to
repeat
each
other.
A
B
So
let
us
start
for
a
change,
maybe
at
the
bottom
here
so
far:
private
repositories
right
so
kind
of
company
internal
Registries,
where
artifacts
are
mirrored
for
the
consumption
by
the
internal
build
pipelines.
We
have
touched
upon
them
not
really,
but
in
the
the
process
of
the
discussions
I
noted
down
kind
of
two
early.
You
know
things
that
can
go
wrong
now
and
in
this
context,
I
wanted
to
discuss
a
few
things.
B
So
the
first
one
we
we
mentioned
then,
is
basically
because
vetting
processes,
if
any,
can
be
incomplete
or
insufficient.
So
maybe
they
don't
look
at
the
right
things
or
they
don't
look
deep
enough.
You
have
you
have
malicious
component
being
mirrored
in
your
internal
registry
and
from
there
on
it,
becomes
and
is
available
to
the
internal,
build
pipelines.
A
Be
so
I
can
speak
to
your
project
and
how
open
embedded
does
these
things
so
again,
going
back
to
the
embedded,
the
embedded
side
of
things
the
octoproject
open,
embedded
use
the
same
one
is
built
on
the
other.
It
has
its
own
internal,
mirroring
mechanism
for
keeping
track
of
of
software.
One
of
the
reasons
why
it's
become
the
de
facto
build
system
and
in
fact
it
implements
much
of
the
drawing
that
you
have
at
the
top
there.
A
You
know
making
sure
that
the
what
you
download
is
is
what
you
downloaded
last
time
or
that
the
recipe
author
intended
for
you
to
use
so
that
you
don't
get.
You
know
weird
changes
that
things
haven't
changed
on
the
way
through.
You
know
a
threat
actor
doing
a
man
in
the
middle
kind
of
attack,
but
so
so
the
mirroring
initially
was
was
designed
around
solving
that
those
specific
problems.
A
However,
we
also
have
something
called
a
pre-mirror,
and
what
a
Premiere
allows
you
to
do
is
is
to
specify,
instead
of
an
upstream
mirror,
because
the
project
actually
mirrors
software
at
a
location,
that's
actually
run
by
the
Linux
Foundation,
the
you
can
actually
have
your
own
mirror
and
you'll
find
that,
let's
say
the
companies
that
are
that
are
more
paranoid
than
others.
And
again
these
are
companies
like
security,
focused
companies,
like
literally
companies
that
sell
security.
B
A
C
A
B
A
So
I
I,
perhaps
didn't
explain
it
appropriately.
So
so,
in
a
lot
of
situations,
we
have
these
things
called
recipes
and
for
each
component
that
we're
building-
and
there
could
be
hundreds
to
thousands
of
these-
we
download
either
a
specific
tarball,
which
is
usually
has
a
version
number
in
it
if
it's
done
properly
or
it's
pulling
down
an
entire
git
repository,
typically,
which
is
then
cached
to
make
sure
that
the
next
time
you
go
back
to
it,
it's
still
there.
A
Now
this
can
be
done
globally,
as
we
do
in
the
in
the
project
to
make
sure
that
Upstream
sources,
if
they
go
away,
we
still
have
access
to
it.
But,
like
I
said,
you
can
actually
have
your
own
local
mirror
that
we
call
a
Premiere
in
the
sense
that
we
check.
We
check
it
before
we
check
the
public
one,
and
what
this
ultimately
means
is
that
we
have
three
sources
that
we
can
get
something
from.
We
can
get
source
code
from
a
premier
which
basically
circumvents
the
whole
mechanism.
A
A
They
do
not
allow
the
other
two
to
work
and
you
can
turn
those
off,
and
so
they
basically
have
a
security
team
that
looks
at
the
software,
regardless
of
whether
it's
open
source
or
proprietary,
and
that's
it
before
putting
it
into
a
Premiere
such
that
you
can
only
pull
software
from
what
your
bill
SRE
source
code.
Pardon
me
from
from
those
locations
from
those
vetted
locations,
but
I
mean,
for
instance,
just
as
an
example.
If
you're
building
software
for
a
missile,
you
don't
exactly
want.
You
know,
source
code
to
come
from.
A
B
I'll
say
yeah
so
and
all
right
and
so
which
I'm
unfamiliar
with
and
so
but
I,
but
I
still
imagine
that
there
is
a
so
this
we
started
from
the
idea
that
there
could
be
misconfigurations
in
those
in
the
way
those
mirrors
are
populated
consumed.
Maybe
the
order
in
which
requests
are
happening.
Maybe
you
pull
first
from
the
piece
mirror
and
if
you
don't
find
anything
you
go
to
the
public
Upstream
one
and
so
forth,
not.
B
Or
not
selling
any
at
all,
it's
still
a
misconfiguration,
yeah,
yeah
and
so
I
I
wonder.
Do
you
think
in
terms
of
the-
and
we
had
this
discussion
also
in
the
past?
Do
you
think
it
makes
sense
to
how
granular
do
you
do?
We
want
to
keep
this
here
so
I
started
coming
up
with
this
kind
of
one,
let's
say:
basically
misconfiguration
misconfiguration
being
one
thread
resulting
in
the
consumption
of
malicious
components.
The
examples
I
came
up
with,
basically
and
so
again.
B
I
come
I,
come
more
from
this
application
Level
world,
so
I
speak
more
of
Maven,
Maven
repositories
and
maybe
mirrors
or
so,
and
so
here
one
possibility
could
be.
You
know
that
you
can
set
them
up
in
such
a
way
that
you
basically
blindly
mirror
everything
from
the
Upstream
from
public
repositories
you
create
a
copy
and
which
is
protecting
you
against
the
downtime
of
apps
of
public
repositories,
but
that
is
not
doing
anything
on
top,
so
you
could
just
mirror
happily
a
malicious
component
exactly
another
one.
B
Is
that,
basically,
suppose
you
have
a
vetting
process
in
an
organization
you
need
to
kind
of
enforce
and
properly
configure
the
approved
components
and
of
course
there
can
be
plenty
of
hiccups
and
misconfigurations
related
to
this
so
I,
so
I
guess
what
I'm?
What
I'm
asking
here
is:
how
detailed
do
we
want
to
keep
those
threats
or
do
we
just
say
when
it
comes
to
running
an
internal
registry?
A
B
A
And
just
thinking
about
the
ways
I
could
be
messed
up
in
in
in
my
specific
context,
because
you
bet
you've
got
you
thought
about
the
your
own,
like
Maven,
Maven,
basically
and
and
a
lot
of
the
other
mechanisms
replicate
what
we
do
essentially
internally,
with
Dr
Patrick
instantly
I
put
a
link
to
doctor
project
in
the
in
the
the
list.
There.
A
C
A
A
A
A
B
A
A
A
E
We
were
talking
about
being
what
we
were
talking
about
in
this
one
was,
for
example,
in
Homebrew.
It's
happened
before
where,
because
Homebrew
uses
a
DSL,
someone
will
put
a
malicious
link
so
that
Homebrew
itself
will
pull
from
a
malicious
link
and
because
people
don't
actually
check
where
what
they're,
downloading
and
whatnot
it
has
happened.
Where
we
can,
like
accidentally,
merge
that,
and
then
we
end
up
on
Reddit.
A
B
The
just
just
a
quick
question
is
this
something
that
is
happening
on
the
client
of
those
guys.
So
this
is
not
something
that
is
misconfiguration
of
the
internal
package
registry,
but
more
a
misconfiguration
of
the
local
package
manager
which
which,
which
we
have
discussed
as
a
threat
to
the
developer
machine,
where
we
already
have
misconfigured
Maven,
and
we
can
maybe
take
up
here.
A
E
Because
what
we
were
trying
to
say
is
that
home.
If
this
were
to
happen,
Homebrew
would
would
take
its
stance
that
basically
Homebrew
is
not
at
fault,
because
we
are
not
a
software
security
or
a
like
gatekeeper
of
what
gets
in
a
home
brew
and
whatnot.
What
doesn't
so
and
we
merged
it
is
because
it
looks
good
and
it
basically
acts
like
a
dog.
So
it's
a
duck
at
least
from
our
purview
and
if
you're
using
Homebrew,
it
would
be
of
the
opinion
that
maybe
you
should
check
the
formula
before
you
install
it.
C
E
C
B
Yeah
all
right,
but
then
but
then,
but
then
one
quick
question
this
again.
This
sounds
more
like
this
is
either
a
vulnerable
or
a
malicious
package
that
has
a
recipe
configured
that
results
in
pulling
yet
other
components
from
an
attacker-controlled
repository
right.
So
this
is
more
the
the
attack
Vector
here
is
a
malicious
package
on
home
group,
not
a
misconfigured
thing.
I.
A
Think
you
can
step
back
a
bit
further
because
that's
certainly
the
result.
I
think
that
the
threat,
not
the
threat
yeah
the
the
development
threat
here
is,
that
is
that
Homebrew
was
The.
Homebrew
developers
were
were
tricked
into
accepting
essentially
a
formula
that
that
was
malicious.
If
this
is
like
the
the
the
whole
criminal
Community
accepting
patches
that
were
that
introduced
security
problems
in
the
kernel
from
the
University
of
Wisconsin
anyway,
yeah
same
same
kind
of
thing
right,
so
the
end
result,
of
course,
is
the
end
result.
A
B
A
E
You
remember
when
audacity
got
sold
to
that
Chinese
company
and
they
basically
started
packaging
spyware.
That
was
that
was
one
of
the
days
that
basically
Homebrew
ended
up
on
Reddit
because
they
were
like
how
do
you
distribute
this
stuff
and
their
response
was
like,
because
our
job
is
not
to
like
tell
people
like
this
is
what
you
need
to
do
with
your
software.
You
could
do
whatever
you
want
with
your
software
and
it's
a
valid
upgrade.
So
some.
C
B
B
Maybe
it's
the
open
source
home
brew,
guys
or
maybe
I
know
the
developers
of
some
open
source
project
start
pulling
and
declaring
a
malicious
dependency.
But
their
end
result
from
the
perspective
of
this
development
organization
is
the
same
that
it
consumes
a
malicious
piece
of
software
in
different
systems.
Right
so
I
wonder
whether
we
can
describe
this,
whether
it
makes
so
much
sense
to
distinguish
this
here,
as
it
says,
a
different
threat
or
whether
the
threat
is
not
simply,
you
can
consume
well.
A
Interested
no
I
think
I,
think
you're,
saying
here,
mayor,
malicious
component,
you're,
basically
saying
you
know
copy
and
then
continue
to
reuse.
You
know
software
from
an
external
input.
I
I
think
what's
being
discussed
here,
is
more
merging
merging
a
patch
that
that
is
malicious
is
is
the
is
the
threat
here.
It's
a
separate
threat.
Okay,.
B
But
at
this
this
we
have
so
we
have
malicious
commits,
but
this
would
be
commits
that
happen
in
the
source
code.
Repository
of
that
organization.
We
have
a
couple
of
right
and
we
have
I
think
of
course,
this
consumption
of
malicious
packages
and
this
whole
private
registry
is
kind
of
a
variation
of
consuming
malicious
components
through
through
that
channel.
B
D
A
I,
don't
believe
it
does
no
I'm,
not
sure
what
we're
discussing
is
a
malicious
commit,
because
it's
accepting
a
patch
from
a
third
party.
Let's
just
commit
it,
talks
about
and
I
don't
I
I
at
the
risk
of
derailing
things
here.
The
most
estimate
talks
about
a
malicious
Factor
like
a
developer,
going
Rover
malware,
making
a
change,
we're
talking
about
a
third
party
patch
coming
in
and
not
and
being
insufficiently
vetted.
B
A
A
A
So
in
theory
we
know
where
they've
come
from
or
at
least
who
claims
to
have
produced
the
patch.
The
the
the
point,
however,
though,
is,
is
that
a
lot
of
these
things
come
in
through
email
and
of
course,
email
can
be,
it
can
be
subverted,
and
so,
if
something
comes
in,
let's
say
from
Linus
Torvalds,
you
know
weirdly
he's
sending
a
patch
to
the
Linux
drill,
mailing
list
and
and
so
on
and
so
forth.
A
B
A
B
A
It
does
it
does
and
and
the
reason
why
is
because
the
kernel
that
that
people
use
in
again
in
embedded?
Quite
often
it's
not
a
Mainline
kernel,
so
it
usually
starts
as
a
so
we
call
them
vendor,
kernels
and
so
they're,
typically
forked
kernels,
and
then
you
typically
add
Patches
from
other
locations
that
solve
specific
problems
that
haven't
made
it
up
Upstream
now
in
ideal
situations
that
doesn't
happen
but
you'd
be
shocked.
A
B
The
idea
here
of
the
malicious
commit
and
the
malicious
approval
would
be
that
basically
they
go
hand
in
hand
in
case
there
are
kind
of
review
processes
in
place,
maybe
sometimes
they're.
Not
yes.
Maybe
you
have
you
know
one
developer
machine
infected
is
doing
a
commit,
it
requires
approval
and
that
can
be
done
by
I,
don't
know
by
another,
in
fact,
to
developer
machine.
After
having
understood
you
know
what
are
the
typical
roles
of
the
people
in
this.
A
B
A
B
A
C
B
A
B
B
Yeah,
okay,
so
then
I
don't
think
we
have
this.
Yet
this
is
somehow
I.
Don't
I,
don't
see
it
yeah
yeah,
but
that
is
something
for
the
I
I
put
it
here
to
the
developer
machine
because
it
will
eventually
be
done
from
yes
by
the
developer
sitting
on
his
machine
all
right.
So
then,
how
can
we
name
this
threat
here?
Then.
B
A
B
B
No,
that's
a
nice,
that's
a
nice
one!
Thank
you!
So
much
we
didn't
really
get
any
further
here.
We,
though,
maybe
a
quick
question
to
resolve
this
for
me,
so
my
my
take
would
be
for
this
private
repository
that
we
have
two
threads
one
is
for
the
time
being
and
it
can
be
detailed
and
split
up
later
on.
B
One
is
all
about
misconfiguring
such
private
repositories,
and
the
second
is
basically
about
wrong:
insufficient,
incomplete
approval
processes
or
betting
processes
that
you
know
they
only
look
at
Major
releases,
but
not
that
minor
releases,
and
so
if
there
is
a
malicious
software
in
the
minor
release,
they
wouldn't
get
it
or
maybe
they
look
at
the
when
vetting.
They
look
at
the
source
code
repository
on
GitHub
and
don't
realize
that
does
that
this
does
not
correspond
to
what
they
download
from
a
binary
repository.
It's
kind
of
flawed
plot
betting
processes.
A
B
A
C
B
D
A
That's
then
signed
by
the
person
who
did
the
vetting
so
that
you
can
then
say:
okay,
this
person
said
that
this
commit
is
I
I.
It's
not
it's
a
mitigation
to
this
problem
as
opposed
to
an
actual
problem,
but
I'm
I'm
wondering
whether
something
like
that
exists,
because
then
the
the
issue
would
be.
You
know
not
having
a
certificate
of
of
being
vetted
for
security.
B
A
C
B
C
B
D
B
I'm
lacking
the
name
here
but
I
think
there's
something:
I
can
I
will
look
this
up
for
the
next
session,
I
hope
all
right,
but
other
than
that
you
agree
on
this
being
at
least
two
different
threats.
The
one
is
this
whole
misconfiguration
thing
and
then
yes,
other
is
related
to
the
vetting
process
is
being
having
hiccups.
Let's
say
yes,
and
so
I
will
actually
I
will
actually
move
this
down
here,
which
is
the
incomplete,
insufficient
vetting
process,
which
is
kind
of
actually
a
broader
description
of
or
more
General
description
of.
B
One
of
the
the
problems
that
that
is
in
here,
which
is
they
just
look
at
the
different
artifact?
Okay
right,
so
you
see
how
this
is
how
quickly
the
time
passes
right.
So
it's
I,
don't
know
it's
I
yeah
always
gives
me
the
feeling
that
there's
just
so
much
so
much
more
to
do
and
to
discuss
feels
a
little
bit
like
this
is
first
but
yeah
again,
I'm
quite
happy
I.
A
A
A
B
E
B
Good
all
right!
Well,
then,
thank
you
so
much
and
hope
to
see
you
so
as
of
the
next
week.
Maybe
last
word
here
so
since
we
we
have
until
end
of
this
week
in
order
to
vote
on
this
new
time,
slot
I
would
say
that
I
think
we
should
have
next
week
again
have
it
on
the
on
the
three
o'clock
and
then
we
as
of
the
week
after
we
start
on
the
new
schedule.
It
would
be.
My
would
be
my
purpose
all
right
guys.
Thank
you.