►
Description
Meeting notes: https://docs.google.com/document/d/1KQalBRzfRBvsqh73JUYfp1KG-AJdXcv2Z8LTIFoQP8c
A
B
B
A
B
B
A
A
A
Happened
over
the
weekend,
I
think
a
couple
of
guys
were
off
on
vacation
and
then
yeah.
There
were
just
too
many
malicious
packages
being
published
in
the
week
before,
so
they
decided
to
temporarily,
you
know,
forbid
new
accounts
being
created
and
packages
being
I
think
actually
it
only
created
affected
mu,
entirely
new
packages,
not
new
package
versions
of
existing
packages
render
right
correct.
D
A
B
A
D
A
Okay,
all
right
so
last
time
we
were
basically
discussing
different
security
threats,
materializing
on
the
developer
machine
on
the
very
left
hand,
side
of
this
architecture
diagram-
and
we
came
up
with
a
good
number
of
threats
that
I
have
documented
here.
I
just
changed
a
little
bit
the
a
few
phrasings
here
and
there,
but
not
very
much,
and
so
what
we
have
come
up
with
is
basically
it
was
all
around.
A
E
A
So
what
you
mean
is
because
we
we
look
at
threats
related
to
the
consumption
of
basically
malicious,
open
source
components
right
and
so
do
I
get
it
right
that
if
a
developer
is
backing
something
up,
that
backup
is
tampered
with
and
then
it
re
he
restores
it
on
on
his
or
her
developer
machine.
This
would
be
a
vector.
E
Yeah
I
guess
once
it's
back
up.
There
are
multiple
multiple
ways
to
use
that
backup.
One
way
that
you
just
said,
maybe
the
backup
can
be
something
can
be
added
malicious
code
or
virus
can
be
added
to
the
backup
and
one
developer
restore
to
the
developer
machine
that
the
problem
goes
comes
back
to
the
developer
machine.
There
is
also
possible
that
the
the
password
file
or
key
files,
whatever
is
on
the
secrets,
that's
stored
on
the
developer
machine,
could
be
could
be
accessible
on
the
on
the
backup.
A
And
so
if
we
develop
a
machine
and
but
the
developer
back
up
would
would
not
you
know,
be
stored
outside
of
that
organization.
Right
and
would
not
be
would
be
unrelated
to
those
data
flows
so
even
though
in
general
I
agree,
but
that
this
could
be
a
problem
as
long
as
we
exclude
Insider
threads
I'm,
not
sure
how
this
can
be
a
vector
for
consuming
malicious,
open
source,
I.
D
Know
what
I
mean
I
think
that
they
kind
of
I
think
it
walks
a
a
very
debatable
line,
because
I
have
argued
many
points
of
view
when
it
comes
to
backup-
and
there
are
many
points
of
view,
because
there's
also
the
point
of
view
of
the
best
they're,
the
most
secure
backup
that
you
can
have.
There's
no
backups
I
mean
I,
don't
necessarily
agree
with
it,
but
I
mean
I,
guess
so.
D
I
I
think
that
I
agree
with
Henrik
I
think
that
that
we
should
focus
more
on
supply
chain,
specifically
because
I
think
that
that's
an
entirely
separate
topic
about
backups
Integrity
of
backups
and
where
you
keep
your
backups
and
the
setup
of
backups
and
the
you
know,
there's
a
bunch
of
different
programs
that
you
could
use,
even
though
on
Linux
we
all
try
to
use
kind
of
the
same
stuff,
but
I
I
think
that
it
distracts
the
topic.
If
you
want
my
personal
opinion,.
E
D
No,
no,
please
go
ahead
because
all
bills
are
supposed
to
be
like
replicatable
on
everything
except
Gen
2.
Basically,
right
like
every
build,
is
reproducible
every
single
time.
You
should
get
this.
You
should
be
installing
the
same
thing.
So
theoretically,
I
mean
there
could
be
a
way
of
like
managing
package.
D
Integrity
I
guess
is
what
we
would
be
talking
about
and
like
backing
up
like
a
certain
setup,
I
mean,
but
but
it
would
be,
it
would
be
more
from
like
how
do
I
like
save
this
type
of
situation,
like
I,
have
a
setup
that
I
have
audited
I
feel
secure
about.
How
would
I
be
able
to
reproduce
this
setup
in
another
machine
foreign.
A
D
I
guess
it
depends,
you
know
it
really
like
like.
It
really
depends,
but
I
mean
yeah.
It
was
just
a
thought
that
I
had
as
far
as
going
as
far
as
like.
What
would
you
do
if
you
wanted
to
like
maintain
a
certain
package
set,
and
you
wanted
to
maintain
that
the
Integrity
of
said
package
set
on
the
developer
machine?
If
that
makes
sense,.
A
Yeah
this
this
rings
a
bell
and
I
think
of
an
attack
that
I'm
not
sure
whether
this
was
just
a
proof
of
concept
or
so,
but
here
basically
malicious
packages
were
able
to
modify
cached
packages
that
were
used
in
other
development
projects.
So
basically,
as
soon
as
you
start,
caching,
your
downloaded
stuff,
such.
B
A
D
E
A
D
That
would
be
a
separate
threat
because,
in
order
for
you
to
modify
the
caches
of
the
package
manager,
I've
I've,
if
I
remember
correctly,
you
would
have
to
physically
like
go
in
like,
for
example,
I.
Don't
remember
where
Gen
2
keeps
it,
but
we
there's
a
folder.
The
disk
files
is
what
we
call
it
dis-
files
and
basically,
all
the
all
the
installer
files
and
whatnot
that
get
downloaded
by
Portage
yeah
put
in
that
folder.
D
D
A
C
A
B
E
A
A
A
D
A
D
So
I
think
that's
where,
like,
if
you're
going
to
be
a
safe
user,
no
matter
what
you're
doing
you
have
to
know
what
you're
installing
so
I
think.
That's
where,
like
the
trust
but
verify
ideology,
comes
into
play
because
at
the
end
of
the
day,
it
doesn't
really
matter
how
good
of
a
supply
and
system
you
design
if
you're
never
actually
going
to
Care
to
like
understand
what
you're
installing
and
how
it
got
to
your
computer,
then
it's
all
kind
of
really
pointless.
Isn't
it.
A
Yeah
I
think
we
we
started
having
this
discussion
last
time
as
well,
and
I
reflected
this
in
this.
This
bullet
point
here
that
I'll
just
highlight
I
wonder
whether
yeah,
whether
whether
to
phrase
this
as
a
threat
or
maybe
rather
maybe
educate
developers
and
and
teach
them
this
principle
of
trust
but
verify.
C
D
D
And
just
to
point
out
Henrik
the
reason
that
I
really
say
this
is
because
this
is
kind
of
a
ongoing
issue
point
between
packagers
and
users
that
we
Cur
we
have
at
all
times
because,
as
I
said,
a
lot
of
people
do
think
that
packagers
have
the
responsibility
to
keep
you
safe
and
it's
kind
of
like
we
do.
But
we
don't.
You
know
what
I
mean
yeah.
A
D
Right
and
I'm
not
going
to
lie
to
you
that
sometimes
it's
a
lot
of
in
the
attitude
of
the
packaging
teams
as
well,
because
a
lot
of
packaging
teams
will
have
this
attitude
of
like,
and
this
is
why
I
say
this
they'll
say
it
like
trust
but
verify
but
they'll
say
it
but
like
in
a
much
meaner
way
and
kind
of
make
it
like.
But
it's
your
fault.
And
how
could
you
not
do
this,
so
you
get
what
I'm
saying
like
yeah.
D
A
Yeah,
it's
just
just
not
I,
don't
know
this
whole
verification
as
much
sense
as
it
makes
it
is
just
so
unrealistic.
At
some
point,
I
had
a
look
earlier
today
at
the
Transformers
library
or
package
that
comes
from
hugging
face
and
it
has
like
2
000
dependencies
yeah.
Good
luck,
very
fine.
This
I
mean
but
yeah
I
mean
that
we
can
have
those.
A
D
D
And
let
me
also
say
this
Henrik
I
think
also
in
terms
of
this
getting
Mass
adoption
and
whatnot
I.
Think
what
one
of
the
big
pieces
of
feedback
I
get
at
a
lab
sometimes,
is
that
open
ssf
likes
to
Champion
a
lot
of
things,
but
they
don't
realize
that
security
has
been
an
issue
since
Linux
has
been
open
sourced
in
1991..
D
Like
I
won't
name
specifics,
but
I
know
of
a
package
manager
that
just
uses
a
shot
at
256
on
a
package
and
that's
what
they
call
security.
It's
just
drawing
things
left
and
right
and
at
the
end
of
the
day,
if
the
downloaded
package
shawl
matches
the
one
that
we're
delivering
then
in
past
security-
and
you
see
that's
that's
what
I'm
saying
like
it's
it's
difficult,
because
there
are
different
generations
and
I'm
sure
that
may
have
worked
at
the
time
when
that
was
implemented.
A
E
A
E
D
E
For
example,
they
are
there's
a
another
organization,
independent,
sometimes
in
its
foundation
it's
called
open,
compute,
Computing
Foundation,
so
one
of
the
threats
they
have
identified
is
firmware
virus
no
out
of
virus
or
sturdy
risk
that,
after
even
if
you
like,
if
your
laptop
authenticated
using
species
Inspire,
for
example,
and
the
it's
possible
for
this
firmware
to
trigger
a
reboot
right
after
reboot,
the
it
can
be
remotely
controlled
so
by
the
by
the
actor,
I
guess
hacker,
so
I
I
can
bring
up
that
post.
That
link.
E
E
B
E
A
D
Now
let
me
say
this:
let
me
say
this:
there
are
firmware.
That's
in
the
Linux
kernel
gets
meticulously
like
audited,
so
I
would
say
also
to
keep
I
mean
if
we're
talking
about
Linux,
specifically
most
firmware
like
should
relatively
be
safe,
but
it
kind
of
goes
under
that
install
but
verify
I
would
say,
because
you
gotta
figure
out
like
do
I,
have
the
right
firmware.
D
D
Those
are
the
dkms
Dynamic
kernel
modules,
which
is
really
the
ones
that
you
need
to
be
careful
of,
because
those
are
the
kernel
modules
that
can
get
loaded
on.
The
Fly
could
be
a
problem,
but
this
is
where
the
kernel
has
like
signing
and
stuff
like
that
that
you
can
Implement,
depending
if
you're,
building
your
own
kernel
or
not.
D
B
A
E
E
F
E
But
the
basically
they
take
the
responsibility
away
from
the
end
user,
but
underneath
the
the
cloud
itself
still
have
the
same
consideration
concerns
right
so
similar
to
here
firmware
yeah.
In
most
cases,
user
developer
shouldn't
need
to
worry
about
the
firmware
now.
Is
it
in
scope
to
consider
it
who's
responsibility?
It
is
to
consider
it
then.
D
That's
a
fair
point,
but
here
here's.
What
I'm
saying
is
that
like
we're
talking
about,
for
example,
a
version
of
firmware
that
has
a
specific
problem
like
how
would
a
user
go
about
controlling
that?
Because
in
most
districts
that
I
know
you
either
install
the
firmware
per
vendor?
Or
you
just
install
this
one
huge
package
that
is
just
firmware.
E
D
Let
me
say
this
Victor
I
think
they're,
referring
to
like,
if
you're
using
like
yakto
project,
to
basically
create
like
an
in
like
an
embedded
operating
system,
then
I
think
then
that
would
be
when
you
would
do
this,
because
you
would
have
control
over
everything
in
like
yocto
project,
which
is
similar
to
Gen
2.
But
it
would
only
be
in
those
scenarios
that
you
would
actually
have
control
over
this.
D
E
D
B
D
Does
but
like
how
useful
is
that
legitimately,
and
do
you
be?
Would
you
would
be
one
out
of
like
two
people
that
do
it
so
I
mean
unless
of
course,
you're
using
again
Gen,
2
or
yakto
project,
because,
for
example,
in
Gen
2,
you
can
select
the
firmware
that
you
want
to
have
it
or
you
want
to
carry
on
your
system
and
yakdo
project?
You
can
do
that
as
well,
because
basically
you're
doing
essentially
Linux
from
scratch
and
building
an
immutable
image
with
everything
for
your
embedded
device.
D
That
should
be
somewhat
tamper-proof,
so
you
know
so
so
in
those
scenarios
absolutely
but
like
here
so
I
guess
the
question
Henrik
that
I'm
proposing
is
do.
Is
this
a
developer
like
because
we're
talking
about
developer
machines?
So
if
we're
gonna
to
talk
about
developer
machines,
I
would
almost
argue
that
that
wouldn't
be
in
scope.
They
were
talking
about
embedded,
embedded
programming
and
embedded
devices,
then
that
would
be
in
scope.
D
E
E
I,
don't
know
yeah
what
I
mean
is
I,
think
it's
possible
to
exist,
just
treat
it
likes.
Insiders
thread,
because
this
the
mitigation
for
this
firmware
risk
basically
means
the
the
the
corporate
policy
in
the
network
policy
will
not
allow
like.
If
you
build
your
own
laptop
right
using
any
firmware,
those
Hardware
will
not
be
allowed
into
the
corporate
Network.
E
A
It
goes
a
little
bit
in
the
same
direction
than
the
thought
that
I
had
that.
Interestingly
in
such
bigger
development
organization,
I
suppose
these
are
completely
different
teams
and
responsibilities
right.
So
you
have
one
group
of
people
that
tell
developers
how
to
securely
develop
whatever
software
application,
and
then
you
have
an
entirely
different
team.
A
D
Me
just
say
this
real
quick
Henrik
that
I
have
had
that
point
of
view
for
many
years
and
in
my
almost
10
years
of
being
a
packager
I
have
yet
to
find
a
company
that
actually
has
a
a
like
team
that
oversees
their
packages
or
that's
like
hey.
Let's
look
at
all
of
the
patches
that
we're
using
and
make
sure
that
there's
no
junk
in
them
or
anything
I've,
never
foreign
I,
haven't
met
anyone
yet
so
I
I
would
say
in
theory.
D
A
No
yeah
I
didn't
I
didn't
want
to
say
that
there
are
teams
in
such
organizations
that
vet
each
and
every
version
I
completely
agree.
This
is
happening
not
very
off,
not
to
say
very
seldomly.
What
I
meant
is
that
those
Central
Security
teams
care
more
for
the
the
security
in
the
application
development
life
cycle
right.
A
They
they
organize
and
prescribe
the
static
application
scanners
to
be
used,
or
maybe
some
Dynamic
scanners
to
be
used
and
they
teach
them
the
secure
development
practices
and
all
this
on
the
level
of
the
application,
and
this
group
is
completely
different
from
the
ones
managing
the
the
low
level
systems.
Basically
correct.
D
A
A
They
are
not
in
control,
and
they
cannot
do
much
about
the
lower
operating
system
level
through
which
some
malicious
stuff
can
also
come
in
and
I'm,
not
sure
whether
the
it
teams
are.
You
know
on
the
same
page
in
regards
to
the
consumption
of
third
party
stuff.
So
that's
that's.
Why
I
find
it
an
interesting
point
here,
you're.
F
A
A
I
don't
know
there
were
different
experiments
in
Germany
I.
Remember
one
from
the
city
of
Munich
I
think
many
years
back.
They
they
went
away
from
Windows
in
order
to
deploy
Linux
systems
all
across
the
city
systems,
but
after
I
think
a
number
of
years.
They
went
eventually
back
to
Windows,
but
it
took
them
a
couple
of
years.
A
D
D
A
A
D
B
A
So
I
wonder
whether
we
can
actually
turn
this
into
maybe
make
this
so
rather,
this
was
very
particular
for
malicious,
third-party
firmware
and
Hardware
I.
Wonder
whether
that's
worthwhile
transforming
those
thoughts
we
had
into
a
more
into
another
thread
or
a
general
thread
such
as
this.
This
split
between
organizations
caring
for
different
parts
of
a
stack
one
for
the
development
one
for
the
operating
system,
and
that
this
is
resulting
in
less
oversight.
Let's
say.
A
D
Henrik
for
next
time,
I'm
going
to
see
if
a
colleague
of
mine
being
is
available
to
come
to
this
call,
he
does
a
lot.
He
doesn't.
He
knows
a
lot
of
people
in
the
colonel
knows
lioness
and
everyone,
but
he
does.
Although
the
training
for
security
Kernel
wise
and
for
LF,
like
he
got
space,
his
main
job
is
to
maintain
that
stuff.
D
A
That
sounds
interesting.
I
would
also
love
to
have
a
seat
back.
Maybe
on
this,
this
research
that
was
done
by
the
by
some
U.S
University
a
couple
of
I
think
one
or
two
years
back
where
they
tried
to
basically
suggest
malicious,
pull,
requests
and
checked
whether
they
were
caught
by
the
reviewers,
and
it
was
a
large
debate
about
this
going
on
I'm,
not
sure
whether
you're
aware
of
that.
A
A
E
D
A
No
but
I
think
what
it
but
I
think
what
Victor
meant
is
that
we
have
so
I
can
I,
guess
technically
you
you
you
can
handle
this
I.
Don't
have
any
doubt
about
this,
but
more
from
an
organizational
point
of
view.
When
you
happen
to
work
in
an
organization
that
manages
those
operating
systems
for
the
development
Workforce
that
what
are
the
typical
challenges
and
problems
that
they
face.
I
think
that
is.
D
D
A
All
right,
I
think
one
I'm,
not
sure
one
thing
that
I
I
find
is
not
sufficiently
reflected
is
about
what
I
mean
here.
We
we
speak
of
operating
system,
productivity,
software,
Ides,
plugins
and
so
forth,
and
so
here
in
the
diagram
on
the
right
hand,
side.
We
very
well
say
this
is
kind
of
across
the
whole
software
stack.
But
if
we
look
on
the
left
hand,
side
we
stay
very
generic
and
high
level
without
I
would
be
nice
to
have
examples
of
all
the
different
cases
in
order
to
give
it
some
meat.