►
Description
Presented by Diane Hosfelt, Research Engineer, Mozilla
About GitMerge
Git Merge is the pre-eminent Git-focused conference: a full-day offering technical content and user case studies, plus a day of workshops for Git users of all levels. Git Merge is dedicated to amplifying new voices in the Git community and to showcasing the most thought-provoking projects from contributors, maintainers and community managers around the world. Find out more at git-merge.com
A
Sorry,
so
I'm,
Dian,
haasvelt
and
I
am
a
research
engineer
at
Mozilla
and
I
work
on
the
servo
project,
and
today
I
am
here
to
talk
about
how
open-source
development
can
benefit
security-critical
code.
I
am
a
reformed
government.
Employee
I,
remember
one
day
at
my
old
job,
I
looked
around
the
room.
I
had
no
idea
what
anyone
else
was
doing
and
no
one
in
that
room
knew
what
I
was
working
on.
A
That
was
normal
and
in
this
job
that
was
necessary
now
I'm
at
Mozilla
and
clearly
I've
experienced
the
exact
opposite
I'm,
convinced
that
when
it
comes
to
widely
used
security,
critical
code,
such
as
the
things
that
underpin
all
of
your
internet,
browsing
and
usage,
there
are
benefits
to
having
an
open-source
workflow
as
a
mozillian.
I
believe
that
an
open
Internet
is
a
better
internet.
So
browsers
are
the
main
gateway
to
the
web.
A
I
know
that
there's
there's
a
lot
of
people
who
now
connect
via
apps
or
via
embedded
browsers
inside
apps,
but
it
all
can
come
down
to
the
fact
that
we
use
browsers
to
connect
to
the
Internet
as
a
rule
of
thumb.
Maybe
you
do
some
fancy
command
line
only
stuff,
but
that
is
far
too
complicated.
For
me,
this
makes
the
the
browser
both
critical
it's
essential
and
it's
security
critical.
We
need
to
protect
users
while
still
being
flexible
and
on
the
servo
projects.
What
we're
doing
is
we
are
investigating
new
technologies
that
require
architectural
changes.
A
A
A
Basically,
what
this
requires
is
that
a
browser
has
to
try
and
do
something
with
this
random
code
that
someone
else
wrote,
but
it's
running
on
your
machine
even
before
considering
things
like
privacy
and
secure
banking,
it's
clear
that
browsers
need
to
be
flexible
while
still
ensuring
that
you
are
secure,
and
you
know
people
aren't
exfiltrating
your
bank
routing
data
and
taking
all
of
your
money
or
whatever
it
is.
You
don't
want
people
to
know
about.
A
So
what
is
servo
servo
is
an
experimental
browser
rendering
engine
and
it's
written
in
a
language
called
rust.
Rust
is
a
modern
systems,
programming
language
who
here
loves
C,
yeah,
okay,
who
here
loves
C++
all
right
few
hands
fair
enough
right
so
who
loves
writing
parallel
code
and
C
and
C++
all
right?
A
Somebody's
lying
I
do
not
believe
you,
so
what
Russ
does
is
it
has
certain
memory,
safety
guarantees
and
I
so
happens
that
the
mechanisms
of
the
language
that
allow
you
to
prevent,
use
after
freeze
and
double
freeze
and
other
terrible
horrible
things
that
go
wrong
when
you're
doing
manual
memory
management.
This
also
prevents
data
races.
This
allows
you
to
fearlessly
program
concurrent
code
and,
generally
speaking,
if
your
rest
code
compiles,
it's
gonna
work
pretty.
Well
you
unless
you've
done
something
well,
unless
you've
done
something,
weird
and
probably
wrong,
you're
not
going
to
segfault.
A
There
are
no
seg
faults
and
rust.
It's
great.
It
makes
your
life
a
lot
easier
once
you
get
used
to
it,
but
anyways
so
by
writing
a
browser
engine
and
Russ.
What
we're
able
to
do
is
write
highly
parallel
code
that
also
prevents
major
causes
of
security
vulnerabilities,
something
like
60%
of
browser
vulnerabilities
in
Firefox
over
the
past
decade
or
so.
This
is
a
statistic
in
my
head.
Don't
quote
me
on
it.
A
So
no
I
know
I've
talked
up
rust.
A
lot
and
I
haven't
even
gotten
to
like
our
workflow,
but
rust
is
not
a
magic
solution
to
having
perfect
code,
it's
a
tool
and
it's
a
great
tool,
but
it
doesn't
solve
all
of
your
problems
for
you
and
we
rely
on
a
few
underlying
principles
of
open
source
code
and
the
strength
of
our
community
to
write
secure
performance
code.
A
This
is
sorry.
Let
me
get
this
sumed
better
so
that
you
can
actually
see
the
entire
site.
Here
we
go
so
I'm
going
to
talk
a
little
bit
now
about
a
very
basic
open
source
workflow,
and
this
is
how
we
run
things
in
servo
right
everything
starts
with
an
issue.
There
are
a
few
benefits
to
having
open
issues
obvious.
One
is
that
if
you
have
a
list
of
issues
and
ideas
and
projects
for
contributors
to
work
on,
they
can
take
one
and
then
can
get
started
right
away.
A
They
don't
have
to
know
who
to
talk
to
to
figure
out
what
they
can
do.
They
can
look
find
something
that
matches
their
interests
and
they
can
get
going.
They
can
get
working
on
it
right,
the
other,
the
flipside
of
this
is.
We
also
can
have
anyone
submit
issues
to
us
in
2016
in
June
we
released
servo
nightly,
builds,
and
the
moment
we
released
this
all
of
a
sudden.
We
had
a
flood
of
new
issues.
I
have
no
idea
how
many
came
in,
but
it
was.
It
was
just
a
massive
influx
of
people
saying
hey.
A
A
We
also
gained
27
new
contributors
during
that
period
of
time
directly
after
this,
this
allowed
us
to
drastically
improve
our
user
experience
in
a
very
short
period
of
time.
It's
also
important
that
you
ensure
that
your
bugs
are
labeled
appropriately
this.
This
just
smooths
the
process.
In
particular,
we
have
a
set
of
bugs
that
are
labeled
EEZ,
and
these
are
bugs.
That
would
be
great
for
first-time
contributors
there
well
scoped
someone's
willing
to
mentor
them
and
it
helps
introduce
new
contributors
to
our
workflow.
A
However,
these
bugs
are
incredibly
popular
and
we
are
not
able
to
keep
them
around
I
swear
some
of
them
disappear
in
a
matter
of
hours.
It's
insane.
So
we
have
coined
the
term
e-easy
piranhas,
because
on
server
we
love
memes.
You'll
you'll,
see
a
little
more
about
that
in
a
few
slides,
I
swear
from
personal
experience,
working
on
an
e,
easy
bug,
something
that's
well
scopes
and
easy
to
code,
but
allows
you
to
figure
out
how
the
workflow
action
works.
A
It's
really
helpful.
It
makes
contributing
to
open
source
much
less
daunting.
I
had
never
contributed
to
open
source
I've
been
programming
for
years,
but
I'd
never
contributed
to
anything
that
other
people
could
see
right
and
that's
it's
a
little
scary,
especially
you.
You
don't
want
people
to
say
bad
things
about
your
code.
It's
like
that's
the
worst
thing
in
the
world.
A
A
A
Once
you've
opened
up
your
pull
request,
our
friendly
bots
are
going
to
greet
you
they're,
gonna,
say
hi.
How
are
you
doing?
Someone
will
talk
to
you
soon
and
get
hub
will
assign
a
reviewer,
and
this
is
probably
I
would
say
that
reviewing
is
one
of
the
two
most
important
steps
in
this
process.
Just
because
your
source
code
is
open
and
available
doesn't
mean
that
anyone
is
actually
going
to
read
it.
Who
has
ever
had
that
feeling?
Oh,
hey,
I'm
gonna
go
read
open
us
a
cell
today,
great
yeah,
it's
great
bedtime
reading
right.
A
A
A
I
did
a
horrible,
stupid
thing
and,
like
now,
I'm
fixing
it
and
everyone
else's
were
oh
look,
I'm
a
genius
I've
done
everything
in
just
a
single
commit,
and
so
learning
to
rebase
has
really
improved
my
self
confidence
and
my
self
when,
like
Hey,
look
at
my
great
commit
messages.
Aren't
these
impressive
it's
a
personal
victory,
but
it
does
actually
have
a
purpose
right
when
someone
does
get
love
like
they
need
to
actually
see
something
meaningful
if
they're
going
to
follow
what's
happening.
A
A
What
is
the
point
of
having
code
on
your
master
branch
that
fails
tests
you're
just
going
to
end
up
with
failure
fatigue
if
everything,
if
things
always
fail,
what's
one
more
failure?
Does
it
really
matter?
It's
a
tree
is
already
fallen
in
the
forest.
Do
you
know
if
a
second
tree
has
fallen
or
a
hundred?
A
A
A
The
strength
of
both
rust
and
servo
is
the
community.
In
particular,
there
are
two
aspects
that
I'm
going
to
highlight:
the
the
Code
of
Conduct
and
our
global
distribution.
The
numbers,
underneath
the
logos,
are
the
total
number
of
contributors
that
we
have
on
github.
These
numbers
I
think
are
incredibly
impressive,
especially
having
over
2,000
people
contribute
to
you
know
a
language.
That's
I,
think
that
that's
impressive
and
something
for
the
rest
language
to
be
proud
of
security
and
open
source
projects
requires
more
than
just
existing
as
open
source.
It
requires
an
engaged
community.
A
You
need
different
contributors,
you
need
to
be
inclusive,
you
need
to
be
responsive
and
you
need
to
have
good
coding
and
development
practices.
No
one
will
want
to
bring
up
bug
to
you.
If
you
have
a
history
of
being
unpleasant
to
people
who
point
out
your
mistakes,
it's
not
a
good
way
to
include
new
contributors,
if
they're
afraid
that
you're
going
to
tell
them
that
they
are
stupid
and
they
are
wrong.
A
One
awesome
thing
about
starting
with
git
is
that
it's
easy.
A
lot
of
people
already
have
github
accounts.
It
lowers
the
barrier
to
entry.
You
don't
have
to
go
to
some
random
FTP
server
and
know
how
to
fetch
the
code
and
know
how
to
build
it.
All
you
can
just
get
clone
and
everything
works
magically
and
this
by
lowering
the
bar
of
entry,
we
can
expand
our
potential
community
communication
matters.
This
is
where
our
global
diversity
helps.
We
have
core
contributors
and
time
zones
across
the
blow.
A
If
someone
submits
a
bug,
you
need
to
respond
in
a
timely
manner.
Are
you
really
going
to
submit
an
issue
or
a
pull
request
if
it
languishes
for
two
years
before
someone
finally
looks
at
it,
you're
just
going
to
write
that
off
and
move
on
with
your
life
discussing
things
in
if,
if
someone
finds
a
vulnerability,
you
really
need
to
respond
in
a
timely
manner.
A
A
Wood
mist
held
the
competition
to
decide
on
a
new
crypto
standard
AES.
They
were
required
to
consult
the
crypto
experts
at
NSA.
The
selected
algorithm
is
a
symmetric
encryption,
algorithm
called
Rindell
and
a
key
component
is
the
substitution
box.
The
sbox
an
input
comes
into
the
S
box,
it's
transmuted
into
some
output.
Now
the
NSA
reviewed
this
algorithm
and
then
mysteriously
all
of
the
s
boxes
were
changed
for
years.
A
Obviously,
the
NSA
had
an
interest
in
keeping
their
techniques
classified,
but
they
also
wanted
to
strengthen
the
encryption
standard.
They
have
a
dual
mission.
The
downside,
of
course,
is
that
for
years,
people
were
like
I'm,
not
using
AES.
It's
been
backdoored
by
the
NSA
when
really
they
just
made
it
better.
A
This
is
a
great
quote
about
the
rust
community
from
you
know,
everyone
tries
out
rust
and
then
once
you've
tried
rust,
you
have
to
write
a
blog
about
trying
rust,
because
if
you
haven't
blogged
about
trying
rust,
have
you
tried
rust,
you
have
not.
The
rust
community
seems
to
be
populated
entirely
by
human
beings.
I
have
no
idea
how
this
was
done.
Well,
it's
done
via
a
strict
code
of
conduct.
If
you
are
unpleasant
to
other
people,
you
are
not
welcome
in
the
rest,
community.
A
So
this
brings
us
to
one
of
the
core
discussions.
When
we
talk
about
open
source
code,
just
do
more
eyes
lead
to
better
code.
I
would
argue
yes.
Firstly,
it
makes
you
accountable.
No
one
wants
to
have
their
bad
code
in
the
public,
for
everyone
to
see
and
I've
already
mentioned
reviewing,
but
that's
that's
an
automatic
second
eyes.
You
know
going
over
your
code
line
by
lying
function
by
function
and
it's
so
important.
Grayden,
who
is
the
inventor
of
rust,
said
you
should
automatically
maintain
a
repository
of
code
that
always
passes
all
of
the
tests.
A
A
This
also
means
making
sure
that
you
actually
have
tests
it.
Doesn't
you
know
if
you
run
your
tests
and
they
all
pass,
but
your
only
test
is:
can
you
print
out
hello
world?
You
aren't
actually
testing
anything
and
I
ran
into
this
a
little
bit
about
a
little
bit
ago.
There
was
a
logic
error
that
resulted
in
a
critical
security
vulnerability
a
few
years
ago,
and
it
was
patched
but
then
during
a
code
refactoring,
it
was
reintroduced
because
at
the
time
that
it
was
first
patched,
no
one
wrote
a
test
for
it.
A
A
But
you
say
what
about
things
like
shell
shock,
shell
shock
existed
in
bash
for
25
years
before
it
was
discovered,
and
to
talk
about
that
first
I'm,
going
to
reference
an
axiom
that
will
be
familiar
to
anyone
who
studied
cryptography,
and
this
is
Kirchhoff's
principle.
A
cryptosystem
should
be
secure,
even
if
everything
about
the
system
except
the
key
is
public
knowledge,
for
example,
let's
consider
the
following
crypto
system.
The
first
letter
of
every
word
of
my
message
is
my
secret
message.
Now
this
is
great
until
you
know
this,
and
then
everything
falls
apart.
A
A
A
Returning
to
the
example
of
shell
shock,
the
moment
the
bug
was
reported,
hackers
started
exploiting
it.
Cloudflare
reported
seeing
ten
to
fifteen
attacks
per
second
after
they
implemented
mitigations
in
match.
There
are
ways
to
work
around
this
if
you
think
it's
unlikely
to
be
independently
discovered,
wait
and
just
slip
it
into
the
next
big
release
that
way,
it'll
be
in
with
all
of
your
other
improvements,
and
it's
you
know
it's
just
not
as
glaring
alarm
bells
as
it
is.
A
A
Who
here
knows
about
open
SSL
I've
mentioned
it
like
five
times,
so
there
should
be
all
of
you
all
right,
yeah,
we're
done
that's
good,
open
SSL
is
the
most
widely
used
open
source
implementation
of
cryptography
and
the
TLS
protocol.
It's
been
around
since
about
1998.
In
the
past,
the
code
base
was
not
known
to
be
friendly.
In
fact,
I
once
took
an
exam
that
required
tracing
and
analyzing
some
open
SSL
code,
and
it
was
the
hardest
part
of
the
exam.
A
A
A
This
is
an
amazing
accomplishment
and
one
that
really
does
benefit
everyone
and
I
would
encourage
everyone
to
look
at
how
you
can
open
your
code.
Maybe
your
community
is
your
company
or
your
team.
You
know,
or
some
superset
of
your
team
instead
of
the
world.
Not
all
projects
can
be
public,
however,
by
forming
an
open-source
community
and
having
certain
community
standards,
like
always
having
your
tests
pass,
you
can
improve
your
product,
while
I
focus
on
the
benefits
to
security,
critical
code.
These
practices
can
benefit
all
and
all
projects.
Thank
you.