►
From YouTube: Securing Critical Projects (April 22, 2021)
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
And
it
should
be
recording
once
the
recording
button
turns
red
in
the
upper
corner.
There
we
go
cool
and
so
now
we're
recording
so
welcome
everyone
to
this
week's
working
group
securing
critical
projects
working
group
meeting.
I'm
sharing
the
agenda
today
or
the
the
meeting
notes,
so
we
usually
sign
in
everyone's
names.
So
we
get
to
know
each
other
and
it's
a
light
agenda.
So
I
guess
maybe
I'll
just
do
a
call
for
topics
right
now.
If
anyone
has
something
they
want
to
add
or
discuss.
A
A
All
right
cool,
so
yeah,
so
josh
added
something
here
about
talking
about
the
package
feeds
project
and
I
know
we
have
a
few
people
on
the
call
that
have
some
context
of
that
project.
So
josh,
do
you
want
to
talk
about
your
proposal
and
you
can
take
over
the
screen
too.
If
you
want
to
present
something.
C
Sure
yeah,
so
I
don't
know
how
many
of
you
are
familiar
with
the
package
vids
project,
it's
something
that
my
colleague
tom
and
I
have
got
involved
with
recently,
and
we
put
this
document
together
to
kind
of
highlight
some
of
the
changes
that
we'd
like
to
see
in
the
project,
and
you
know
how
that
might
fit
into
stuff
that
might
be
useful
to
everyone
else
and
we've
kind
of
pushed
that
through
last
week.
C
Some
discussions
with
dan
and
jordan
ended
up
pushing
forward
to
that
getting
done.
We've
actually
implemented
most
of
this
now,
but
I
will
quickly
just
try
and
share
my
screen.
C
Yeah
yeah:
it's
it's
fine!
If
you've
already
got
the
sharing
going,
it's
just
a
brief
document
with
kind
of
our
initial
understanding
coming
into
the
project
at
the
top,
which
may
be
useful
for
anyone,
who's
not
familiar
with
the
project
and
how
it
works
and
that's
how
it
is
currently
and
then
at
the
bottom.
We've
got
some
listed
features
that
we
would
like
to
see
and
have
have
spent
the
last
week
or
so
working
on
trying
to
add
so.
C
So
one
of
the
main
things
that
we
we
have
here
is
we
it
ingests
package
updates
from
several
package
repositories
so
that
those
can
be
fed
into
other
services.
Currently
package
analysis
is
an
example,
repository
of
that
that
is
consuming
them,
but
in
theory
it
could
be
anything
and
the
problem
we
one
of
the
problems
we
face
is
the
fact
that
these
feeds
pipe
ruby,
gems,
nougat,
etc.
C
They
are.
Some
of
them
are
lossy
so
to
highlight
that
as
an
issue,
you
know
if
we,
if
we're
ingesting
those
for
a
service
which
is
critical
to
our
systems,
and
we
can't
afford
to
have
a
missed
update,
say
pipe.
I,
for
example,
takes
the
last
50
updates
and,
if
you've
not
polled
fast
enough
or
say,
51
packages
have
been
released
in
the
past
five
minutes,
there's
no
way.
You're
gonna
you're
gonna
be
able
to
pull
fast
enough
to
catch
everything.
C
So
one
of
the
things
that
we're
looking
to
do
there
is
to
one
minimize
that,
in
the
case
where
we
have
identified
identified,
implementations
that
have
that
issue
by
say
for
pi
pi.
If
we
have
specific
packages
that
are
of
issue
to
us-
and
we
want
to
monitor
those,
we
can
monitor
those
specifically,
rather
than
just
checking
the
fire
hose
of
every
update
in
pi
pi,
and
that
can
help
to
minimize
loss
on
a
subset
of
packages.
C
Obviously,
that's
not
feasible
for
the
entire
entire
repository,
but
given
the
current
availability
of
pi
pi
apis,
that's
the
best
we've
got.
I
believe,
there's
some
work
in
progress
to
kind
of
improve
that
maybe
on
several
fronts,
but
it's
not
really
feasible
right
now,.
C
So
we
have
that,
but
we
all
we
also
have
some
efforts
towards
kind
of
just
identifying
that
you
know
we're
we're
trying
to
improve
the
logging
for
that,
so
that
when
this
does
happen,
if
we've
identified
there's,
you
know
the
the
possibility
that
data
has
been
lost,
then
we
can
at
least
log
that
and
try
and
monitor
you
know
which
feeds.
C
This
is
an
issue
for
whether
it's
pi
pi
npm
and
then
look
to
improve
that
in
the
future
and
maybe
push
upstream
repository
maintainers
to
kind
of
have
apis
available
like
say
php
packages
actually
allows
you
to
query
all
of
the
package
updates
since
a
certain
time,
which
means
you
don't
really
have
these
issues
because
you
tell
it
when
you
want
information
from
and
it
gives
you
it
and
then
we
have
some
other
minor
changes.
That
being
the
main
one
which
is
kafka.
You
know,
gcp
is
the
current
implementation.
C
C
Currently,
the
application
is
pulled
by
a
curl
request,
which
happens
on
a
timer
indeed,
in
google
cloud,
I
believe
obviously
we'd
like
to
kind
of
encapsulate
that
into
the
docker
image,
so
that
there's
no
dependency
on
a
third-party
service
to
ask
for
the
data
to
be
adjusted,
but
it
can
instead
just
be
done
on
a.
C
But,
like
I
said,
we've
we've
worked
towards
adding
some
of
these.
You
know
any
any
feedback
or
review
is
is
great.
If
anything
here
is
relevant
to
anyone,
then
we'd
be
interested
in
hearing
how
we
can
adapt
some
of
these
ideas
to
make
this
work
best
for
everyone.
B
D
You
need
it
sorry,
I
also
was
not
removed
so
yeah.
I've
not
contributed
to
this
project
in
the
past
and
in
particular,
the
composer
part
of
the
package
is
part
of
it.
I'm
just
wondering
how
you
would
like
feedback
to
this
like,
should
we
just
add
comments
to
the
google
doc
or
do
you
want
to
have
it
and
github
issues
or
something.
C
Yeah,
I
think
I
think
either
here
in
open
discussion
or
in
the
document
is
fine.
I
think
for
some
of
the
larger
topics
like
lossiness.
We
do
have
issues
open
for
those
that
can
be
added
to
and
if
I
think,
if
there
are
any
other
ideas,
then
I
mean
tom,
and
I
are
around
to
kind
of
hear
these
ideas
and
see
how
we
can
push
the
project
forward
with
that.
E
Just
to
jump
in
on
tom,
there
were
engineers
being
contributed
some
stuff,
so
we
have
been
looking
at
just
providing
general
updates
to
the
code
base
so
like
expanding
the
unit
tests.
One
thing
that
we
were
interested
in
is
knowing
that
the
data
that
we
were
getting
fed
from
the
publishers
we
could
have
a
reference
to
what
we
would
be
being
fed.
So
we've
pushed
through
some
work
to
provide
a
json
schema
of
the
date,
that's
being
dumped
on
the
wire
service.
E
So
that's
currently
the
implementation
is
a
kafka
publisher
or
the
gcp
publisher.
However,
that
could
be
expanded,
so
there's
a
semantic
diversion
schema.
Now,
that's
included
and
tested
again.
So
if
we
ever
update
the
ingester
to
add
extra
metadata
downstream,
subscribers
should
be
able
to
know
there's
a
change
in
what
that
changing
entails.
E
So
yeah
linkedin
is
obviously
a
thing.
We
want
consistency
so
we've
I've
pushed
some
linkedin
changes
today
to
try
and
get
the
code
base
in
a
consistent
state.
So
that's
all
if
anybody
really
wants
to
review
some
lint
changes.
Yes,
that's
that's
what
I
wanted
to
add.
A
Cool
all
right
back
to
the
agenda
here,
so
that's
linked
in
the
in
the
meeting
notes
and
also
the
a
link
to
the
github
project
too.
I
added
a
case.
Do
you
want
to
next
and
then
yourself.
F
Hi,
my
name
is
case
cook.
I
just
thought
I'd
pop
into
the
securing
critical
projects
bit
here
with
something
that
came
up
and
actually
reminded
me
of
a
little
while
ago,
but
I
think
it
comes
back
to
sort
of
a
a
global
issue
which
is
compiler
flags.
There's
a
lot
of
hardening
features,
enabled
that
can
be
enabled
by
compilers
and
that
affects
basically
everything
you're
building.
F
Of
course,
the
link
is
mostly
an
example
of
this,
but
the
the
issue
of
hardening
the
stuff
that
you've
built
is
certainly
not
new,
but
traditionally
these
flags
are
enabled
sort
of
in
package
management
and
not
sort
of
globally
for
the
compiler.
F
So
the
package,
if
you
built
a
package
through
a
distro's
package
management
system,
you'll
get
the
flags,
but
if
you
just
build
it
yourself
in
some
container
outside
of
package
management,
you
may
not
get
those
flags
and
I
think
that
that's
a
problem
since
we're
needlessly
exposing
you
know
hand-built
hand-rolled
stuff,
to
to
attacks,
because
those
features
are
off
by
default.
F
They're
only
turned
on
if
you're
inside
a
package
manager.
When,
when
I
was
running
the
security
team
at
ubuntu,
I
basically
demanded
from
the
compiler
team
that
those
be
on
by
default.
So
if
you're
building
your
college
program
or
if
you're
you
know
rebuilding
apache
or
nginx
or
something
on
your
own
outside
of
the
package
management,
you
would
still
have
the
benefit
of
all
of
those
security
features.
F
It
looks
like
ubuntu
and,
to
a
certain
extent,
alpine
are
the
only
distros
that
are
doing
this,
and
I
think
that
this
is
a
an
unusual
sort
of
a
a
gap
in
the
defenses
that
we
have
globally
and
it's
you
know
not.
This
isn't
about
any
specific
issue.
It's
just
that.
I
think
that
there
is
an
obvious
gap
in
in
defending
all
of
the
other
critical
pieces
that
someone
might
depend
on
inside
their
for
their
workload,
but
that
was
that
was
it.
I
see
a
hand
up
from
from
david.
G
Yeah,
yes,
indeed,
so
first,
I
think
your
new
case
I'm
a
big
fan
of
the
hardening
work.
Thank
you
again
for
what
you've
been
doing.
I
think
we've
talked
about
this
before,
but
I
think
it
might
be
useful
to
talk
about
it
again.
I
agree
with
you
that
the
defaults
should
be
all
these
hardening
measures,
but
I
don't
think
the
default
should
even
be
within
the
packages.
I
think
the
defaults
should
be
within
the
compilers
themselves.
Yes,.
G
No,
no,
no,
no!
No
you're!
Talking
about
the
distribution
of
the
compiler,
I'm
talking
about
the
from
the
gc
developers.
That
should
be
the
default.
If
you
really
really
want
an
insecure
build,
you
can
ask
for
it,
but
I
don't
know
many
people
who
think
you
know
today.
I
want
to
generate
an
insecure
build,
so
I
think
from
the
critical
project's
point
of
view,
can
we
press
that.
F
That's
a
yeah,
I
mean
I
completely
agree.
I
would
rather
have
it
on
in
the
upstream
compilers
themselves
than
each
distribution
of
it
right.
I
think
the
faced
with
the
developer
communities
in
gcc
and
in
clang
I
have
taken
the
more
practical
approach
of
saying
that
there's
almost
no
hope
of
making
that
change
in
the
upstream
compilers
they're,
very,
very,
very
conservative,
about
the
kinds
of
changes
they
make
there.
F
The
middle
ground
that
I
that
got
worked
on
a
little
bit
by
some
gen
2
developers
was
basically
adding
configure
options
to
easily
turn
this
on
and
off
in
compilers,
and
that
that's
probably,
as
far
as
we
can
push
it
right
now,
it's
sort
of
all
about
changing
what
you
know
what
everyone's
used
to-
and
you
know
I
ubuntu
made
their
compiler
changes
over
10
years
ago
and
I'm
still
waving
my
arms
on
this
one.
F
So
it
would
be
nice,
but
I
don't
think
we
would
ever
be
able
to
convince
upstream
compilers
to
make
this
change
without
also
turning
around
and
saying,
hey,
look.
This
is
literally
how
every
distribution
ships
your
compiler.
Why
are
you
doing
insecure
defaults
when
literally
everyone
else
on
the
planet
who
uses
your
software
uses
it
in
a
safe
fashion?
H
I
I
the
power
of
public
opinion
and
also
like
forcing
upon
them
a
cve
you
know
could
could
potentially
provide
some.
Like
you
know,
social
pressure
in
that
direction.
Maybe.
F
I'd
like
to
think
so,
but
I
mean
there's,
I
my
my
current
counter
example
again-
and
this
is
mostly
just
pragmatism-
I
think,
as
far
as
scaling,
what
we
can
get
done
and
what
we
can
accomplish
quickly.
The
counter
example
I
have
and
the
sort
of
strong
conservatism
I
see
from
gcc
and
clang
while
they
are
perfectly
well-meaning
they're,
mostly
defending
their.
You
know,
like
the
the
c
definition,
the
c
plus
plus
definition
and
one
you
know
one
cve
won't
do
it.
H
F
Yeah,
okay,
that
that
is
possible.
I
think
that
there's
yeah,
I
I
end
up
with
some
negative
outcomes
from
that.
G
G
F
Yeah
and
as
and
as
far
as
like
scoping
actual
work
to
be
done
here,
I
think
one
of
the
main
pushbacks
that
I
that
I
saw
again
this
was
some
time
ago
was
the
fact
that
the
features
weren't
considered
sort
of
expected
by
the
actual
compiler
itself.
So
when
the
compiler
would
run
its
own
self-tests.
F
If
you
built
the
compiler
with
these
things
turned
on
the
self
test
would
fail
because
they
were
expecting
slightly
different
layouts
or
slightly
like
there's
a
lot
of
corner
cases
that
would
get
broken
so
to
get
package
like
compiler
package.
Maintainers
to
accept
these
kinds
of
changes
in
a
distro
probably
requires
upstream
work
to
to
add
these
kinds
of
you
know,
configure
flags
or
whatever
that
make
it
a
first-class
citizen
within
the
upstream
compiler,
without
making
it
a
default,
but
just
making
it
possible
to
build
with
those
flags
enabled
by
default.
F
So
I
think
that's
where
the,
where
there's
sort
of
a
unit
of
work,
we
could
apply
to
solving
this,
and
then
we
turn
to
the
distros
and
say
you
see
it's
really
easy.
You
just
add
a
configure
flag
and
everything
still
works.
For
example,
I
believe
that
would
convince
debian,
because
that
was
their
specific
issue
with
it.
B
I
was
just
gonna
say
thank
you
for
pushing
this
one
and
two.
B
I
know
there
is
it's
a
small
number
of
developers,
but
I
know
there
are
developers,
at
least
in
my
company,
that
use
c
for
like
some
of
this
stuff,
that's
super
performance,
critical,
there's
like
firmware
stuff
or
there's
something
squirreled
away
and
some
teeny
tiny
little
piece
of
silicon
someplace
right,
and
so
I
often
have
to
do
a
lot
of
you
know
conversation
with
these
folks
to
say
no,
no,
no,
let's,
let's
be
right,
so
it's
yeah
undefined
behavior
is
is,
should
should
not
be
the
the
default,
but
that's
kind
of
a
war
that
I
I
I
get
to
fight,
but
the
and
probably
anybody
doing
like
hardware,
one
sort
or
another
has
to
deal
with
that.
B
B
When
we
talk
about
stuff,
that's
going
on
and
you
know
either
any
any
sort
of
software
we're
working
on
in
my
company
at
least
so
I
think
driving
that
back
is
a
great
idea
case
in
court,
according
to
you
which
of
the
distros,
we
should
target,
because
I
think
collectively
we
probably
have
enough
opportunity
to
influence
this
sort
of
things.
F
Well,
I
think
I
think
step
two
is
going
to
the
distros.
I
think
step
one
is
making
these
options
first
class
citizens
within
the
builds
and
test
case,
like
the
the
test
frameworks,
the
self-test
frameworks
that
the
compilers
have,
without
that
it
creates
a
lot
more
work
for
distros
and
it's
a
harder
sell.
F
Usually
you
end
up
with
separate
compiler
packages.
Like
I
think,
there's
you
know
the
gcc
for
avr,
for
example.
It
doesn't,
you
know,
is
it
going
to
turn
on
stack
protector
or
whatever
else,
so
I
think
on
a
but
for
for
non-specialized
stuff,
it
seems
like
by
default,
would
be
nice.
G
If,
if
I
can
jump
in
first
of
all,
I
I
did
some
embedded
in
the
past
and
you
know
I
remember
needing
an
eye
bleeding
number
of
options
when
you
actually
care
about.
You
know
how
many
bites
something
takes.
So
it
seems
to
me
that
having
to
turn
off
something,
you
know
having
to
add
extra
flags
for
embedded
process.
Oh
look.
The
world
is
just
the
same
as
it
was
five
minutes
ago.
F
The
complexity
yeah,
the
complexity
with
that
one
tends
to
be
that
you
end
up
with
a
different
run
time.
So
you
know
you
may
not
in
the
embedded
world,
you
may
not
have
a
libsy
at
all
and
some
of
the
features
like
fortify
and
to
some
extent
stack
protector
end
up
depending
on
your
runtime
as
well.
So
you,
you
know,
sort
of
have
to
lean
on
that
in
some
cases.
But
anyway,
that's
it's
really
a
few
of
those
as
corner
cases.
G
F
Right,
having
it
be
first
class
in
the
compiler
build
itself
means
that
it's
trivial
to
define
like
oh
this,
this
compiler,
we've
deemed
you
know
just
safe
by
default.
This
one
we've
deemed
you
know
specifically
for
having
as
few
features
as
possible,
because
you're
so
close
to
the
bare
metal
or
whatever
like
it,
makes
it
easy
to
make
those
changes.
G
Right
I
mean
if
we
can
make
it
easier
to
turn
on
and
off
sets
of
flags.
I
mean
there's
already
flags
for
sets
of
flags
anyway,
but
I
think
there's
a
step
zero,
which
is
sort
of
a
list
of
what
you
know.
What
would
you
like
to
see
see?
I
mean,
I
know,
there's
a
whole
bunch
of
lists
of
recommended
flags
anyway.
G
I
bet
you
could
probably
point
us
to
some
some
list.
Yeah.
F
Yeah
that
the
link
I
gave
was
the
example
wiki
that
that
ubuntu
publishes
about
what
their
default
flags
are.
Some
of
those
are
about
optimizing
their,
how
the
linker
behaves
and
some
other
things,
but
the
bulk
of
it
is
are
the
security
features
that
are
enabled
by
default.
F
Yeah,
I
think,
there's
only
one
that
yeah
there's,
I
think
the
last
two
in
the
flags
past
the
linker
on
the
ubuntu
wiki
are
probably
not
security
relevant,
but.
F
I
I
don't
have
much
opinion
about
them.
I
know
that
there
are
very
good
reasons
to
do
it.
It's
just
that
those
those
reasons
came
out
of
a
different
universe
than
where
I
was
looking.
B
Hey
by
the
way,
the
other
comment
I
would
make
by
the
way
I
I
you're
right
with
step,
zero
on
step,
one
and
step
two.
Okay,
the
other
player
out
of
this.
Have
you
have
you
there's
a
chap
named
ryan
ware?
Have
you
talked
to
them?
At
all
case?
You
know
who
I'm
talking
about.
B
There's
another
open,
ssf
work
group,
that's
working
on
security
tools,
and
I
think
he
just
picked
up
the
the
chairmanship
of
that
that
working
group,
so
I
think,
he's
usually
the
one
I
lean
on
on
flags
and
and
that
sort
of
thing,
so
it
may
be
good
to
kind
of
get
more.
I
I
don't
want,
I
think,
we're
responsible.
I
feel
responsible
for
this
right
as
a
work
group,
but
I
think
get
getting
more
work
groups
on
board
on
this
is
a
is
a
good
thing.
You're
smiling
david.
G
G
G
Right
now
case,
how
far
do
you
think
we
can
get?
I
mean
we
can
do
one
thing
where
I
know
the
package
managers
all
support
like
default
flags,
when
you
create
a
package,
can
we
make
it
so
that
when
things
are
compiled
on
the
typical
distro,
it's
automatically
with
these?
Without
I
I've
never
looked
into.
F
G
F
It
depends
on
how
you
built
the
compiler
in
some
in
some
cases.
Yes,
you,
you
can
specify
an
external
spec
file,
but
traditionally
well
at
least
where
I've
seen
it
that's
not
so
easy,
which
is
why
I
wanted
it
on
by
default.
In
the
compiler,
you
just
run
gcc.
G
F
Yeah
and
it
depended
like
the
way
debian
and
ubuntu
built
their
gcc.
It
didn't
look
like
you
could
specify
external
spec
files,
but
I
know
that
that's
one
of
the
main
ways
that
gentoo
back
then
turned
on
these
types
of
flags
is
through
their
common.
Like
they
didn't
change
the
code,
they
changed
the
spec
file
that
the
compiler
loaded
by
default.
So
I
think,
there's
a
bunch
of
different
ways
to
approach
the
implementation,
but
ultimately
it
looks
like
making
it
a
first
class
citizen
within
the
compiler.
F
Build
itself
is
probably
the
right,
the
right
step-
and
I
know
for
example,
gcc
gained
you
know,
should
I
enable
pi
by
default
as
a
configure
flag
somewhere
along
along
the
way
there,
so
that
all
got
sorted
out.
Okay,
but
many
others
remain.
G
Gotcha
yeah,
I
I
I
think
many
of
us
have
different
connections
with
different
different
linux
distros
that
probably
could
move
along
this
yeah.
I
know
the
the
alpine
folks
and
you,
you
know
the
ubuntu
folks,
I'm
sure
we
can
talk.
B
To
debian
and
fedora,
if
we
look
at
step
one
of
our
our
proposed
three
step
process:
okay,
steps
to
zero:
we've
got
to
figure
out
the
flags
right,
but
who
has
the
who
has
the
you
know
if
you're
going
to
add
these
things
as
first-class
citizens?
It's
it's
like.
It
helps
to
actually
push
the
code
right.
That's
right!
That's
at
least
you
know,
let's
do
a
pull
request
on
the
code.
That
would
do
that.
I
have
some
folks.
B
I
can
talk
to
that
work
on
the
gcc
and
and
llvm
projects.
I
I
playing.
I
could
just
you
know,
talk
with
them
and
and-
and
anybody
else
have,
that
kind
of
you
know
influence
to
start
that.
F
G
G
We
should
use
these
flags
in
these
circumstances
and
link
off
and
then
I
think
several
of
us
can
point
to
that
and
start
at
least
talking
to
see
what
we
can
do
for
the
next
steps.
I
know
that
the
I'm
actually
interacting
with
alpine
linux,
for
example,
they're
interested
in
making
some
improvements.
G
F
G
F
F
There's
and
and
mucil
specifically
does
not
want
a
fortify
implementation,
that's
specific
to
mucil.
So
there's
a
bit
of
a
political
question.
There.
F
F
It's
a
weird
position
to
be,
but
anyway
that's
an
example
of
the
technical
and
political
problem
that
needs
to
be
addressed
to
get
this
done
for
step.
I
don't
know
how
we've
numbered
it
now,
but
step
two
which
is
getting
into
this.
G
So
I
I
you
know,
you
know
what
I'm
hearing
case,
I'm
I'm
here
at
least
so
far
unanimous
agreement,
or
at
least
no
objections.
Yeah.
F
H
A
fair
enough,
I'm
also
thinking
that
if
I,
if
you
have
that
blog
post,
I
don't
think
that
gradle
automatically
supports
throwing
a
bunch
of
these
arguments
in
so
I'd
totally
like
you
know,
use
that
as
a
draw
like
add
all
those
defaults
to
gradle
2
as
a
as
as
a
you
know,
when
we
generate
the
the
compiler
calls
like
this
would
be
the
defaults
unless
you
set
some
manual
ones.
That
would
be
really
cool
addition
there
and
maybe.
A
H
F
I
I
I
would
support
such
such
ideas,
but
that's
not
I've.
I've
attempted
such
battles
in
the
past
and
it's
I'm
going
to
use
my
time
differently.
J
F
Anyway,
that's
all
I
just
wanted
to
raise
awareness,
and
apparently
now
I've
prepared
a
list
of
things
for
me
to
do.
Oops.
B
G
Yeah
but
but
although,
although
of
course,
I
always
view
success
when
I
manage
to
put
a
to-do
list
on
somebody
else,
oh
no
dave.
G
G
Yeah
but-
and
in
fact
I
think
you
should
be
able
to
just
point
off
to
to
things
rather
than
having
to
generate
things
from
scratch,
but
but
I
think
that
I
think
there's
definitely
an
opportunity
here.
I
I
think
more
there's.
I
think
that
some
of
those
battles
may
there
may
be
less
pushback
than
there
was
before
as
yeah
it's
it's
got.
A
G
You
you
know,
if
you
do
this
I'll
I'll,
be
happy
to
help
out
the
second
part
and
in
fact
case,
if
you
can
give
any
arguments
for
why
this
isn't
so
crazy.
Like
you
know,
you
already
mentioned
the
alpine
does
all,
but
one
of
these
you
know
any
argument
you
can
raise.
That
suggests.
You
know
that
that
some
folks
are
already.
G
There
would
be
great
well
a
to
try
to
work
with
with
mu
salt
and
and
or
alpine
to
try
to
fix
that
one
spot
left,
but
also
on
the
others
yeah,
and
I
know
that
fedora
turns
on
the
number
of
flags.
I
don't.
I
haven't
done
the
cross,
compare
with
what
you
which
you've
had
yeah.
F
Last
I
checked
they
turn
on
the
flags
in
their
package.
Build
systems
so
compiler
itself,
yeah
everybody
doing
like
regular
package
builds
turns
these
on
now.
So
you
know
that
that's.
That
problem
is
at
least
gone,
but
I
still
think
especially
given
the
sort
of
rise
in
containers
and
people
building
whatever
they
want
on
their
own,
as
opposed
to
depending
more
heavily
on
necessarily
packaged.
You
know
pre-packaged
district
software.
I
think
this
problem
is
sort
of
resurfaced.
F
Yeah,
or
at
least.
F
G
Feelings
about
that
yeah
I
think
we
may
have
to
drill
down
briefly,
I
mean
I
don't
think
that
should
take
days
of
research,
but
that
may
be
something
worth
exploring,
basically
finding
a
way
through
the
through
the
technical
desires
of
different
groups
to
get
where
you
want
to
go
right.
A
All
right,
I
think,
I'm
the
next
one,
so
the
agenda
was
light
today.
So
I
was
thinking
in
the
back
of
my
head.
What
else
could
we
use
this
time
for,
but
now
we
sort
of
filled
it
up,
so
that
worked
out
well,
but
I
just
wanted
to
either
have
a
discussion
or
see
if
there's
interest
in
maybe
turning
like
every
every
other
one
of
these
meetings
into
an
office
hours
of
sorts.
A
I
don't
have
any
idea
how
this
could
work
in
practice
because
I
just
thought
of
it,
as
as
I
was
driving
back
home
today.
I've
seen
it
work
well
with
other
specific
projects,
but
maybe
like
you
know,
we
could
do
more
of
a
public
announcement
of
it
and
the
projects
are
looking
for
security
help
or
something
like
we
could
come
together
and
sort
of
help.
So
I
don't
know
I
haven't
again.
A
L
G
I
I
have
to
admit,
I'm
a
little
afraid
if
every
open
source
project
starts
showing
up
at
once,
but
you
know
we
can
try
and
stop
if
it
turns
out
to
be
a
problem.
A
I
mean
I
just
structure
it
a
little
differently.
Maybe
we
pick
a
different
topic
or
typic
different
theme
for
each
each
session.
D
I
co-organized
the
kubernetes
office
hours
and
they
are
a
research
wednesday
where
people
can
just
come
by
and
ask
questions
hey.
How
do
I
use
kubernetes?
This
is
so
complex.
Please
help
me
figure
it
out
and
we
usually
start
by
saying
we
don't
have
access
to
your
cluster.
We
cannot
do
box
things
for
you,
but
you
can
try
to
formulate
your
questions
as
well
as
possible.
So
if
you
need
help
with
that,
I
would
be
happy
to
help
especially
also
the
streaming
setup.
D
D
So
we
roughly
average
100
viewers
on
for
like
one
hour
and
we
get
like
roughly
between
10
and
30
questions
asked
and
it's
like
it's
sometimes
very
overwhelming.
We
usually
have
a
panel
of
like
five
to
ten
people
that
try
to
answer
these
questions.
We
share
experiences.
D
Usually
we
try
currently
also
the
process
of
trying
to
roll
out
sick,
specific
or
like
work
for
you.
It
would
be
working
groups,
but
at
communities
it's
special
interest
groups
to
have
them
also
have
an
open
office
hours.
So
we
want
to
have
six
specific
office
hours
as
well,
so
like
whatever
there
is
in
terms
of
it's
like
okay,.
A
Yeah,
maybe
we
try
something
like
getting
questions
in
advance
or
something,
and
then
the
audience
can
sort
of
tailor
itself
to
who's
interested
in
helping
who's
interested
in
listening
so
yeah,
I
don't
know
if
you
have
ideas,
throw
them
in
this
dock
and
the
agenda
and
I'll
think
about
it.
Some
more
too
and
see
you
know,
there's
something
there
that
we
can.
A
Spearhead
and
yes,
lots
of
drama
in
the
news
this
week
on
security,
stuff
david
is
one
of
all
you.
G
With
that,
okay,
so
those
of
you
who
are
not
aware
there's
this
big
brouhaha,
some
university
of
minnesota
researchers
decided
to
start
sending
malicious
packages
to
the
linux
kernel
without
any
consent
by
the
people
being
experimented
on.
It
turns
out
that
you're
not
supposed
to
be
experimenting
on
people
without
their
consent,
but
they
did
it
anyway.
So
I
don't
know
so.
G
The
the
the
quick
answer
right
now
is
that
the
linux
kernel
folks
have
banned
university
of
minnesota
from
any
contributions
and
are
working
through
and
removing
a
lot
of
past
contributions
under
the
assumption
of
bad
unless
proven
otherwise,
although
in
theory
we
don't
know
if
that
they
attacked
anybody
else.
G
As
far
as
I'm
concerned,
this
is
fundamentally
unethical
behavior.
So
we,
since
they
didn't,
warn
the
linux
kernel
developers,
I'm
not
sure
I
should
trust
anything
else.
They
say
so.
F
They
they
wrecked
the
trust
and
they
ended
up
retroactively,
ruining
their
own
reputation
to
the
point
that
all
of
many
hundreds
of
what
appear
to
be
legitimate
and
good
faith
patches
are
being
reverted
from
the
colonel
or
at
least
under
threat
for
revert.
I
actually
spent
a
great
deal
of
time
yesterday,
attempting
to
map
their
commit
history
against
the
various
research
papers
that
they've
produced
over
the
last
couple
of
years
and
is
overwhelmingly
in
good
faith.
It's
all
legit
fixes
legit
security,
and
I
I
think,
with
other
people's
help.
F
We
found
the
the
five
attempts
they
made
it
at.
You
know
evil
patches,
which
were
sort
of
isolated
to
one
one
paper
and
does
not
appear
to
reflect
on
the
rest
of
it.
Although
there
is
a
question
about
sort
of
current
research
is
not
malicious
per
se,
but
looks
to
be
relatively
flawed
so
because
they
wrecked
the
trust
and
then
they
showed
up
with
bad
patches.
That
appeared
to
be
unintentionally.
G
Yeah,
I
don't
make
it
clear:
I'm
not
opposed
to
research.
I
am
all
for
research
hooray,
please
go
research,
but
you're
not
allowed
to
attack
systems
without
permission
of
the
owners,
you're
not
allowed
to
experiment
on
humans
without
permission
and
consent
by
the
humans.
These
are
kind
of
basic.
These
are
kind
of
basic
basics
and
I'm
ticked
david.
Do
you
know
if
it
went
through
institutional
review
at
the
university?
G
G
Doing
an
irb
is
exactly
not
okay,
and
now
I'm
going
to
be
clear.
I
am
not
a
lawyer
okay,
but
it
seems
to
me
a
pretty
clear
ethical
violation
and
possibly
civil
civil
and
criminal.
I
don't
know
that
I'm
not
a
lawyer,
yada
yada,
but
I
mean
this
just
is-
is
crazy,
stuff
right
now
I
did.
I
did
a
quick
search
on
the
ci
best
practices
badge.
We
don't
have
any
searches
from
anybody
from
university
of
minnesota
keith.
G
If
you
have
case,
if
you
have
a
better
set
of
things
to
search
for
so
I
can
I'll,
have
more
targeted
searches
for
potential
bad
actors,
because
I'm.
G
Yeah,
it's
just
you
know.
Basically
I
mean
you
know
so
that
we
can
look
at
the
commits
most
likely
to
need
re-review.
F
Right
yeah,
I
think
the
the
issue
is
that
of
regaining
trust,
because
I
think
the
bulk
of
the
the
vast
majority
of
of
patches
were
completely
in
good
faith
and
interested
in
facing
legitimate
bugs,
but
they
wreck
their
own
trust.
So
now
we
have
a
re-review
everything.
D
Actually
I
didn't
use
a
university
here,
yeah
right,
just
saying
that,
as
far
as
I
know
this
like
message,
I
said
you
look
for
from
university
of
minnesota,
but,
like
the
commission
comments
that
were
made
previously
were
like
not
used
using
this
email
domain.
G
Yeah,
it's
actually
not
just
james
bond
but
included
james
bond
in
there,
so
but
basically
yeah.
If
you
know
improvements
on
ways
to
detect.
G
We
lost
david
and
is
just
you
know
if
you,
if
you
do
anything,
I
had
to
go
through
irbs
to
do
surveys.
You
know,
oh,
my
gosh.
What
are
you
you
know
trying
to
insert
malicious
code
into
a
compiler
used
by
billions
of
devices
is
just
it
blows
my
mind
why
anybody
thought
that
was
okay
sounds
like
they're
doing
security
research
on
the
irb.
G
Yeah,
so,
as
you
can
tell
I'm
ticked,
you
know,
yes,
obviously
other
people
probably
have
submitted
have
attempted
to
submit
things
in
bad
faith,
but
if
you're
from
a
researcher
you
should
know
better.
F
Yeah
it's
funny
because
what
you
know
trying
to
figure
out
this
is
like
codes
of
conduct
are
mostly
designed
to
protect
contributors
from
other
contributors,
but
there
isn't
usually
any
language
to
protect
a
project
from
contributors.
F
So
you
like
this
now
presents
a
whole
new
social
thing
to
add
to
codes
of
conduct,
which
is
don't
don't
add,
malicious
code
like.
Why
did
that
need
to
be
said?
But.
G
I'm
actually
skeptical
that
that
needs
to
be
added
in
particular,
in
this
case,
it's
already
not
okay,
to
experiment
on
humans.
I'm
sorry.
M
H
So
if
you're
working-
so
you
know,
security,
researchers
right,
if
you
go
look
at
most
bug
bounty,
you
know
policies,
they
say
no
social
engineering
right
at
all
and
that's
because
the
security
team
usually
has
a
pretty
well
defined.
Like
you
know,
if
you're
gonna,
do
you
know,
pen
testing
against
our
firm,
like
you
have
to
get
hired
like
we
hire
an
external
firm
to
do
that
and
they
sign
a
bunch
of
legal
documents.
Saying
like
what's:
okay
and
what's
not?
Okay
and
the
scope
is
very
well
defined.
H
You
know
like
you,
so
you
don't
end
up
with
the
you
know
the
case
where.
Well
I
mean
there
was
the
case
at
the
courthouse
if
you
let
coal
fire
and
courthouse
and
ending
up
like
with
all
those
guys
getting
prosecuted,
you
have
to
be
really
really
careful
about
engagements
like
that,
so
those
are
not
usually
open
for
the
public
they're,
something
that
is.
It
is
defined
and
explicit
now
to
say
that
a
a
pen
test
of
the
linux
kernel
environment
that
the
linux
foundation
shouldn't
potentially
hire
for
that.
G
G
M
H
Okay,
are
we
done
with
the
previous
topic?
Yes,
okay,
so
I
am
in
the
process
of
making
my
way
through
how
to
measure
anything
in
cyber
security
risk,
which
is
a
really
interesting
book.
I'm
and
I
haven't
done
a
ton
of
look
at
like
the
oss
criticality
score,
but
doing
I
have
done
some.
H
I
like
downloaded
the
thing
and
looked
at
it
and
it
matches
like
your
intuition,
but
I'm
wondering
if
there's
been
any
exploration
of
like
checking
the
oss
criticality
score
against,
like
you
know,
common
ways
that
companies
have
actually
been
breached
right,
like
you
know,
what
is
what
are
common
attack
vectors
that
have
actually
been,
for
you
know,
ways
that,
like
comparing
always
says
criticality
score
with
like?
Is
this
actually
measuring
something
that
is
accurate,
or
is
it
totally
disproportionate
to
what
you
know
actually
causes
breaches
or
causes
data
loss
or
causes?
H
You
know
I
mean
struts
is
clearly
right,
like
a
big
one,
because
it's
caused
a
lot
of
pain,
a
lot
of
suffering.
You
know
a
lot
a
lot
of
data
loss,
not
pain
and
suffering,
but
data
loss,
and-
and
you
know
it's
great
to
say
well
this-
you
know
this
project
looks
important
right
versus
like
let's
look
at
the
historical
data
of
like
and
because
we
have
plenty
like
every
single
breach
that
has
occurred
right
that
has
had
any
significance
has
been
publicly
disclosed
and
for
a
lot
of
them.
H
There's
a
there's
a
like
this
is
you
know
the
root
cause
doing
that
kind
of
comparison?
Also,
you
know
in
general,
the
people
you
know,
people
that
are
directly
involved
in
that
book,
how
to
how
to
measure
anything
in
cyber
security
risk.
I'm
not
finished
with
the
book,
but
it
puts
a
very
compelling
case
on
why
metrics
and
ma
and
numbers
like
this-
should
have
like
scientific
basis
to
back
them
up
around.
Like
you
know
this
act,
this
these
numbers
like
have
been
proven
to
within
90.
H
You
know
like
within,
like
a
50
or
like
some,
some
percentage
point
range
like
have
it
have
a
have
a
50
chance
or
like
a
10
chance
or
whatever,
like
of
actually
accurately
representing
the
risks
in
your
supply
chain,
like
you
know,
giving
some
numerical
values
of
like
you
know,
probabilistic
like
how
how
accurate
are
these
numbers,
how
you
know
what
are
the
p
values
on
these
numbers
stuff
like
that,
so
yeah.
A
H
Oh
yeah,
well,
it's
in
the
channel.
I
linked
it
yet
a
couple
days
ago.
A
H
I
can
link
it
again
in
here.
I
can
link
it
in
the
in
the
meeting
notes.
A
I
just
added
a
link
that
we
started
and
didn't
really
go
anywhere
with
was
just
sort
of
similar
idea,
but
thinking
about
like
what
would
make
a
critical
project
like
a
security
critical
project
like
if
they
were,
you
know,
attacked
how
bad
would
it
be.
So
maybe
they're
not
that
popular
but
they're.
Actually,
you
know
not
maintained
by
anyone,
but
if
they
were
breached
they
would
have
massive
implications.
So
I
don't
know
if
there's
stuff
in
there.
I
haven't
looked
at
that
doc
recently,
but
just
ideas
and
stuff
to
throw
throw
in
there.
A
I
think
most
of
the
googlers
drop
that
work
on
that
project,
but
yeah
I
mean
certainly
open
to
you,
know
things
that
improve
the
criticality
criticality
score
project.
I
think
one
thing
we've
sort
of
you
know
have
been
learning
like
we're,
never
going
to
get
the
list
right
and
I
think,
there's
an
obvious
top
list
of
projects.
We
can
almost
start
with
amir's
on
the
call
and
came
up
with
a
list
of
you
know
critical
projects
that
need
some
help
and
we're
looking
at
trying
to
fund
some
remediation
there.
A
So
yeah
I
mean
this
is
interesting.
I
think
at
some
point
we
do
need
to
come
up
with
a
list
that
people
can
vaguely
agree
on
yeah.
H
Yeah,
the
authors
contend
that
that,
although
you
can't
get
anything
exact
you
can
get,
you
can
get
like
pretty
much
everything
into
a
probabilistic
state
where
you
have
a
probability
of
it
being
and
like
a
and
so
using
there's
a
I'm.
H
You
know
you
can
get
the
estimations
of
like
cost
and
things
like
that
into
a
really
well-defined
predictive
model
that
that
you
know
can
be
leveraged,
and
so
that
would,
I
think,
make
this
number
this
this
this
metric
more
useful
for
for
people
trying
to
incorporate
that
information
into
their
cybersecurity
model.
I
don't
know
the
book
is
incredibly
dense.
Incredibly
dense,
I'm
listening
to
it
as
an
audiobook
and
I'm
you
know,
but
I
I
still
recommend.
G
G
I've
read
the
book
as
an
audiobook.
I
don't
even
know
how
you
could
possibly
follow
it.
It's
got
all
these
charts
and
stuff,
so
it
is
interesting
and
you're
he's
and
jonathan's
right
about
the
monte
carlo.
Basically,
I
mean
one
of
the
key
things
that
they
did,
which
I
didn't
think
was
interesting.
G
Was
you
know
list
all
the
things
that
you
think
are
our
attacks
list,
the
probabilities
list,
the
range
of
damage
and
then
doing
monte
carlo
simulations
and
instead
of
getting
a
single
number
getting
a
graph
of
what
are
the
probabilities
of
different
damages
measured
in
dollars?
It
certainly
was
an
interesting
approach.
I
I
I'm
not
sure
how
that
could
be
applied
to
open
source,
but
maybe
I'm
just
not
being
creative
enough
about
applying
their
ideas.
So
it
is
interesting.
G
That's
for
sure,
when
I
work
with
the
government
with
the
us
government,
the
struggle
we
had
was
it
was
interesting,
but
a
lot
of
their
damages
are
hard
to
calculate
as
dollars.
So
that
was
a
cool.
I
don't
know
how
I
apply
this,
but-
and
I
think
the
same
is
true
right
now
for
me.
Thinking
about
this
for
open
source
but
sure
bring
them
on,
and
if
they
can,
if
we
could
connect
the
dots
together,
that
might
be
really
interesting.
Yeah.
H
If
you
could
compute
it
as
dollars,
then
you
could
say:
hey,
like
you
know,
if
you
want
to
offset
this
much
risk
for
these
open
source
projects
right
like
we
need
this
investment
right
like
that,
that's
a
good
selling
point
right.
It
is
not
like
you
know,
because
it
is
open
source
right,
like
there's
a
bunch
of
open
source
projects
using
it.
But,
like
you
know,
there
are
businesses
that
are
using
open
source
and
you
can
sell
it
to
them
as
like.
This
is
the
amount
of
c
financial
risk
you
are
introducing,
potentially
whatever
yeah.
A
Yeah,
it's
interesting.
I
don't
know
how
accessible
the
authors
are,
but
I
think
it'd
be
great
if
they
want
to
come,
give
us
a
tldr
of
their
book
and
we
can
think
creatively
how
to
apply
it.
G
A
All
right
cool
and
then
I
just
added
a
link
to
a
paper
someone
plugged
in
in
the
chat
which,
what's
related
to
this
all
right,
I
think
that's
a
wrap
so
good,
seeing
everyone
feel
free
to
add
agenda
items
for
next
time.
I
think
a
couple
of
us
have
some
homework.