►
From YouTube: CHAOSS Risk Working Group 11-19-20
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
B
I
am
particularly
interested
in
them
because
of
their
security
impacts,
because
you
know,
if
you
have
really
old
dependencies,
they're
more
likely
to
have
vulnerabilities.
But
you
know
people
are
interested
in
them.
For
other
reasons,
like
you
know,
maintenance,
sustainability,
that
sort
of
thing,
and
so
I've
been
poking
around
a
little
bit
and
I
did
find
a
a
metric,
in
fact,
a
metric
and
another
metric.
They
don't
mention,
but
I
think,
should
be
called
a
libya.
B
So
a
libya
is
a
very,
very
simple
way
to
measure
how
fresh
something
is
so
so
let
me
just
kind
of
verbally
explain
it,
because
it
really
isn't
complicated
if
the
current.
If,
if
the
version
of
the
software
that
you're
using
of
some
library
they're
using,
is
current,
then
it
has
a
libya
of
zero.
B
B
B
Absolutely
now
that's
actually
one
of
the
problems
with
the
beers,
so
one
of
the
so
in
fact
there's
a
webpage.
Thank
you
very
much
libya.com
where
they
pitch
this,
and
it
turns
out
a
lot
of
people
measure
this
there's
a
tool.
There
are
simple
tools
to
do
this
in
ruby,
called
libya.
Bundler
I've
actually
used
it
remarka
yeah
remarkably
simple
tool.
It
does
what
it
says
on
the
tin.
It
shows
what
what
what
that
one
does-
and
I
think
many
of
them
do-
is
they
list
everyone?
B
That's
behind
how
many
libyars
for
each
then
adds
them
up
now.
The
only
problem
with
this
now
no
metric
is
perfect.
Okay,
but
one
obvious
and
there's
a
citation
here
which
I've
actually
briefly
interacted
with
these
folks.
Unfortunately,
the
guy
who
led
that's
no
longer
doing
this
sort
of
thing
it
was
his
master's
thesis.
He
got
his
master's
now
he's
off
to
another
side,
but
I
did
contact
them
briefly.
What's
the
problem?
Yeah
go.
C
So
what
tool
is
he
using
to
basically
go
and
track
the
dependencies
through
here?
Is
it,
like,
you
know,
dependency,
check
or
something
else,
or
what's
that.
C
B
Well,
okay,
that
depends
well.
The
answer
is,
it
depends,
okay,
sure,
if
it,
if
it
is
being
brought
in
by
the
package
manager,
then
the
answer
is
yes,
even
if
it's
transitive,
if
it's
not
being
brought
in
by
the
by
the
package
manager
for
whom
it's
using
its
data.
So,
for
example,
let's
say
you're
using
an
old
version
of
a
standard
library,
but
it's
part
okay,
then
I
think
most
these
tools
would
not
include
that.
B
Okay,
now
that
doesn't
mean
that
you
can't
conceptually
include
it.
It's
just
many
of
these
tools
only
work
off
a
particular
repo,
but
you
know
what
you
know
right
now,
I'm
just
looking
at
this
more
generally.
So
the
problem,
one
of
the
problems
with
these,
though,
is
that
larger
projects
just
automatically
are
going
to
have
more
lib
years,
because,
if
you
add
them
up,
if
there's
a
thousand
dependencies,
I
mean
that's
it.
I
think
in
some
ways
this
grossly
penalizes
projects
so
I've.
B
I
looked
at
this
and
said:
that's
an
interesting
idea,
but
why
are
they
measuring
the
total
that's
kind
of
silly?
Why
don't
they
report
the
average,
because
all
you
have
to
do
is
take
libya
divide
it
by
the
number
of
components.
B
Now
you
have
an
average
libya.
I
mentioned
this
to
the
ruby
bundler
of
the
libya
bundler
folks,
which
do
a
ruby
implementation
and
they
said
yeah,
that's
easy.
I
mean
they
already
have
to
count.
They
already
have
to
identify
the
components
they
already
have
to
total
up.
Libyars,
that's
the
hard
part,
you
know
divide
a
by
b.
B
That's
easy
so,
and
I
actually
did
this
for
one
of
my
projects
and
it
actually
helped
me
find
immediately
some
things
that
were
older
than
I
was
expecting
and
I
managed
an
improvement
now,
I'm
not
advocating
that
this
is
necessarily
for
you
know,
chaos
to
include,
but
I
am
saying
that
this
is
one
and
one
of
the
easiest
metrics
I've
seen.
That
might
be
useful.
If
somebody
does
some
studying
first
to
see
how
useful
this
is,
I
mean
I
I
did
it
for
one:
google
measured
it
for
one.
B
A
A
B
But
yeah
I
would
be
interested,
but
I
I
think
you
know
the
last
two
meetings
have
been.
How
do
you
measure
this
stuff?
And
I've
also
brought
this
up
briefly
with
the
with
some
folks
in
a
and
in
the
open,
ssf
metrics
group,
and
that's
where
one
of
the
googlers
actually
measured
libyars
on
their
project
and
and
calculated
out
some
things?
So
you
know
this
doesn't
mean
it's
the
be
all
end
all
but
found.
A
A
D
Mean
back
to
olivia,
I
was
going
to
say
I
like
the
average
comment,
because
I
feel
like
that
versus
a
total.
I
think
it
helps
to
normalize
it
a
bit,
but.
D
Taking
an
average,
then
you
could
also
look
at
the
live
year
per
component.
So
if
it's
a
huge
project
like
kubernetes
having
one
number
doesn't
really
make
sense,
you
probably
want
you
want
that
number
for
all
of
the
sub
projects
right
so
like
and
then
then
the
average
becomes
the
standard
number
across
all
of
them.
D
So
there's
your
average
and
then
within
each
component
you
have
the
average
of
those
components
and
then
you
have
general
relative
freshness
or
however,
whatever
your
word,
you
want
to
use
as
a
metric
that
you
can
aggregate
at
both
the
low
and
high
level
and
then,
when
you
have
a
low
level,
then
it
is
very
actionable
and
then
the
top
level
it's
an
overall
risk
metric.
So
I
kind
of
like
that.
A
lot.
B
Yeah,
I
I
I
think
doing
it
by
that
transitive
closure
and
following
through,
might
I'd
have
to
think
through
that
because
there's
some
complications
when
you
do
that
mathematically,
but
I
will,
I
will
say
you
mentioned
hey
drill
down
as
well
as
just
hey.
I
do
account.
I
then
said:
hey
give
me
a
sort,
show
me
the
worst
ones
you
know
in
order
and.
A
B
The
libya
bundler
was
what
I
use,
but,
but
you
know
in
order
to
calculate
this,
all
of
those
have
I
mean
I
don't
know
if
they
can
show
them,
but
all
of
them
have
to
be
able
to
do
that
because
they
have
to
calculate
for
each
one.
You
know
how
old
each
one
is
and
having
a
report
of
tell
me
the
oldest
ones,
in
reverse
order,
as
well
as
a
total
and
an
average.
B
I
I
think
would
be
useful
and
maybe
the
you
know,
maybe
by
grouping
it
by
transitive.
Closure
might
also
be
interesting,
but
I
think
that
will
be
more
complicated.
A
E
It
in
terms
of
like
okay
library,
current
version
latest
version
and
the
live
year.
If
you
can
click
that
and
in
there
they
are
calculating
the
lib
here,
but
I'm
trying
to
understand
how
they
are
calculating.
It's
just
a
version
like
different
versions.
Is
there
any
date
option
yeah?
Can
you
scroll
down
a
little
bit
more.
A
Yep
yeah,
this
is
the
yeah,
so
this
is
interesting
because
some
of
the
more
contemporary
ways
of
using
python
have
the
requirements
embedded
in
a
setup
file.
A
A
E
E
B
B
Yes,
that
too
used
it
many
years.
So
if
you
look
at
the
paper
on
from
libya
on
the
on
the
libya.com
site,
they
actually,
if
you,
if
you
read
the
paper
by
cox
at
al,
they
actually
measure
freshness
in
multiple
ways,
including
one
two,
that
use
versions
as
the
metric
and
in
fact
several
of
these
tools
also
do
versions.
B
The
problem
with
the
versions
metric
is
that
assumes
that
version
numbers
have
the
same
meaning
for
everybody
and
I
think
in
some
communities,
that's
almost
true
because
they
they
prefer
semver,
but
I
think
that
that's
kind
of
dubious.
B
I
I
frankly
I'm
not
convinced
because
version
one
and
version
two,
some
you
know
if
you
follow
semver
every
time,
an
api
changes
you're
supposed
to
update
the
major
version,
but
that
major
version
change
may
have
very
little
to
do
with
being
updated,
and
you
know
so.
It's
not
clear
that
that
paying
attention
to
version
numbers
really
makes
much
sense,
whereas
the
dates
I
mean
the
advantage
is
at
this
particular
date.
I
can't
update
any
sooner
than
today.
D
B
D
In
the
in
the
version
argument
too,
I
mean
there's
been
some
research
around
average
release
stability
so
having
the
latest
isn't
always
the
most
stable.
So
if
we're
talking
about
this
as
a
potential
factor
of
risk
and
stability
within
your
code
having
the
latest
version
of
something
isn't
always
an
indication
that
it's
the
most
stable.
D
B
Yeah
now
the
paper
that
the
paper
that
cited
down
there,
they
do
mention
a
little
bit
of
it
and
there's
a
quirk
well
quirkiness.
They
did
think
about
this
one
at
least
what
they
say
is
you
should
measure
it
from
the
version
you
should
be
at
which
is
carefully
not
defined
to
say
the
most
recent
version,
it's
the
version
you
should
be
at,
and
but
the
problem
of
course,
is
when
you're
doing
this
in
an
automated
way.
A
B
B
Yeah
I
will
say
that
as
soon
as
you
maintain
anything
for
a
couple
years,
worrying
about
oh
my
gosh,
I'm
using
stuff,
that's
too
new
is
probably
not
your
problem.
E
B
Yeah
I
mean
if,
if
you
remove
a
functionality,
it
may
change
a
whole
new
stem
version
december,
but
if
you
weren't
using
that
functionality
anyway,
it
it's
it's
a
non-event
right.
So
so
I
I
I
have
to
admit,
I
mean
they
prefer,
the
this
version
numbers
and
I
I
just
leave
they
pay
for
me.
I
think
they've
got
some
interesting
ideas,
but
the
version
number
emphasis,
I
think
just
leaves
me
totally
unconvinced.
A
A
B
B
F
So
I'll
make
a
comment
here.
So
I
I
like
this.
I
like
the
discussion
here
and
I
think
it's
important
to
keep
in
mind
that
a
lot
of
the
metrics
that
we
develop
here
in
the
chaos
project-
they're,
not
they're
value
free
in
the
sense
that
we
don't
say.
Oh
a
high
number
is
good
or
a
low
number
is
good.
We're
just
developing
the
metrics,
often
to
try
to
locate
people
into
something
that
they
should
be
looking
at,
and
it
often
requires
more
investigation
by
a
person
to
their
local
context.
F
So,
in
the
case
of
what
say,
sophia
or
kate
was
talking
about
that
that
that
the
with
respect
to
the
newest
version,
so
you
may
have
low
libyars,
but
that
would
be
something
that
is
particularly
relevant
to
them
versus
a
libya
of
or
ten
thousand,
and
to
your
point
david
earlier
like
if
you
have
a
thousand
dependencies
like
sure
like
a
a
non-average,
libya
is
going
to
be
crazy.
High.
B
A
B
Average,
libya,
you
know,
where's
the
notes
here.
B
Okay,
so
anyway,
you
know,
we've
been
discussing
a
topic.
I
found
something
that
might
be
relevant
to
the
topic.
F
So
on
that
note
too,
if
you
look
at
sean,
is
in
the
minutes,
if
you
go
to
the
top
of
page
two
sean
yes,
so
we
had
kind
of
this
conversation
about
dependencies
that
I
tracked
pulled
out
from.
I
don't
even
know
where
that's.
A
F
F
A
F
F
Yeah,
so
my
guess
is
that
we
had
talked
about
building
dependency
metrics
and
we
were
trying
to
capture
the
conversation
we
just
put
it
somewhere.
So
here
it
is,
and
so
we
do
have
one
metric
that
is
proposed,
which
is
the
number
of
dependencies.
A
F
A
B
F
B
I
have
to
admit
I'm
not
sure
I
would
care
about
the
direct
dependencies
if
there's
only
five
or
six.
Does
that
really
matter?
It's
the
transitive
ones.
In
my
mind
that
really
matter,
it's
all
inclu,
it's
all,
including
the
transit
dependencies,
because
it's
super
easy
to
convert
all
your
dependencies
into
one
dependency.
A
These
days,
where
libraries
depend
on
libraries,
libraries
and,
and
so
there
are
some
ecosystems
that
have
a
lot
of
transitive
dependencies,
and
there
are
others
that
have
fewer
sure,
but
note
like
I
would
use
node
not
as
a
just
as
an
example
of
a
dependency
that,
for
example,
auger,
has
that
on
the
front
end,
which
is,
it
seems
to
be
just
this
infinite,
well,
that
we
can
navigate
down.
E
B
C
I
think
it's
more
easy
to
gain,
but
I
think
most
people
don't
bother
gaming
it
and
so
in
the
sense
that
understanding
how
many
direct
dependencies
you
actually
have
is
useful
for
a
fan
out
perspective
and
I'm
thinking
of
a
container
example.
C
C
Is
that
what
you
mean
by
indirect?
Or
do
you
mean
by
something
that
is
selectively
called
at
some
per
some
points
in
time,
but
not
always
so?
Basically,
it's
bound.
I
think
I
think
I'm
looking
for
a
definition
of
indirect
dependency.
What
direct
definition
are
you
using.
A
A
B
A
A
F
B
B
A
Their
distinctions
this
is
this-
is
process
right,
the
so
it's
a
decision
to
walk
the
whole
dependency
tree
all
the
way
down
since
you're,
going
to
get
to
the
last
turtle,
basically
and
counting
those
in
account
of
those
dependencies
like
how
many
dependencies
are
there.
So
that's.
A
A
E
B
B
B
Sure,
well,
let
me
point
out
the
libyars
as
just
an
example,
because
I
think
that's
useful
you'll
notice.
Most
of
those
tools
are
language
specific
and
it's
not
a
mystery,
how
they
work.
The
the
pip
rot.
One.
A
B
I
I
can
assure
you
that
the
ruby
one
only
looks
at
ruby,
it's
looking
at
the
gem
file,
which
is
how
ruby
handles
inside
ruby
dependencies.
So
I
suspect
that
the
most
of
these
are
single
ecosystems
and
the
same
for
counting
up
the
dependencies.
A
number
of
these.
It's
really
easy
to
do
within
one
ecosystem.
B
If
you
want
to
cross
ecosystems,
that's
when
you
start
pulling
in
these
owasp
pools,
for
example,
and
there's
other
folks
who
do
it
too,
not
just
owasp
who
can
try
to
track
between
ecosystems,
but
it's
it's
more
challenging
kate
did
you
is
that
plausible
summary?
That's
plausible
I'll
tell
you.
E
I
have
a
question
on
the
adoption
of
the
metric,
maybe
not
that
direct
related
to
this,
like,
as
we
have
proposed
lib
years,
so
that
metric
is
developed
by
someone
and
as
a
chaos,
how
we
adopt.
If
somebody
has
already
developed
a
metric
and
how
we
inculcate
that
in
our
community,
like
okay,
we
just
write
the
same
metric
and
refer
it
to
the
author
or
we've.
E
A
We
did
it
with
project
velocity
if,
if
a
metric
falls
in
the
wilderness
and
nobody's
there
to
hear
it,
did
it
really
fall?
It's
it's.
Does
the
metric
have
utility
right.
C
B
A
A
So
there
are
limits
on
the
implementation,
but
the
idea
of
the
metric
remains.
I
think
it's.
It's
certainly
not
a
terrible
starting
point
and
looking
at
average
leviers
is
not
a
terrible
starting
point
and
I
would
think
like.
I
would
want
to
know
both
the
libya's
average,
but
I'd
also
want
to
know
the
version
behind
average
like
those
would
be
two
different
things.
B
Yeah
I
added
on
the
bottom
and
vi.
You
know
some
sort
of
sorted
the
the
id
the
worst
ones
you
know
give
me
give
me
the
top.
Give
me
the
ten
that
are
worse
sort
them
that
way,
and
that
way
you
know
it
give
me
an
idea
about
how
bad
things
are
so
number
of
dependencies
age
of
those
version
dependencies.
F
So
why
don't
I
propose
as
we're
approaching
time
that
I'll
start,
let's.
F
F
F
B
B
The
a
runtime
basically
tell
me
the
runtime
only
subset,
you
know,
you
know
basically
yeah.
A
B
Right
because
you
know
at
least
for
most
systems,
I've
seen
there's
a
whole
bunch
of
dependencies
that
are
involved
in
the
test
infrastructure,
and
so
on
that
you
don't
you're
not
going
to
use
them
in
runtime,
and
so
you
know
if
you're
worrying,
about
security,
for
example.
B
A
A
E
B
A
B
A
Cool,
thank
you.
So
the
next
meeting
that
we
have
would
be
sometime
in
early
december,
and
perhaps
we
can
continue
this
discussion,
then
kate.
Is
there
a
virtual
version
of
the
the
compliance
summit
happening
this
year,
yeah.
C
A
No,
it's
it's
really.
Thank
you.
A
Here
we'll
do
that
separately
and
yes,.
E
B
Okay
and
by
the
way,
I've
thrown
another
metric
into
the
hopper
as
f,
so
at
least
it's
there
for
discussion
at
some
future
date.
C
Thank
you
guess
what
guess,
who
gets
to
sit
there
and
record
your
talk
tonight
or
tomorrow.
A
C
C
F
A
No
actually
we're
right
at
time
now
so
we're
all
right!
You
you
all
as
well
bye.