►
Description
Presented by Brian M. Carlson, Git Ecosystem Engineer, GitHub
"Git has long used SHA-1 to identify objects in its datastore, but recent cryptanalytic advances have rendered SHA-1 weak. There's ongoing work to transition to SHA-256, which is more secure. We'll cover the transition plan, where we are with it, what's involved in the transition work, and how we're going to provide interoperability between versions of Git using different hash algorithms."
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
A
So
why
shock
you
56
so
for
sha1,
get
currently
used
as
sha-1
objects,
so
the
name
of
every
object,
a
commits,
blob
tree
or
tag
depends
on
its
hash
and
it's
uniquely
identified
by
its
hash.
But
sha-1
is
horrible
to
collisions
if
you're
familiar
with
a
shattered
attack.
That
was
a
proof
of
concept
by
google
showing
that
collisions
could
be
practically
shown
to
occur
with
sha-1,
and
so
a
malicious
actor
could
create
two
different
objects
with
the
same
hash
and
the
attack
requires
lots
of
resources.
A
The
shattered
attack
required
years
of
cpu
time,
but
it
tacks
only
get
better,
so
we'd
like
to
do
something
about
it
before
we
have
a
problem.
So
what
would
happen
if
we
didn't
transition
if
sha-1
were
broken
and
we
were
stuck
using
it,
so
it
would
eventually
not
be
able
to
store
certain
objects.
You
wouldn't
be
able
to
store
the
two
colliding
objects.
A
You
could
either
store
one
or
the
other,
but
not
both,
and
so
you
basically
lose
the
idea
where
git
is
a
general-purpose
content
store
which
is
really
useful,
because
people
use,
if
restoring
source
code,
game
assets,
images
pretty
much
anything.
It
uses
the
backup
format
in
certain
programs
and
get
would
stop
being
able
to
store
a
whole
bunch
of
data.
You
really
want
to
be
able
to
store
and
sign,
commits
and
tags
would
become
meaningless.
A
A
One
of
our
considerations
was
that
we
wanted
a
hash
where
the
hash
fits
on
the
screen
and
the
hash
is
64
characters
long
with
sha-256
and
it
fits
on
an
80
column
screen.
I
know
some
people
feel
very
strongly
for
or
against
80
column
screens,
but
they
still
exist.
So
that
was
a
consideration.
It
provides
128-bit
security.
A
It
is
supported
in
all
major
crypto
libraries
across
platforms.
This
was
a
major
consideration.
We
thought
about
not
only
Linux
and
UNIX
systems,
but
about
Windows
about
Apple,
common
crypto,
the
Mac
OS
standard
library.
So
it
has
good
performance
everywhere
and
it's
widely
supported
and
even
better,
it's
supported
in
Hardware
on
AMD
and
arm
and
soon
it
will
be
supported
on
general-purpose
and
tell
processors
as
well,
and
that's
really
beneficial.
A
If
we're
looking
for
the
best
performance
action,
Guji
isn't
a
performance
problem
for
us,
but
we
might
as
well
go
with
the
best
performance
we
can
get
if
it's
possible,
so
I'm
going
to
talk
a
little
bit
about
the
transition
plan,
and
so
the
goal
is
for
our
plan
are
to
minimize
disruption
for
our
users.
We
want
it
to
be
as
simple
and
straightforward
to
use
as
possible
and
we
want
to
preserve
interoperability.
If
person
a
is
using
sha-1
and
person
B
is
using
sha-256.
A
We
want
them
to
be
able
to
work
together,
so
we
considered
interoperability,
one
of
the
core
tenets
of
the
plan,
and
so
each
user
gets
to
decide
when
they
want
to
transition
independent
of
others.
That
means
that
if
I'm
working
with
I
shot
it
2:56,
repo
and
I'm,
collaborating
with
you
on
an
open-source
project
or
you're
one
of
my
colleagues,
you
get
to
decide
when
to
transition
and
I
can
transition
independently
and
new
signs
objects
will
make
use
of
the
stronger
hash
algorithm.
So
we
can
have
signatures
from
both
sha-1
and
sha-256.
A
So
there's
a
staged
transition
plan
and
it
depends.
It
varies
based
on
three
different
types
of
three
different
types
of
algorithms
used.
So
we
have
the
algorithm
used
for
the
data
directory
which,
when
we're
doing
a
transition,
is
always
going
to
be
sha-256
and
the
input
data,
which
is
what
you
put
on
the
command
line
or
standard
input
and
the
output
data,
which
is
what
we're
putting
out
to
the
screen
or
what
we're
piping
to
other
programs.
A
So
the
variations
that
we
have
in
the
different
stages
depend
on
these
three
so
stage
one
is
the
dark
launch,
so
the
data
in
the
gate
directory
will
be
shocked.
256
like
in
all
of
these,
but
in
putting
up
with
sha-1,
you
won't
be
able
to
notice
that
anything
is
different
and
that's
the
goal.
So
it
works
just
like
it
did
before.
A
So
I'm
going
to
cover
a
lot
of
what's
in
this
document,
but
if
you're
interested,
we
actually
have
more
information
about
the
transition
plan
in
the
gate,
repo
and
we've
documented
it
in
the
technical
documentation
directory
so
that
it's
anyone
who's
doing.
This
work
can
be
involved
with
it
and
know
what
the
plan
is
and
so
that
other
people
can
be
familiar
with
it
and
other
developers
who
aren't
doing
work.
A
This
area
can
help
support
it
by
considering
these
things,
when
they're
writing
new
code,
so
I'm
going
to
talk
a
little
bit
about
the
implementation
details
about
what's
going
on
and
some
of
the
decisions
we've
made
about
what's
involved.
So
one
of
the
overarching
design
guidelines
that
we're
trying
to
stick
with
is
that
everything
in
the
docket
directory
uses
the
same
algorithm
so
even
where
it
doesn't
strictly
need
to
we've
chosen
to
make
it
consistent
so
that
the
gate
directory
is
either
a
sha-1
or
all
sha-256.
A
There
are
translation
tables
that
we
will
write
between
the
two
algorithms
that
will
obviously
not
be
on
the
one
algorithm,
but
other
than
that.
It's
all
going
to
be
consistent.
So
anything
producing
get
data
as
well,
like
a
bundle
is
also
going
to
do
the
same
thing.
It's
going
to
produce
the
same
data
format
and
he
packs
any
bundles
they're
all
going
to
produce
that
same
algorithm,
fetch
and
push
will
negotiate
an
algorithm
to
use.
A
So
all
other
output
is
going
to
use
the
same
algorithm
so
anything
that
outputs
to
the
screen
or
to
another
program
is
going
to
be
consistent,
based
on
which
stage
of
the
transition
garage.
The
alternative
to
this
is
to
separate
plumbing
and
porcelain
commands.
Plumbing
commands
are
those
that
are
used
for
scripting
and
porcelain.
Commands
are
used
as
the
user
interface,
but
a
lot
of
people
aren't
familiar
with
the
distinction,
and
so
they
use
porcelain
commands
for
scripting.
A
A
The
order
in
which
we're
doing
the
work
is
actually
a
little
different
than
the
order
in
which
users
will
transition
through
the
stages.
So
right
now
we
have
a
stage
zero
get,
which
is
it
get
that
is
capable
of
only
sha-256.
It
doesn't
support
any
existing
repos.
We
also
have
a
stage
four
get,
which
is
a
get
that
can
do
either
one,
but
the
repo
is
either
all
of
one
or
all
the
other.
A
The
next
step
we're
going
to
implement,
is
get
being
capable
of
a
per
repository
algorithm,
but
it
can
talk
to
the
other.
So
if
you
have
a
server
that
hasn't
been
upgraded
yet
or
if
you're
on
an
older
client,
they'll
be
able
to
interoperate
and
then
we're
going
to
let
get
specify
the
output
algorithm
and
then
finally,
the
input
out
for
them,
at
which
point
we'll
have
all
the
stages
complete.
A
So
these
are
some
of
the
things
that
we've
had
to
do
in
order
to
do
the
transition,
so
we
have.
The
get
code
base
has
had
an
extraordinarily
large
number
of
20
and
40
based
constants,
and
it's
not
just
20
in
40
but,
for
example,
shallow
headers
contain
48,
so
we've
transitioned,
all
of
those
constants
into
fixed
constants,
fixed
magic,
constant
values
and
using
a
structure
abstract
away
our
objects.
A
So
it's
easier
to
replace
this
means
that
all
the
code
just
works
when
we
upgrade
so
we're
going
to
use
an
abstraction.
So
we're
going
to
basically
say
I
want
the
size
of
the
current
algorithm.
We
don't
care
what
algorithm
you're
using.
We
just
want
the
size
of
the
current
one,
and
this
abstraction
lets
us
do
that
very
easily.
A
There
are
a
large
number
of
tests
that
have
simply
hard-coded
hash
values
in
them,
and
so
we've
moved
to
computing
those
values
if
I
want
the
hash.
For
two
commits
ago,
I
asked
for
lookup
a
hash
for
two
commits
ago:
I,
don't
hard-code
the
value
anymore,
and
this
makes
it
a
lot
faster
to
develop
new
algorithms.
A
With
version
3,
which
will
allow
us
to
look
up
versions
in
the
same
version
for
sha-1
and
sha-256,
if
and
then
we
have
general
bug-fixing,
we
have
some
code
that
just
relied,
incidentally,
on
the
behavior
of
sha-1
and
actually
has
a
bug
and
it's
broken,
but
we
didn't
notice
so
there's
going
to
be
some
general
bug
fixing
as
well
so
as
I
kind
of
implied
a
little
bit
earlier.
Our
current
status
is
that
we
have
a
stage
for
implementation.
We
have
a
repository,
you
can,
on
a
per
repository
basis,
use
one
algorithm
or
the
other.
A
A
A
A
A
So
so,
basically
in
get
1.0,
we
developed
the
repository
format
version
and
we
set
it
to
zero,
and
so,
if
it
saw
a
repository
format
version
that
wasn't
zero,
it
was
fail
and
that's
good,
because
clearly
it
would
know
how
to
read
the
data
and
get
2.7.
We
went
ahead
and
added
repository
format,
version
1,
which
allows
for
extensions,
and
so
now,
if
it
sees
an
extension,
it
doesn't
understand,
it
will
fail.
So
the
way
we
basically
handle
this
situation
is,
we
say
core.
A
The
core
repository
format
version
is
1,
so
we
can't
read
extensions
on
and
the
object
format.
Extinction
is
sha-256,
and
that
did
enough
to
tell
us
that
our
repo
is
in
shock
256.
We
can
also
set
the
compact
object
format
to
sha-1,
and
that
basically
means
I
want
you
to
build
tables
for
sha-1.
I
want
you
to
support
backwards,
compatibility
and
so
alder
gets
that
don't
know
about
these
extensions.
We're
about
the
new
format
version
will
just
fail
and
that's
really
what
we
want.
A
So
the
way
we're
going
to
store
multiple
algorithms
is
we're:
gonna
store
the
objects
in
the
pack
files
and
the
loose
objects
in
the
sha-256
for
them,
and
we're
going
to
do
on
the
fly,
translation
of
new
objects
and
new
packs.
So
if
you're
talking
over
the
network
to
another
algorithm,
if
you're
writing
a
new
object,
we
will
compute
it
in
both
forms.
A
The
loose
objects
will
have
a
lookup
table.
So
if
we
already
have
the
object,
it's
very
fast,
we
look
it
up
and
lookup
table
the
pack
and
xv-3
will
store
both
algorithms
in
separate
look-up
tables
such
that
we
say
this.
One
is
the
fourth
object
in
this
algorithm,
so
it's
the
fourth
object
and
the
other
algorithm,
and
it's
very
fast
and
efficient
lookup,
and
we
wanted
to
perform
as
well
as
possible,
be
because
people
have
a
large
number
of
repositories
that
are
very
large
and
we
have
to
consider
performance
as
a
primary
characteristic.
A
So
for
specifying
revisions,
if
you're
using
stage,
2
or
stage
3,
you
can
just
write
your
sort
hash
and
it
will
figure
it
out
on
his
own.
If
it's
ambiguous,
it
will
ask
you
to
resolve
the
ambiguity.
You
can
write
it
with
this
new
syntax,
caret,
sha-1
or
caret
sha-256,
which
tells
that
that
you
want
one
or
the
other,
where
you
can
just
write
out
a
full
40
or
64
character.
Rsa
object,
ID.
A
If
you're
doing
scripting
you're
probably
going
to
do
this
instead
and
it
will
automatically
figure
out
what's
going
on,
everything
else
is
going
to
work
just
like
it
does
now.
So
everything
you
love
or
maybe
you
don't
love
so
much
about
git,
it's
gonna
be
just
like
it
is
now
and
that's
kind
of
our
goal.
Is
that
we're
going
to
transition,
but
we're
not
going
to
radically
change
the
way
it
works.
A
A
The
two
versions
were
interoperate
one
binary
repositories
and
each
version
will
interoperate
with
each
other.
The
design
is
based
around
regularity
and
simplicity.
It
should
be
easy
for
the
average
developer
to
understand
how
the
transition
is
going
to
work
for
them,
and
the
work
is
already
well
underway.
Much
of
the
code
is
merged,
there's
more
yet
to
be
emerged,
but
it's
been
going
on
for
some
time.
We
have
at
least
15
pack
series
submitted
already
and
I
expect.