►
From YouTube: Securing Critical Projects WG Bi-Weekly (March 23, 2023)
B
C
B
Well,
we
normally
start
at
like
five
after,
but
let's
go
ahead
and
get
going
so
that
we
can
get
as
much
discussion
as
we
can,
especially
if
there's
any
new
faces
here
today
that
wanted
to
introduce
themselves.
We
can
get
started
with
that,
while
people
join
yeah.
So
if
you've,
if
you're
new
here,
if
you
haven't
been
in
a
while
totally
optional,
feel
free
to
introduce
yourself
and
say
hello.
E
So
I
apologize
for
not
having
been
here
lately,
but
trying
to
try
and
do
my
best
to
rejoin
when
I
can
I'm
at
Intel
I
been
involved
in
open
source
for
a
long
time
launched
a
number
of
Open
Source
projects
like
the
Octo
project,
various
other.
You
know,
programs
I've
been
involved
with
over
the
years.
Some
have
been
pretty
successful
like
the
Octo
project,
others
have
just
sort
of
gone.
E
B
H
Hey
everybody:
my
name
is
Georg
I'm
with
Erickson
I'm
in
the
the
Erickson
Hospital
open
source
program
office
following
various
things
in
the
openness
and
stuff,
but
I
haven't
really
managed
to
join.
That
call
very
often
well
not
at
all
recently
because
of
collisions
and
other
things.
So
my
primary
objective
for
today's
video
just
to
to
again
get
an
an
overview
of
what
you
guys
are
discussing
and
doing
that's
that's
it
for
mind.
B
Yeah,
it's
up
to
them
up
to
people
if
they
want
to
introduce
themselves
so
yeah,
meeting
time
update
in
two
weeks,
we're
gonna
switch.
Our
we've
been
alternating
every
other
week
net
this
time
and
APAC
friendly.
So
in
two
weeks
we're
switching
our
Apec
friendly
time
to
a
different
time
because
of
daylight
savings.
I
haven't
updated.
The
calendar
I
need
to
update
that
to
those
of
you
that
are
new,
we
are
are
in
the
middle
of
updating
our
set
of
critical
projects.
B
We
have
a
group
of
projects
that
have
been
proposed
and
so
normally
like.
We
do
typical
working
group
meetings
where
we
have
proposals
for
discussion
and
we
discuss,
but
this
meeting
and
the
previous
one
and
the
next
one
are
a
little
special
in
that
we're
gonna.
These
are
working
meetings
and
we're
going
to
be
working
through
the
list
and
doing
group
consensus
and
voting.
So
any
insight
and
knowledge
you
can
bring
to
the
table
would
be
very
much
appreciated.
B
B
Right
and
so
for
those
of
you
that
weren't
here
last
time
or
the
a
couple
years
ago,
when
we
did
this,
basically
we're
looking
to
build
consensus
on
each
line,
whether
it's
critical
or
not
so
feel
free
anybody
to
kind
of
throw
out
an
argument
or
a
straw,
man
and
then
just
to
get
the
discussion
started
and
then
some
reasoning
but
yeah.
It
looks
like
this
one
was
recommended
when
we
just
did
a
quick
pull
of
the
highest
pulled,
Docker
containers,
and
this
one
was
the
one
that's
up
there.
D
A
lot
of
people,
a
lot
of
things,
depend
on
it.
There's
a
like
it's
pretty
much
a
consistent
set
of
dependencies
that
can
be
used
by
a
lot
of
different
operating
systems
and
languages.
So
I
I've
seen
it
quite
a
bit
around
and
different,
build
pipelines
and
in
different
things,
so
it
seems
pretty
highly
used,
especially
in
Docker
kubernetes
land,
even
in
Cloud
Foundry
land.
If
people
still
use
that
stuff.
B
D
B
B
E
Great
I
was
thanks
for
the
heads
up,
I
think
the
biggest
concerned.
We
probably
ought
to
have
with
any
of
these
systems,
but
basically,
what
it
does
is.
The
descriptions
is
very
good.
It's
it's
very
similar
to
the
Octo
project,
in
that
it's
it's
sort
of
a
combination
of
a
system
that
will
build
a
bootable
Linux
image,
primarily
for
embedded
devices.
E
The
main
concern
I
think
a
lot
of
times
for
the
embedded
world
is
folks,
will
just
create
a
device
and
throw
it
out
there
and
then
never
update
it
and
so
to
some
extent,
there's
a
bigger
meta
issue
than
just
you
know.
Do
they
have
you
know?
Do
they
have
somebody
thinking
about
security
and
updating
things
at
the
surface
level,
the
most
important
risk
on
something
like
this
is
that
are
they
really
on
a
good
Cadence?
For
you
know
up
so
I
I
I've
got
when
I
build
Linux
right.
E
It's
not
just
the
kernel,
but
I
got
a
collection
of
other.
You
know
stuff
libraries
commands
Etc
that
go
into
it,
and
so
the
quest
is,
is
that
being
you
know,
looked
at
to
update
the
you
know
the
components
of
the
when
I
see
when
cves
get
issued
or
when
there's
security
breaches
or
whatever
there's
a
you
know.
Cadence
of
these
things
coming
out
so
I
would
say:
that's
probably
the
biggest
risk
area
for
something
like
build
root,
and
it's
it's
surprisingly
fundamental.
So
I
would
say
you
know
again.
E
This
is
not
the
build
tool
itself.
What
it
uses
it's
more
like
the
the
Linux
it's
producing
can
have
you
know
if
it's
not
up
to
date,
it
can
have
you
know,
components
that
would
expose.
Potentially
millions
of
devices
to
you
know
to
open
security.
Actually,
so
I
would
say,
I
would
answer.
I
would
suggest.
This
is
a
yes
for
sure.
B
I
Okay,
so
then
I
I
just
say
that
I
mean
I.
Don't
disagree
this
important
but
I'm,
not
certain
that
we
should
be
considering
the
Pace
or
Cadence
of
releases
for
a
project,
because
that
seems
orthogonal
I
mean
what
we're
trying
to
decide
is
that
this
is
a
critical
project
and
then,
if
the
project
needs
additional
resources,
so
it's
it's
not
a
matter
of
whether
the
project
is
actually
functioning
well
or
not.
It's
a
matter
of
whether
the
project
is
important
as
consumption,
so
I,
don't
think
it's
the
inner
workings
governance.
E
No
I
I
hear
what
you're
saying
I,
but
because
the
you
know
I
guess,
the
question
would
be
even
today
now
I
I
admit:
I
I
haven't
worked
on
the
embedded
world
since
about
2016
or
so
so.
A
lot
of
stuff
may
have
changed
as
I
understood
the
the
landscape
of
all
the
embedded
devices
out
there.
There
was
a
sort
of
a
split
between
people
who
use
like
a
you
know,
Fedora,
or
something
like
that.
Just
a
conventional,
you
know
desktop
Linux
and
they
they
hack
it
till
they.
E
It
works
for
them,
they're,
folks
that
take
the
open
source
Android
project,
their
Folks
at
use,
the
Octo
project
and
then
there's
a
there.
There
are
some
that
will
use
build
root,
or
you
know
something
like
that:
a
lot
of
routers
and
a
lot
of-
and
you
know,
switches
and
that
sort
of
thing
use
build
root.
It
was.
E
B
E
Of
I,
don't
care
I,
don't
have
a
I,
don't
have
a
Clarity
on
that
one
again,
my
data
is
a
little
old
okay,
a
few
years
old,
five
six
years,
I
mean
I
I.
Think
it's
still
used,
but
I
couldn't
tell
you
how
many
people
are
it's
it's
a
pretty
simple.
You
know
setup
and
use
between
Builder.
You
know
the
project,
so
I
I
think
it's
probably
pretty
widespread.
I
could
ask
somebody
pretty
quickly,
though,
on
online
yeah,
pretty
fast.
E
B
A
A
B
B
D
B
A
B
A
A
D
C
B
Why
that's
why
it's
here,
I
think
one
of
the
questions
we
have
with
some
of
these
things
is:
is
it
used
in
important
systems,
you
know,
or
is
it
used
for
toy
projects?
I,
don't
know
about
caddy,
but
that
was
a
discussion
we
had
on
another
type
of
similar
thing
where
it
was.
You
know
a
simple
website,
type
of
thing
that
you
could
pull
like
a
Blog
and
run
the.
D
D
D
G
B
Yeah
yeah,
we
don't
want
to
necessarily
compare
two
things
but
yeah.
It
isn't
I
think
the
pull
count
is
a
good
metric
to
like
or
put
something
on
here
to
think
about,
which
is
what
we're
doing
like
we're,
not
necessarily
Auto
approving
anything
with
a
high
pull
count
but
yeah.
We
definitely
want
to
look
at
and
see
if
we
know
that
it's
something
that's
used,
yeah.
G
D
B
E
Cassandra
is,
of
course,
wildly
popular
it's
it's.
What
they
base
iCloud
on
Apple,
you
know
is,
is
one
of
the
largest
users
of
Cassandra.
It's
it's
a
Java
based
eventually
consistent
database,
and
it's
it
it's
super
critical.
Now,
since
Apple's
focused
on
it,
I
think
they're,
probably
not
going
to
have
any
worries
but
yeah.
It's
it's
incredibly
popular.
D
D
D
I
H
B
B
H
B
I
C
I
Don't
understand
what
you're,
even
trying
to
suggest
I
mean
in
the
sense
of
RPM,
as
a
package
made
with
the
software
may
be
critical,
but
RPM
is
not
itself
an
ecosystem.
It's
not
a
matter
that
I
can
take
an
RPM
for
one
Linux
distro
and
just
automatically
use
it
on
another
Linux
District.
It's
on
an
ecosystem.
B
Yeah
no
I
think
Randall.
We
need
to
focus
on
the
projects
like
if
it's
a
the
distro
would
be
like
the
packaging,
but
like
for
software
projects
would
be
the
code
and
then
yeah.
Let's
try
to
stick
to
the
ones
on
the
list
and
get
through
them.
We
get
we'll,
have
more
suggestions
and
voting
in
another
iteration,
but
yeah
feel
free
to
to
look
through
and
see
what
we
have
here
already
Josh.
You
have
your
hand
up.
C
J
Can
you
hear
me:
okay,
yeah
well
so
I'm
music
group,
so
I'm
just
trying
to
get
my
bearings
on
this
and
one
of
the
things
I'm
curious
about
is
what
the
purpose
of
the
list
is
just
so
it's
a
little
bit
clearer
when
we're
looking
at
defining
things
as
critical
or
not
what
the
criteria
there
are.
I
put
a
couple
of
questions
in
chat.
Oh.
B
J
B
I
But
if
I
don't
think
I
I
I
understand
Joshua's
question
and
the
basic
answer
is
that
they're,
the
this
is
a
working
group
in
the
open
SSR,
and
this
is
working
to
produce
this
document
of
critical
projects
and
exactly
the
pipeline
in
the
openssf,
how
it
will
be
consumed
and
how
this
information
will
affect.
Policy
is
not
completely
decided.
J
I
I
F
C
C
D
I
C
I
G
D
I
B
G
C
I
G
D
A
C
B
Yeah
I
think
we
should
consider
this
oci
line
is
essentially
around
C
and
and
redefine
it
agreed
and,
and
so
we're
saying
no,
because
while
the
specification
is
important,
the
Run
C
project
itself
is
just
it's.
It's
the
the
runtimes
are
splintered
currently.
Is
that
our
reasoning?
That
is
the
reason
yeah
sounds
good
to
me.
D
A
D
C
A
A
D
A
B
C
C
C
C
D
B
C
C
D
It's
one
of
those
important
but
not
critical
ones.
I
would
say:
oh
okay,
okay
containers,
as
I
said,
so
here's
the
thing
in
cks.
They
actually
want
you
to
know
like
run
times
and
stuff
like
that
and
content
containers
is
one
of
those
things
that
they
specifically
mention
as
like
standard,
and
you
should
be
considering
to
use.
So
that's
why
I
would
argue
that
it
is
critical.
I.
C
D
I
D
D
A
G
C
C
H
C
C
C
B
A
I
So
everybody
it's
like
work
through
some
of
the
the
easy
ones
and
because
we're
spending
a
lot
of
time
debating
stuff-
and
you
know,
like
you-
know-
come
to
kubernetes
jump
to
kbm
Linux
kernel
I
mean
there
are
lots
of
things.
We
can
just
sort
of
get
off
the
list
quickly.
Maria
DB.
We
already
said
it
was
the
top
one.
I
A
C
B
I
J
A
I
A
G
I
D
C
G
I
B
G
G
G
D
B
I
D
A
G
I
B
C
A
Thank
you
and
yes
and
I
I
think
that
was
a
good
approach,
maybe
because
it
does
seem
like
a
lot
of
these
will
probably
get
you
know,
General
consensus
on
pretty
easily
and
then
some
are
going
to
require
a
little
bit
more.
You
know,
discussion
and
digging.
So
it's
good
that
we
knocked
out
a
lot
of
these
and
looks
like
we
only
have
maybe
a
handful
more
of
not
decided.
So
we
could
probably
knock
that
out
by
our
next
meeting.