►
From YouTube: Memory Safety Sig (July 6, 2023)
A
A
D
C
C
E
C
And
in
the
meantime,
since
Zoom
does
not
show
the
chat
history
to
people
who've
newly
joined,
there
is
a
link
to
our
agenda.
Please
go
ahead
and
add
your
attendance.
Take
a
look
at
the
agenda
today.
I
think
this
might
be
a
short
meeting.
Our
shortage
meeting,
which
is
fine.
A
lot
of
people
had
conflicts
today.
C
C
D
A
C
Thank
you.
Yeah,
oh
looks
like
Jay
is
connecting
to
audio
awesome
cool
all
right.
Let's
quickly
review
some
in-progress
work.
We
have
a
couple
of
pull
requests
open,
one
of
which
I
just
approved,
but
I
want
to
see
if
anyone
else
wants
to.
Oh,
that's,
not
the
thing
I
want
to
do.
Anyone
else
wants
to
take
a
look
at
it.
C
It's
a
smaller
one,
from
Josh,
adding
in
some
challenges
to
the
doc
we're
writing,
which
is
a
rewrite
of
the
language
around
the
memory,
safety
stream
of
the
open
source
security
mobilization
plan-
and
this
is
mentioning
the
challenges
with
larger
dependency
change,
particularly
since
it's
common
to
at
least
appear
to
have
a
larger
dependency
chain.
When
stock
was
written
in
Rust
versus
written
in
other
languages.
D
D
C
Okay,
oh
gotcha,
gotcha,
gotcha,
yeah,
I,
think
that
sounds
logical
and
I
know.
That
is
an
area
that
openssf
as
a
larger
org
is
looking
at
with
things
like
s-bombs
and
other
things.
How
do
you
have
this
very
large
web
of
trust,
this
ecosystem
of
trust,
I
I,
when
you're
using
so
many
different
components
from
so
many
different
things?
So
it's
it's
good
I
think
to
call
that
out
in
our
document.
B
D
A
B
D
There
are
probably
a
few
reasons
for
that,
but
one
of
the
most
important
ones
is
that
it
is
a
real
pain
in
the
butt
to
add
dependencies
and
see
and
then
ship
them
across
the
ecosystem.
Rust,
for
example,
has
the
cargo
packet
manager,
and
that
makes
it
really
easy
to
add
dependencies
and
because
it's
easy
to
add
dependencies,
people
do
add
a
lot
more
dependencies.
They
tend
to
add
dependencies
for
things
that
are
just
smaller
Snippets
of
reusable
code,
whereas
in
in
the
Sea
World
it
would
be
a
pain
to
add
a
dependency.
D
So
you
just
put
that
c
code
in
your
own
source
code
or
something
like
that.
So
I
think
the
package
manager
system
is
what
leads
to
these
much
bigger
dependency
trees
and
they
they
have
pros
and
cons.
I
mean
the
big
con
for
me.
Is
the
weather
forecast
is
much
larger,
there's
just
way
more
people
that
you're
collecting
in
your
average
Russ
program.
D
The
pro
is,
the
structure
of
programs
is
often
more
clear.
There's
less
code
duplication
things
like
that,
but
I
think
that's.
The
heart
of
the
matter
is
that
cargo
is
similar
a
similar
deal
with
like
node
and
go
where
they
also
have.
You
know
npm
python.
They
all
have
these
package
matters
that
just
make
it
really
easy
to
make
dependencies,
and
that
does
not
exist
in
the
fee
world.
They
just
have
keyword
dependencies.
B
B
It
might
be
like
Mozilla
and
chrome,
I
mean
and
I
mean.
Have
you
know,
C
plus
plus
rooms
have
huge
numbers
of
dependencies.
It
depends
on
the
the
application
and
some
of
these
efforts
to
rewrite
well
like
mod
TLS
and
other
things
in
Russ
I.
Don't
think
that
those
inherently
have
more
dependencies,
so
that's
I
think
it's
sort
of
how
you
write.
B
B
Styles
or
other
things
have
more
dependent,
and
yes,
it's
good
to
give
the
motivation
with
dependency
chains,
but
I'm,
not
I,
guess
you
just
find
it
sort
of
that.
The
the
motivation,
the
the
reasoning
there
doesn't
fully
make
sense
to
me
or
the
the
what
you're
ascribing
the
the
the
reasoning
to
doesn't
fully
make
sense
to
me.
It
doesn't.
D
Sorry,
if
there's
something
I
can
do
to
make
it
more
clear,
I'm
happy
to
do
that.
I
do
think
things
like
Firefox
and
chrome
are
pretty
outlier,
pretty
big
outliers
in
terms
of
how
massive
they
are
and
they're,
not
really
what
I'm
talking
about.
But
if
you
look
at
things
like
even
mod
TLS,
which
you
cited
right,
mod
TLS
itself
doesn't
necessarily
have
to
have
more
dependencies,
but
because
my
TLS
uses
Russell's
the
Russ
TLS
library.
D
In
the
background,
it
does
in
fact
have
way
more
dependencies
than
the
C
equivalent,
which
is
just
open
this
out,
which
has
far
fewer
dependencies
for
basically
the
reasons
that
I
cited
and
so
leaving
aside
some
of
the
outliers
in
the
CC
plus
sponsor
World,
which
do
have
massive
numbers
of
dependencies.
When
we,
when
we
have
been
rewriting
things
like
ntp
and
sudo
and
some
other
things,
the
dependency
trees
are
definitely
on
average.
Much
larger.
F
Yeah
I
I
think
this
is
a
really
interesting
problem,
space
and
and
I'm
kind
of
curious
how
much
it
is
just
dependency
chain
depth
and
how
much
it's
also
to
do
with
the
way
that
servicing
happens
and
static
linking
and
the
way
that
people
manage
these
sets
of
dependencies
and
operating
systems.
I
I,
don't
have
you
know
deep
insight
into
that
space.
It's
kind
of
I've,
more
worked
with
people
working
on.
F
So
I
think
there
is
like
a
sort
of
I.
Don't
know
whether
you
call
it
impedance
mismatch
or
whatever,
between
what
traditional
packages
look
like
and
what
crates
look
like
and
I.
Don't
know
whether
it's
that
just
the
depth
or
the
volume
that's
the
biggest
issue
or
whether
there's
something
else
there
and
then
I
guess
coming
back
to
the
work
of
this
group.
D
The
way
that
I
I
mean
this
is
not
intended
to
be
specific
to
rust.
So
when
I
talked
to
packagers
for
Ubuntu
and
red
hat,
this
same
conversation
comes
up
for,
go
for
example,
especially
around
kubernetes
components
that
are
getting
integrated
into
these
operating
systems,
but
I
don't
think
it
is
specific
to
go.
But
I
do
think
that
it
is
certainly
an
adoption
issue,
as
opposed
to
an
issue
of
memory
safety
itself.
D
For
me,
those
two
have
become
very
intertwined,
like
I
think
we
know
how
to
write
memory
safe
code,
basically-
and
that's
not
really
the
challenge
unless
you're
talking
about
assembly
code
optimizations,
for
you
know
basically
cryptography
and
video,
you
know
media
codex,
I
think
those
are
the
only
two
places
where
we
don't
really
know
how
to
regular
research
code
in
acceptable
ways.
So
for
me
this
is
really
the
next
step
in
in
bringing
memory
safe
to
the
ecosystem
is
not
like.
How
do
we
write
rusts
or
how
do
we
write
go?
D
The
question
is:
how
do
we
get
that
out
into
the
wider
world
and
right
for
me,
this
is
the
next
Frontier
there,
which
is
helping
operating
systems,
and
everybody
involved
in
this
stuff
understand
what
these
different
dependency
chains
means.
What
do
the
cultural
differences
mean?
How
would
these
programs
structured
differently
and
what
does
that
mean
per
ship
to
them?.
F
So
is,
it
is
like
I
guess
is
the
problem
that
you
present
hey?
You
should
replace
this
package
sudo
or
whatever
you
have
with
this
rust
version,
and
now
that
means
you
have
50
or
whatever
different
packages
that
you
now
need
to
maintain
as
part
of
your
distro.
Is
it
like
just
a
like?
Is
it
just
that
that's
confronting,
and
it's
and
it's
like
a
big.
You
know
it
seems
like
a
big
undertaking
to
replace
one
package
with
something.
That's
a
lot
more
complicated.
Are
we
like?
D
D
And
make
sure
that
everybody
involved
in
the
maintain
them
is
trustworthy.
So
when,
when
Fedora
says
you
know,
okay,
we
have
tools
that
can
package
200
rust
crates
into
a
program.
That's
fine,
but
now
we're
responsible
for
making
sure
that
all
this
stuff
is
secure
and
that's
that's
a
tough
chunk
of
responsibility
to
swallow
compared
to
the
C
equivalent
that
you
know.
In
my
experience,
rust
equivalents
tend
to
have
five
to
ten
times
the
number
of
dependencies,
and
most
of
them
are
new
they're,
not
something
the
operating
system
is
already
dealing
with
I.
F
C
B
Oh
no,
it
was
agreeing
with
what
Daniel
said
earlier,
which
is
and-
and
we
seem
to
be
saying
that
this
isn't
inherent
to
memory
safe
languages.
This
is
part
of
more
modern
package
based
dependency-based
building
of
of
modern
languages
and
those
modern
languages.
Many
of
them
are
more
memory
safe,
but
I'm,
not
certain
that.
It's
really
a
inherent
to
this.
That's
just
for
my
concern
about
making
this
statement
in
in
this
pull
request.
B
This
document
that
again
it's
that
this
is
something
that
that's
important,
exactly
as
we
were
saying
earlier
for
with
Josh
of
how
this
is
going
to
be
a
a
challenge
or
how
it's
going
to
be
make
more
complicated
for
the
deployment
of
these
replacement
applications,
but
it
doesn't
seem
that
it's
inherent
I
mean
that
that
it's
a
necessary
characteristic.
In
other
words,
if
one
had
rust
without
the
crate
system
and
without
the
ease
of
I
mean
and
crates
aren't
you
know,
I
mean
it's.
B
It's
a
nice
feature
functionality
in
Rust,
but
the
rust
language
doesn't
require
crates.
It's
just
a
convenience.
You
could
add
a
package
system
to
see.
So
that's
why
I'm
sort
of
saying
that
it
seems
like
you're
making
a
statement
about
the
inherent
design
of
memory
safe
languages
as
opposed
to
the
inherent
design
of
modern
software
development
and
software
engineering.
C
So
I
like
to
summarize
what
I
think
I'm
hearing
so
what,
if
we
changed
memory
memory,
safe
languages
to
many
modern
languages,
which
tend
to
be
memory
which
tend
to
have
better
memory
safety?
So
let's
reflect
that.
It's
a
modern
language
issue,
not
something
that's
inherent
to
memory,
safe
languages.
It's
inherent
to
Modern
languages,.
B
And
you
know
I
mean
this
isn't
sort
of
fundamental
to
the
you
know,
I
think
to
to
this.
You
know
document
anyway,
I
mean
so
I
don't
want
to
you
know
just
you
know
bike
shed
this
this
one
since,
but
just
it
was
just
curious
to
me
that
yeah
that
this
is
modern
software
engineering
I
mean
has
this
characteristic
I.
F
Because
you
know
say
we
have
memory
safe
languages,
we
see
they
have
value,
but
we
want
to
connect
that
with
actually
having
the
adoption
and
moving
that
forward.
And
so
the
question
then,
is
you
know
and
Josh
I
think
is
speaking
to
a
challenge
that
he
has
in
terms
of
driving
that
adoption,
where
there's
this
cultural
disconnect
and
whether
that's
inherently
to
do
with
rust
versus
any
other
modern
language.
F
Is
it
part
of
our
scope
to
try
and
drive
that
cultural
push
to
be
able
to
adopt
these
languages,
or
is
it
a
place
where
we
think
the
right
thing
is
to
push
back
in
the
other
direction
and
use
rust
without
crates,
which
I
think
would
be?
You
know,
but
I
I
think
that
would
make
you
know,
be
a
big
challenge
in
terms
of
we
don't
really
have
any
of
the
code
that's
written
there,
so
it
would
be
starting
from
from
a
pretty
pretty
low
base.
So
so
I
don't
know.
I.
C
Think
it's
worth
calling
out
in
the
doc,
perhaps
calling
it
out
as
a
cultural,
odd
challenge
versus
a
technical
challenge,
because
we
are
our
Sig
is
within
the
developer.
Best
practices
working
group-
I,
cultured
me-
you
know,
as
developer
myself
gained
developers
to
adopt
best
practices,
is
a
cultural
thing.
It's
not
it's
not
just
a
technical,
not
just
making
technical
arguments.
Changing
the
culture
around
it
I
think
it
is
worth
calling
it
out
as
as
a
challenge
in
moving
critical
internet
software
moving
software
into
modern
languages,
which
tend
to
be
Memory,
safe.
F
I
think
it's
good
to
think
of
it
as
a
bit
of
a
cultural
challenge.
I
think
it
can
also
be
a
bit
dangerous
in
terms
of
the
mindset
it
pushes
us
into
like
in
that
we
know
how
to
do
things
and
we
have
to
teach
them
how
and
I'm
not
saying
that
you
were
suggesting
that,
but
in
in
you
know,
aside
from
the
like
how
to
have
a
culture
that
can
organize
and
manage
and
feel
confident
in
terms
of
supporting
all
of
these
crates,
which
could
have
different
sets
of
independent
developers.
F
E
F
Trying
to
change
some
of
the
building
blocks
of
that
on
them
for
a
benefit
that
they
might
like,
but
it
means
that
we
need
to
have
a
way
that
they
can
work
with.
You
know,
and
there
are
other
efforts
out
there,
like
you
know,
blessed.rs
and
I,
don't
want
to
point
too
heavily
at
that,
but
there
are
efforts
and
other
community
efforts
as
well
to
try
and
identify
trustworthiness
and
crates,
and
it's
it's
obviously
an
issue
that
we
internally
and
Microsoft
have
a
challenge
around
as
well
right.
F
So
I
don't
want
to
diminish
that
challenge,
as
just
saying
they
have
to
you
know,
get
with
the
program
or
whatever,
which
I
know.
That's
not
what
you're
characterizing
it
is
all,
but
yeah
so
I'm,
just
saying
there's
a
risk
of
if
we
make
it
sound
too
much
like
a
cultural
thing
that
it's
like
it's
an
organizational
thing
of.
F
How
do
they
get
to
stand
behind
it
rather
than
a
technical,
tooling
limitation
that
we
can
write
code
to
fix
right,
we
may
need
to
write
some
tooling
to
help
support
the
organizational
change,
but
it's
like
that
that
I
think
is
I.
Don't
know
Josh
you
can
kind
of
chime
in
if
that's
not
what
you're
you're
angling
at
yeah.
D
I
agree
with
you
that
well
I'm,
not
sure
your
sentence,
but
I
would
say
that
calling
it
a
cultural
issue,
I
think
is
not
quite
right.
It
implies
that
we
know
what
like
a
better
culture
is
and
I.
Don't
think
that
we
do
like
at
the
end
of
the
day,
a
lot
of
the
sort
of
stuff
that
gets
labeled
as
cultural
behavior
is
just
the
obvious
conclusion
of
the
tools
available
right
when
you
have
a
system
like
cargo
available
and
rust.
D
Of
course,
people
are
going
to
behave
the
way
that
they
do
with
regards
to
dependency
chains,
because
that's
what
that
that's,
what
those
tools
encourage
and
that's
really
essential
to
the
language.
So
that's
not
that's
not,
in
my
mind,
like
an
interesting
cultural
artifact.
Here,
I
think
we
need
to
make
some
decisions,
and
you
know.
A
D
Can
probably
start
sharing
some
writing
that
I
have
with
with
people
where
I
sort
of
outline
the
problem
long
form
again
focusing
on
this
problem
of
large
pensive
chains
leading
to
trust
issues,
and
you
know
in
my
mind
the
solutions
are
in
the
bucket
of
we
need
to
reduce
the
number
of
dependencies.
One
option,
for
example,
is
to
include
some
more
stuff
from
the
Russ
standard
Library.
There
are
a
lot
of
challenges
around
that
a
lot
of
questions
about.
What
would
you
do?
D
How
would
you
address
approach
that,
if
you
can't
pull
that
off
the
second
best
way
to
do,
it
is
basically
stuff
like
blast.rr,
and
if
you
can't
do
that,
you
know
there.
There
are
solutions
down
the
line
there
and
I.
Don't
think
that
any
of
the
solutions
that
I
have
come
up
with
as
plausible
really
involve
cultural
change.
They
involve
making
decisions
about
how
dependencies
are
going
to
work,
going
forward,
understood.
C
I
do
want
to
be
cognizant
of
time.
We
do
have
some
other
stuff
on
the
agenda.
I'd
encourage
this
discussion
to
continue
I
think
on
Josh's,
open
pull
request
is
the
best
place
for
that
to
be
I.
Think
the
oh,
of
course,
of
course,
I
won't
merge
it
until
you
update
it.
I
I
yeah.
Let's
continue
having
the
conversation
there,
so
there's
a
record
of
it
and
we
will
continue
forward
I.
Thank
you
for
bringing
bringing
those
concerns
up.
Everyone
next
item
on
the
agenda
is.
C
Right
so
some
words
about
proposing
investments
in
education.
We
did
have
a
discussion
on
standardizing
on
memory,
space,
safe
or
memory
hyphen
safe.
We
made
some
agreements,
Last
Call,
on
what
to
what
to
standardize
on
and
I
think
the
pr
just
still
needs
a
few
edits
and
I
know.
Crow
had
a
conflict
today
and
has
had
some
other
stuff
going
on.
C
C
E
E
C
C
C
All
right
well
hearing
none
I
am
I.
Very
much
am
of
the
belief
that
meaning
it's
okay,
if
meetings
End
early,
if
all
discussion
has
has
completed
so
thank
you
so
much
for
those
of
you
who've
been
with
us
here,
live.
Thank
you
for
those
of
you
who
are
watching
this
later
on.
Youtube
I
do
know
that
people
watch
it
and
hello
good
to
see
you
and
thank
you,
everyone
and
have
a
wonderful
rest
of
your
week.