►
From YouTube: End Users Working Group (June 27, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1abI65H4pF5y8YtA2_TuDBAaI47v9mTfpr5mwVvccX_I
B
C
A
C
D
D
John
asked
me
to
forward
this
threat.
Modeling
call
a
couple
of
folks
at
City
who
worked
with
the
main
with
svps
and
Technical
leads
in
the
thread.
Modeling
area,
maybe
he's
hoping
that
they
can
help
us.
One
of
them
had
responded
and
wanted
to
check
and
see.
If
the
you
know
how
his
availability
fits
in,
so
I
just
forwarded
that
and
I
will
advise
if
that
works
out.
D
A
A
A
B
C
B
E
B
B
A
Great
so
for
today,
a
quick
update
on
what
has
happened
since
we
have
been
together
last
I'm,
sorry
oops,
my
phone
rang
since
we've
been
together
last
week,
so
the
one
thing
is
so
for
being
being
suggested
to
actually
change
the
name
because
he
found
it
a
little
bit.
Misleading
and
I
agree.
I
mean
this
was
just
a
kind
of
the
first
title
that
we
we
put
there
and
it's
it's
worthwhile
to
clarify
this.
A
So
with
a
little
bit
of
back
and
forth
between
BN
and
John
and
myself,
John
suggested
threat
model
of
Enterprise,
open
source
supply
chain,
I
find
it
definitely
better
than
what
we
had
before
and
hopefully
clarifying
a
bit
what
we
are
doing
here,
the
one
my
proposal
was
far
too
long.
So
if,
unless
there
is
any
objection
or
I,
would
you
know,
I
would
go
for
this
because.
D
C
A
D
A
D
A
C
A
Again,
please
read
through
it,
and
let
me
know
whether
this
is
clarifying.
What
is
to
be
protected
here.
I
mean
it's.
The
the
five
bits
are
basically
all
the
proprietary
source
and
binary
code,
which
is
including
kind
of
resource
files
default
configurations
and
so
forth,
both
stuff
that
is
ending
up
in
the
final
software
product,
as
well
as
all
the
intermediate
artifacts
that
are
created
and
produced
and
used
throughout
the
development
process.
A
And
then
the
system
infrastructure,
which
is
you
know,
configuration
settings
for
any
internal
systems
and
charts
and
civil
playbooks
data
files
and
the
light
Miracle
particle
that
is
included
or
that
is
used
throughout
the
development
systems
in
the
sense
of
any
systems
involved
in
product
development
and
service
operation
and
then
credentials
and
secrets.
So
so
again
read
through
it
and
let
me
know
and
whether
there
are
any
comments
and
another
I
know
I'm
going
to
share.
A
You
said:
can
you
see
my
screen
now
another
change
or
what
I
looked
up?
Maybe
you
a
few
of
you,
remember
the
discussion
from
last
week
where
we
discussed
with
BN
about
private
repositories
and
that
so
far
in
this
architecture,
diagram
we
just
have
commercial
providers
and
in
general
it
is
nicer
to
in
fact
have
open
source
examples
rather
than
pointing
to
certain
vendors.
A
A
Here
there
was
one
from
Apache
and
one
from
the
eclipse
software
Foundation,
but
but
both
were
either
only
focusing
on
Maven
or
osgi
in
particular,
and
so
they
were
very
narrow
in
schools
and
also
they
don't
think
one
of
the
eclipse
project
has
been
archived
and
for
also
the
the
one
from
Apache.
If
I'm
not
mistaken,
didn't
look
so
you
know
actively
developed
any
longer.
The.
A
So
you
see
here
on
the
screen,
it's
an
open
source
solution
that
is
supporting
a
variety
of
different
ecosystems
in
a
kind
of
plug-in
extension
manner.
So
if
you
scroll
a
little
bit
below
you
see,
they
support
python,
Maven,
I
think
also
npm
packages,
also
Docker
images,
but
also
RPM
and
Debian
packages,
so
I
I
think
in
terms
of
Gulp
and
ecosystems,
supported
that
look
pretty
good,
any
any
feedback.
You
ever
heard
of
this
thing
or
you
ever
even
used
it.
F
B
B
Because
they
want
to
actually
maintain
all
of
the
packages
they
use
when
I
say,
maintain,
I
mean,
for
example,
actually
like
have
a
registry
of
patches
that
get
applied
to
certain
pieces
of
software,
and
they
maintain
all
of
that
nowadays
in
the
modern
world.
You
really
don't
need
to
do
that.
You
know
ever
since
Red
Hat
came
along
kind
of
basically
sold
everyone.
The
idea
of
a
company
doing
that,
for
you,
I
mean
Debian
is
the
same
thing.
B
You
have
a
community
that
does
that,
for
you,
you
know
so
so
it
really
I
think
depends
on
on
like
how
much
technical
debt
you
want
to
incur
what
your
technical
proficiency
is.
You
know
if,
if
you
have
abilities
that
came
post,
Cloud
native
or
pre-cloud
native
and
post
cloud
native
I,
think
all
of
that
has
a
lot
to
do
with
it.
A
Yeah
so
so,
in
other
words,
so
first
of
all
I
understand
that
nobody
knows
or
has
ever
used.
This
particular
thing
right
and
I
agree
that
large
companies,
at
least
the
ones
that
I
know
that
typically
go
for
those
commercial
vendors
I
completely
agree
here,
but
I
I'm
not
sure
what
are
what
are
the
reasons,
in
fact,
because
for
other
Technologies
they
very
well
go
for
in
so
many
cases
they
go
for
for
open
source.
Solutions
such
as
in
my.
G
G
You've
got
a
whole
like
you've,
gotta
or,
if
you,
if
you
pull
it
from
open
source,
you've
got
to
host
it
yourself
and
it.
You
know,
from
a
risk
mitigation
perspective.
You
know
people
keep
considering
that.
Well,
if
you
built
it,
you
probably
are
the
best
job
of
securing
it.
So,
like
we'll
put
the
we'll
we'll,
we
will
hand
that
risk
off
to
you
and
we
will
just
pay
you
money
so
that
you
can
own
that
risk.
A
Yeah,
you
know
this
kind
of
it's
it's
more
convenient
in
that
sense,
if
you
just
rely
on
some
some
cloud
provider
operating
the
thing
for
you,
but
but
again
I
mean
for
other
technologies.
That
is,
that
is
not
really
the
case
right,
so
I
think
there's
still
a
good
number
of
Jenkins
systems
out
there
in
the
industry,
even
though
it
also
requires
running
this
locally
on
premise,
but
maybe
this
is
just
Legacy
and
the
general
Trend
probably
is
also
towards
cloud
services
and
providers
as
well
in
this
space.
A
All
right.
So
maybe
maybe
this
discussion
can
be
concluded
by
saying
we
don't
have
really
a
convincing
or
a
good
or
a
widely
used
open
source
internal
package
registry
that
that
we
could
could
use
as
an
example
in
this
picture
right,
fair
enough
good,
then
I
wanted
to
go
through
and
the
other
change
that
happened
since
last
week
is
basically
that
John
added
a
couple
of
threats,
namely
here
in
the
build
system.
A
Space
and
I
wanted
to
go
over
over
those
and
discuss
with
you,
maybe
maybe
at
details
or
likelihood
or
and
so
forth.
So
the
first
thing-
and
he
was
quite
detailed
here-
was
about
tampering
with
the
existing
build
steps,
adding
additional
build
steps
or
temper
with
the
order
of
so
here.
This
is
more.
You
know,
tamping,
with
the
order
of
of
the
the
steps
in
a
pipeline
temper
with
the
final
build
check,
control
and
that
I
guess
these
are
all.
A
These
are
all
threats
that
he
added,
which
I
think
depends
a
little
bit,
of
course,
on
how
the
the
build
system
is
set
up
but
which
either
require
basically
modifying
the
pipeline,
different
definition,
which
means
committing
a
changed
tempered
version
into
the
source
code,
control
system
or
in
more
classical
environments,
having
kind
of
maybe
the
authorization
to
log
into
a
web
front
end
and
then
temper
kind
of
manually
with
the
through
a
UI
with
a
good
process.
Definition
right,
I,
I,
wonder
what
do
you
think
is
this?
A
A
B
I
would
say
that
there's
a
little
bit
of
a
difference
between
what
John
added
and
where
we
were
head,
where
we
were
at
because
everything
John
added
is
actually
very
good,
and
it's
it's
on
point.
However,
I
I
kind
of
think
that
what
we
were
going,
the
road
that
we
were
going
down
before
was
based
more
on,
because
something
happens.
This
other
thing
can
happen
because
to
tamper
with
a
build
step,
I
mean
yes,
that's
a
bad
thing,
but
I
think.
B
First,
you
would
have
to
figure
out
like
where
the
threat
is
coming
from,
because
what
you're
doing
is
you're
stating
essentially
like
this
would
be
a
bad
thing
and
and
there's
a
lot
of
bad
things,
but
like
how
does
one
go
about
doing
that?
Because
I
would
actually
argue
you
can't
bring
with
a
build
step.
I
mean
it
depends.
It
depends
on
what
what
the
build
system
is,
how
they
have
it
set
up.
B
It's
almost
a
matter
of
prescript
this
versus
descriptive
right,
because
one
is
more
prescriptive
and
the
other
one
is
more
from
like
a
descriptive
point
of
view.
So
I
think
it
just
depends
on
kind
of
what
point
of
view
you're
looking
at
it
from
and
I
think
that
it
some
of
it
might
be
good
to
think
about
just
because
different
people
have
different
ways
of
looking
at
it.
So
prescriptive
might
not
be
the
best
way,
every
single
time,
maybe
adding
a
descriptive
element
in
there.
B
Although
I
kind
of
think
we
cover
that,
but
it
just
might
be
something
to
maybe
better
clarify
and
whatnot,
so
that
there
is
more
of
a
descriptive
element
to
it.
But
I
would
say
that
what
we
were
doing
before
is
more
prescriptive
in
the
sense
that
it's
kind
of
like
directly
addressing
something.
Whereas
John
has
taken
more
of
a
descriptive
route.
Where
he's
describing
things
from
like
a
a
higher
level
and
I.
G
B
A
Be
yeah
now
just
wonder
how
so
whether
this
it
will
make
it
more
difficult
to
come
up
with
controls
right
so
that
that
is
just
one.
If
this
is
a
higher
level
description
of
what
can
go
wrong
in
different
ways,
it
will
be
difficult
to
to
come
up
with
controls
here.
I
think
right,
but
do
you
think
it
makes
sense
to
so?
If
we
say
all
those
things
here,
tamper
with
existing
build
step
change
the
order
change
the
final
check
control.
A
On
the
on
a
build
system
such
as
again
a
Jenkins
system
that
wouldn't
be
covered
yet
right,
so
the
thread
here
would
be
maybe
more
that
yeah
insufficient
access,
control
on
build
system
and
then
yeah.
The
malicious
actor
could
basically
abuse
those.
This
vulnerability.
This
wrong
configuration
and
temper
with
the
with
the
steps
here
in
the
in
the
UI.
B
B
Yeah,
like
that's,
why
GitHub
s,
you
know
basically
tells
you
if
you're
going
to
use
their
build
systems
that
they
are
public,
build
systems,
don't
build
anything.
That's
like
not
or
that's
pretty
much,
not
public,
because
of
that
same
very
fact,
because,
like
this,
it
goes
back
to
the
whole
thing
of
our
container
is
really
secure,
so
yeah,
basically
long
story
short,
there
have
been
people
in
the
past.
Malicious
actors
is
what
they've
called
them
that
have
done
different
things.
B
They
I,
don't
I,
don't
think
they
were
ever
specified
but
was
done,
but
basically
that's
why
GitHub
will
tell
you
like
the
public
machines
they
offer
to
build
on,
are
really
kind
of
for
like
open
source
and
like
things
that
are
public.
If
you
want
something
private,
they
really
don't
recommend
using
their
public
build
service.
People
still
use
it,
but
that's
the
recommendation
is
to
not
do
it
because
there
have
been
things
in
the
past
where
people
have
acted
in
as
Bad
actors.
A
D
D
Specific
one,
and
if
there
are
those
aspects
or
you
know,
components
that
we
can
keep
the
overall
structure
and
and
then
address
the
specific
one
that
we
want
to
approach
that
might
make
it
easier,
like
the
gate
for
for
now
and
then
make
yeah
and
make
it
a
little
bit
more
approachable
and
actionable
item
and
giving
this
as
a
purpose
and
scope.
Like
a
broader
one.
B
B
Now
we
were
talking
about
like
kubernetes
as
an
orchestrator,
that's
different
as
we
were
talking
about
ansible
as
an
orchestrator,
that's
different.
So
you
see
this
is
what
I'm
saying
about
how
like
before.
We
were
very
prescriptive
because
we
were
talking
specifically
about
git
and
now-
and
this
is
more
generalized,
so
I
do
see,
benefits
in
what
John
is
doing.
However,
this
is
where
I
think
we
should
start
thinking
about
like.
Are
we
going
to
be
talking
about
git?
Are
we
going
to
be
talking
about
things
like
at
a
broader
level
like
build
systems?
B
C
C
B
Because
we
also
discussed
this
to
Henrik
about
like
being
very
specific
about
what
we
were
recommending
because
remember,
we
have
the
talk
with
Ian
about
how
like
we're,
focusing
on
how
like
commercial
companies,
use
open
source
and
software.
So
for
the
scope
of
this
document,
if
we
were
to
say
that
most
people
use
GitHub,
GitHub
Enterprise,
then
that
would
be
okay
and
but
you
see
like
so
in
a
way
we
did
kind
of
go
down
that
path
of
being
very
explicit
about
what
we
were
covering.
But
I.
B
A
No
but
but
I
think
so.
First
of
all,
we
discussed
in
the
past
to
not
look
at
GitHub
Enterprise
soon,
but
to
stay
vendor
neutral
here.
Secondly,
I
think
we
can
say
whenever
the
pipeline
is
managed
and
controlled
through
code,
it
is
covered
by
what
we
have
before
and
so
in
order
to
maybe
integrate
John's
contribution,
we
can
still
assume
I
think
in
a
technology
independent
way.
A
There
is
a
build
system
which
has
some
users
with
we
have
some
kind
of
some
commissions
and
accessing
for
some
access
control
and
we
relate
to
the
threat
of
those
you
know
due
to
wrong
configurations
wrong
permissions
factors
could
interact
with
the
build
system
correct,
so
you're
not
so.
This
is
a
maybe
maybe
a
compromise
for
how
to
to
move
forward
on
those
ones.
Here.
B
A
B
So
yeah
we
were
doing
git
and
I
think
that
if
we,
if
we
kind
of
go
down
the
road
that
John's
going
down,
then
that
would
be
Version
Control.
It
doesn't
matter
which
Version
Control
ver.
It
would
basically
be
like
Version
Control,
because
that
would
be
what
John's
talking
about,
because
a
build
system
doesn't
matter
which
build
system
base.
But
it's
a
build
system.
It
can
be
susceptible
to
these
threats.
A
C
B
A
We
keep
this
granularity
and
we
keep
those
three
threads,
but
we
specify
that
this
is
done
through
accessing
the
build
system
or
the
build
systems
API
or
UI
and
whatever
it
exposes
in
order
to
avoid
the
overlap
with
this
malicious
commit
way
of
doing
the
same
thing.
Achieving
the
same
thing,
I'm
not
opposed
to
that
so
Tampa
with
existing
or
maybe
let
me
go
through
suggestion
mode.
A
Even
though
I
must
say,
I
wonder
how
many,
how
many
build
systems
there
are
still
out
or
any
any
feeling
for
how,
because
nowadays,
everything
seems
to
be
managed.
Only
all
the
build
systems
or
build
pipelines
seem
to
be
managed
through
code
right
and,
if
any
feeling,
for
you
know
more
old-fashioned
systems
being
still
out
there
like.
A
A
B
B
A
B
A
B
A
A
You
know
builds
through
through
those
plugins
if
I'm
not
mistaken,
but
then
again
the
build
script
depends
on
whether
again
maybe
managed
by
by
git,
and
so
then
it
would
be
covered
and
build
tool
is
for
me,
yeah
I,
don't
know
another
and
just
another.
You
know
binary
installed
on
the
build
system
that
is
invoked
by
the
build
script
right
so
which
can
be
compromised,
maybe
in
a
different
way,
for
example
by
through
by
accessing
through
the
operating
system
and
tampering
with
this
one
through
through
this
way.
So.
B
B
Because,
essentially,
as
as
you
said,
if
you
can
get
to
the
build
script,
you
can
build
it
so
I
think
the
build
pipeline
is
what
offers,
for
example,
access
controls
and
all
of
that
stuff.
But
then
you
would
be
talking
about
devops,
you
wouldn't
be
talking
about
like
make,
because
all
of
that
came
into
exist
and
long
after
make
was
a
thing.
B
G
G
B
So,
basically,
what
we
were
saying
is:
should
we
separate
like
build
pipelines
from
build
systems
because
build
systems
like
make,
for
example,
there
you
just
invoke
them
and
if
you
can
get
access
to
them
via
privileged
escalation
or
whatever,
basically
it's
building,
but
with
build
pipelines.
You
have
ACLS
and
all
that
other
different
type
of
stuff.
So
should
those
two
maybe
be
separated,
because
the
security
threats
are
slightly
different
between
the
two.
G
If
you're
purely
looking
at
it
from
the
perspective
of
like,
are
the
risks,
so
are
we
looking
at
it
from
the
perspective
of
what
the
risks
are,
what
the
results
of
an
attacker
being
able
to
compromise
them
are
right
like
if
you
can,
the
purely
the
ability
to
invoke
some
like
some
build
is
not
necessarily
completely
a
risk
right
like
that
I
mean
it
may
be.
It
may
lead
to
you
know
exposure.
C
G
A
problem
in
and
of
itself,
it's
the
it's
the
it's
the
execution
in
the
pipeline,
where
you're
actually
releasing
the
software
right.
The
ability
to
tamper
with
the
the
make
file
right
is
a
risk.
If
you
are
able
to
commit
it
and
contribute
it
back
right,
because
then
you
can
tamper
with
it,
but
then
that's
checking
the
source,
control
and
it's
traceable
right
and
and
act
actors
are
less
inclined
to
want
to
be.
B
G
Well,
I
mean
it
depends
you
can.
It
can
release
the
software
if
you've
added
like
I
know,
there
are
still
many
many
a
developer
who
they
use
the
ICD
pipelines,
but
they
the
the
the
frequency
at
which
they
release
their
software,
is
so
infrequent
that
they're,
like
okay,
I'm
gonna,
set
up
the
the
publishing
Pipeline
and
I
run
that
locally
on
my
machine.
Only.
C
A
A
You
know
a
tool,
a
thing
that
is
invoked
during
the
build
or
a
build
step
as
part
of
a
pipeline
sure,
and
if
we
and
then
the
last
bit
and
for
me
the
build
system
is
for
me
really
kind
of
you
know
the
the
operating
system
on
which
all
of
that
runs
could
be
in
like
a
physical
box
could
be
a
Docker
container.
It
could
be
yeah
container
managed
by
by
kubernetes.
Also.
B
I
would
say
that
basically
makes
main
a
focus,
at
least
when
I
was
created
from
my
understanding
was
for
you
not
to
have
to
invoke
the
super
long
like
terminal
command,
to
make
your
software.
So
that
way,
it
basically
would
do
it
for
you
and
it
would
configure
it
for
you,
but
all
of
that
came
long
before
we
were
able
to
have
like
I
would
say
like
legitimate
configuration
files
for
a
build
pipeline,
so
I
was
I,
would
I
think
in
the
community
at
least
the
way
I've
read
it
most
of
the
time.
B
B
So
I
would
say
Henrik
that,
like
what
you're
like
what
you're
talking
about
was
post,
Cloud
native
and
I,
think
that
this
is
very
important,
because
that
we
get
right,
because
there
are
a
lot
of
people
in
the
community.
That
think
that
we're
very
tone
deaf
to
everything
that
happened
prior
to
Cloud
native.
F
E
F
A
C
A
C
A
So,
but
one
step
back
so
here
to
so,
if
we
say
one
thread
is
that
GCC,
the
Java
compiler
and
other
you
know
things
invoked
during
a
bit
pipeline
are
tempered
with
right.
You
would
do
this
I
suppose,
or
one
way
of
doing
this
would
be
by
accessing,
but
again
depends
on
the
build
system
right.
So,
let's.
B
Say
I
actually
have
a
better
definition
from
being
because
I'm
on
static
with
being
he
says,
a
build
system
runs
on
a
developer
machine.
A
pipeline
is
usually
something
that
like
is
installed
in
the
source
code
directory
that
monitors
the
source
code.
So
IE
a
build
system
cannot
be
Auto
triggered
a
build
pipeline.
Can.
F
B
C
B
A
B
But
I
do
think
that's
that's.
A
good
distinction
is
build,
pipelines
are
not
automatic,
CI,
CD,
I'm,
sorry,
build
systems
are
not
automatic.
Ci
CD
pipelines
are
because
I
think
that's
the
threat
right,
because
it's
one
thing
to
compromise
the
developers
machine
and
to
compromise
the
build
system.
It's
a
something.
That's
separate
when
you
have
a
remote
machine,
that's
monitoring
something,
and
then
you
could
basically
get
away
with
certain
different
things.
Basically,.
A
All
right,
so,
let's,
let's
let
maybe
let
me
take
me
another
perspective,
so
suppose
I
want
to
maybe
in
a
in
a
in
an
attack
comparable
to
solar
winds.
I
would
like
to
tamper
with
such
a
such
a
big
job,
so
that
kind
of
the
I
think
in
solar
wind,
the
solar
winds
case
there
was
the
legitimate
Source
calls
was
replaced
just
shortly
before
compilation
and
then
the
legitimate
code
was
restored
after
the
malicious
code
has
been
compiled.
A
I
I,
think
that
holds
even
true
for
Jenkins
that
you,
you
basically
have
your
Docker
containers
being
spun
up,
and
then
it's
within
this
Docker
container
that
you
would
run
the
actual
build
right
so
where
the
Clone
happens,
where
the
compilation
happens
and
so
forth,
and
so
in
that
sense,
in
order
to
tamper
with
it,
one
way
would
be
to
basically
for
the
attacker
to
to
change
the
image
correct
that
that
is
pulled
when
the
build.
Let's
say
all
it's:
let's
use
names
when
Jenkins
instantiates
a
new
container
that.
A
D
B
It'd
be
a
good
example.
A
simple
example
would
just
be
compromising
the
developers
machine
based
on
the
software
they
have
installed,
and
then
you
see
and
then
basically
at
that
point
I
mean
it's
not
just
a
matter
of
build
pipeline.
You
can
do
whatever
you
want,
but
yeah
you
could
change
it.
You
could
change
things
on
their
computer
where
they're
compiling
software
with
your
special
patched
version
of
GCC,
then
they
would
never
know
about
it.
A
Yeah
but
but
I
mean
the
software
that
is
produced
by
the
organizations
that
we
that
we
talk
about,
they
would
not
I
hope,
build
any
software
on
any
developer
machine,
but
that
is
only
happening
on
dedicated
machines
right.
So
the
the
kind
of
tempered
modified
version
versions
of
GCC
on
the
developer
laptop,
don't
matter
so
much.
Maybe
it.
A
Yeah,
that's
what
I!
That's
what
I
wanted
to
say:
I
there
should
be.
There
should
be
okay.
Well,
maybe
maybe
we
can
make
this
a
separate
thread.
Then
I
would
not
expect
any
company
to
have
you
know
the
distributed
software
being
built
on
a
single
developer.
Machine
I
mean
I,
know
that
this
is
yeah.
Okay,.
A
Yeah
for
the
open
source,
Community
I'm
I'm,
well
aware
that
there
is
a
long,
a
long
tail
of
small
projects,
probably
that
builds
it
on
the
on
the
on
the
laptop,
basically
before
uploading
to
npm
and
Pi,
Pi
and
so
forth.
But
I
would
think
that
for
a
commercial
organization
staff
dedicated
systems
to
build
and
software,
but
I
think
it's
worthwhile
to
call
it
out.
So
in
this
sense,
okay,.
B
A
E
B
E
So
this
is
so
sash
by
the
way,
so
this
is
like
when
you
have
so
what
are
the
attack
surfaces
here?
So
you
have
all
the
plugins
like
Eclipse,
ID,
plugins
and
everything.
So
they
are
the
source.
They
can
be
the
source
of
back
doors,
so
waiting
and
selection
of
those
all
those
plugins
Associated
associated
with
all
the
developer
development
tools
used
by
the
developers,
so
that
can
be
compromised.
That
is
one
and
second
thing
is
Secrets
developers.
A
E
A
C
E
A
B
Description
would
be
basically
modifying
the
build
system
in
some
way
the
developer
can't
tell,
or
does
it
notice
that
ultimately
modifies
the
release
build
and
for
the
record
Henrik?
Just
so
you
know,
I
see
this.
A
lot
in
driver
production,
like
I,
could
have
done
a
lot
with
drivers
like
the
driver,
development
habits
of
people
that
make
drivers
is
a
blissmally
terrible.
B
B
And
this
is
also
why
we
still
like
in
Linux,
we
still
have
really
really
old
drivers,
because
basically
the
million
people
have
contributed
a
million
things
to
them,
so
yeah
like
it,
gets
really
really
hard
and
as
far
as
Linux
is
concerned,
there
have
been
issues
in
the
past
with
drivers
and
people,
basically
having
very
bad
habits
on
their
machines,
losing
machines.
Just
it's
it's
terrible
like
like,
and
it's
because
driver
development,
and
not
that's
just
not
in
Linux,
but
in
general,
it's
just
it's.
E
B
Very
expensive,
that's
what
I've
been
told
is
that
it's
very
expensive
and
that's
why
it's
very
messy,
because
they
will
try
to
copy
and
paste
as
much
as
humanly
possible
to
try
to
save
costs
on
a
lot
of
things.
And
it's
not
just
one
company.
It's
all
the
companies
are
to
blame,
which
is
really
why
they
had
to
separate
firmware
from
the
Linux
kernel
years
ago,
because
firmware
cannot
be
trusted
because
it
could
literally
come
from
anywhere,
and
sometimes
it
does.
B
That's
the
other
funny
thing
that
sometimes
it
does
sometimes
it's
not
from
the
company
directly
and
then
you
get
these
drivers
and
they're
just
from
some
random
guy.
That
spent
two
months
trying
to
figure
out
how
something
works
and
there
you
go,
and
then
everybody
uses
that
driver
and
then
that
guy
doesn't
know
anything
about
security.
B
C
B
And
if
you
want
like
specific
examples,
I
could
go
find
them,
but
if
you
just
go
to
the
like
the
kernel
to
like
the
Linux
kernel
and
you
go
to
the
driver
development
section,
yeah
like
there
are
a
lot
of
people
that
submit
stuff,
no
one
can
verify
where
it
comes
from.
They'll
wait
like
six
months
and
then
somehow
it
just
ends
up
in
the
kernel.
A
A
A
B
B
A
C
A
E
Yeah,
eventually
trying
to
prevent
a
malicious
code
injection,
but
we
are
talking
about
different
Source
malicious
code-
can
come
from
a
copy
paste
from
a
stack
Overflow
or
that
kind
of
what
what
you
just
said,
all
malicious.
What
can
come
from
a
black
door
from
say
from
Plugin
or
any
other
any
other
insecure
or
any
other
vulnerable
software?
So
there
are
different
attack
surfaces
from
for
malicious
codes
to
be
injected.
So
that's
what
we
are
trying
to
do.
A
Okay,
so
then
these
are
two
different
things
and
so
sorry
we're
we're
well
beyond
time,
but
as
long
as
there's
some
interest
in
continuing
the
discussion,
I
just
keep
on
talking,
so
the
first
that
you
mentioned
were
vulnerable
plug-ins.
If
you
have
that
they
can
be,
those
vulnerabilities
can
be
exploited
and
then
maybe
there's
some
innovation
of
privilege
on
this
respective
build
machine
and
then
from
there
anything
can
happen.
The
second
thing
that
you
just
mentioned
are
malicious
plug-ins
right.
A
So
this
comes
back
to
what
we
have,
which
is
kind
of
a
different
thing,
I
would
say
and
which
comes
back
to
the
discussions
we
had
previously
on
the
developer
machine
about
you
know
having
vetting
processes,
approval
processes
that
make
sure
you
only
install
this
version
of
this
thing
and
nothing
else.
Yes,
yes,.
E
A
No,
we
we
don't.
We
don't
do
this,
so
we
were
excluding
this
in
the
beginning.
We
have
opened
the
scope
anyhow
far
too
much
I
have
the
feeling.
So
no
we
don't.
We
don't
do
this
and
so
yeah
so
for
malicious,
build
system
plug-ins
the
controls.
This
comes
back
to
you,
know
approval
and
betting
processes.
B
A
Yeah
yeah
I
agree.
We
we
will,
we
will.
We
continue
to
see
those
right.
There
will
be
vulnerable.
Software
is
all
over
the
place.
There
will
be
the
likelihood
or
some
chance
of
having
a
malicious
piece
of
software
all
over
the
place,
and
maybe
they
will
be
condensed
at
a
later
point
in
time.
I
think
no
matter
where
they
are
installed.
A
A
A
A
All
right,
I,
I,
think
I'm
good,
maybe
another
last
request
and
I
I
wanted
to
have
I
forgot
when
going
through
those
in
the
beginning
of
the
meeting
but
I
when
going
through
this
stuff,
I
noticed
we
have
a
lot
about
lack
of
tool,
guidance,
lack
or
bypass
of
a
wetting
process,
an
incomplete
vetting
process
or
inconsistent
internal
processes
and
get
guidelines.
So
so,
but
these
are,
these
are
more
problems
of
organizational
processes
or
maybe
organizational
head-ups.
A
The
end
goal
is
to
have
I
think
a
comprehensive
list
of
threads
that
we
can
share
with
such
commercial
development
organizations
and
that
can
be
linked
to
existing
efforts,
both
of
the
most
most
importantly
of
the
open
ssf,
but
also
from
other
sources
that
that
can
be
used
to
mitigate
those.
So
but.
B
C
B
B
Yeah
because
I
would
be
happy
if
we
have
like
50,
you
know
or
like
I
know,
that's
a
lot
but
I
think
I
mean
I.
Think
it's
a
tangible
number,
but
even
if
we
said
30
or
20,
you
know
like
at
least
I
would
be
enough
for
us
to
start
marketing
and
getting
the
word
out.
In
fact,
I
talked
yesterday,
I
had
a
meeting
internally
with
the
LF.
C
A
B
Let
me
know
we
should
talk
about
that
next
time,
because
I
I
definitely
have
a
lot
to
do
with
the
LF
marketing.
I
just
have
contact
with
them
for
the
new
blog
and
I
know
that
Jennifer
Bligh
does
the
marketing
at
LF
and
we've
talked
before.
So
we
should
talk
about
that
next
time
about
how
we
could
start
doing
or
drawing
lines
in
the
sand.
A
B
A
I've
talked
to
Jennifer
in
the
past:
I
think
that
is
yeah.
That
was
a
it's
a
good
way
to
go
I
agree,
but
for
that
I
think
there's
still
a
little
bit
of
consolidation
required
totally
totally
or
all
right,
good.
Let's,
let's
call
it
a
day
for
today,
yep
I
will
again
again
get
well
soon.
Randall.
Thank.
C
A
I
hope
you
get
over
your
cold
and
talk
to
yeah,
maybe
next
for
next
week
we
set
last
week
Thursday.
We
would
still
have
it
on
Tuesday
right,
but
I'm
not
sure
whether
anybody
of
you
will
be
there
I
guess
it's
it's
July
4th,
so
you
will
be
off
on
vacation.
So
don't
think
this
makes
makes
so
much
sense.
In
fact,.